Security Architecture
Every component of the MovingOrders stack was designed for the threat model of a military housing platform — OPSEC, privacy, and financial integrity are non-negotiable.
Encryption
Database Security
Every one of the 78 tables in the movingorders schema has Row Level Security enabled and at least one RLS policy. Geocoordinates are stripped from every member, guest, and AGENTGATE serializer — latitude and longitude never appear in API responses. All monetary values are stored as integer cents — no floats, no decimals.
AWS Infrastructure
All compute, database, cache, and storage runs in AWS us-east-1. AWS services used by MovingOrders independently hold SOC 2 Type II, ISO 27001, and FedRAMP High authorizations.
Vendor API Routing — MO-LD-XRAY-001
All third-party vendor API calls — AI models, speech-to-text, text-to-speech, voice biometrics, payments, background checks, e-signature, and translation — route exclusively through api.25xray.ai/v1. This is an absolute architectural rule enforced at CI on every commit. No direct vendor calls are permitted from MovingOrders code.
OPSEC Filter — RELOCATE-19
Every POST and PATCH that writes text fields to the database calls RELOCATE-19 OPSEC-FILTER synchronously before any database write. If the verdict is BLOCK, the request returns 422 and no data is persisted. This applies to original content and to translations — a translation is content and is filtered identically. OPSEC-FILTER runs at the application layer, not as a post-hoc moderation step.
Secrets Management
Zero secrets in the frontend environment. All API keys, database credentials, and service tokens live in AWS Secrets Manager under the movingorders/prod/ path. The X.R.A.Y. API key is surfaced server-side only as XRAY_IEN_SERVICE_KEY. Iron Law 30 blocks any database URL in the postgres scheme from reaching the git remote.
Vulnerability disclosure: security@movingorders.com · security.txt