Security & trust posture
Every security control documented here is implemented as a structural constraint — enforced by the database, the execution engine, or CI — not by training, guidelines, or voluntary application-layer guards. Designed from the first commit for Fortune 500 finance, defense procurement, and regulated operations.
Controls are marked Enforced when the implementation is a structural constraint — blocking rather than merely logging — and verifiable from source. Full mapping with evidence package available under NDA.
Access Control (AC)
Separation of Duties
Proposer ≠ approver enforced server-side on every action_proposals row. The database trigger fires before any UPDATE — no application-layer bypass is possible. Zero self-approvals; every attempt is blocked and written to the audit log.
Least Privilege
Four role tiers (viewer, analyst, admin, owner) with locked capability sets defined in lib/auth.ts. Role escalation requires an explicit privileged write — end users cannot escalate themselves. Enforced in CI via migration 0029.
Remote Access
All sessions require a valid Supabase JWT. Tokens are short-lived (1 hour default). Connector credentials are held in Vault, not environment variables, and are never returned to the client.
Audit and Accountability (AU)
Audit Events
Every proposal creation, approval, rejection, execution, rollback, replay, and connector credential change writes an audit record with caller identity, org_id, payload hash, action type, and duration. Coverage is structural — events are emitted by the execution engine, not by voluntary application logging.
Protection of Audit Information
The execution step ledger (nervos_execution_steps, migration 0030) is hash-chained: each row's hash field is computed over the concatenation of the current payload and the previous row's hash. Any row deletion or modification breaks the chain and is immediately detectable.
Audit Record Generation
Automatic on every state transition in the governed execution path. Records are written by lib/execution/ledger.ts (appendExecutionStep) before the action result is returned. Failure to write the ledger entry causes the execution to fail — not to silently succeed without a record.
Configuration Management (CM)
Access Restrictions for Change
No write to any connected system (NetSuite, Salesforce, etc.) is possible without an approved action_proposals row in status=approved. The write gate is enforced in lib/execution/engine.ts — there is no code path that writes to an external system without first fetching and validating an approved proposal.
Identification and Authentication (IA)
Identification and Authentication
All API routes validate the caller's Supabase JWT before any data access. Service-role (RLS-bypassing) access is limited to an allowlisted set of files, verified in CI (tests/service-role-allowlist.test.ts). Any new service-role usage trips a CI gate.
System and Information Integrity (SI)
Software, Firmware, and Information Integrity
SHA-256 hash-chaining on the execution ledger. HMAC-SHA256 verification on NetSuite inbound webhooks (x-aetherforge-secret header). CSP enforced (not Report-Only) in next.config.mjs. npm audit runs in CI on every PR.
Six structural properties — enforced at the infrastructure layer, not the application layer.
Postgres RLS is enabled on every table. Every policy is scoped by org_id = current_org_id(). Verified in CI: zero tables without RLS, zero over-permissive policies, zero unconstrained write paths. A CI tripwire (tests/service-role-allowlist.test.ts) blocks any unreviewed RLS-bypass from reaching production.
Connector credentials (NetSuite OAuth tokens, TBA private keys) are stored in Supabase Vault — encrypted with libsodium, keyed by Supabase KMS. A stolen session token cannot read another org's credentials because Vault access is enforced by RLS, not by application-layer guards.
NetSuite inbound webhooks are rejected unless the x-aetherforge-secret header matches the HMAC-SHA256 of the payload body, using a secret held only in the server environment. Unsigned and replayed payloads never reach application logic.
The nervos_execution_steps table is append-only by design: no UPDATE or DELETE policy exists. Each row's hash field links it to the previous entry, forming an independently verifiable chain. DCAA examiners can verify chain integrity without Nervos involvement.
GitGuardian / GitHub secret scanning runs on every push. npm audit runs in CI on every PR. The .gitignore blocks .env*, *.pem, *.key, and secrets/ directories. CSP is enforced in production (not Report-Only) to prevent XSS exfiltration.
QAMO agents cannot write to any system. Agents produce a structured recommendation that enters the proposal queue — where it waits for human approval before any execution path is invoked. No agent can self-approve, and no agent has credentials for any connected system.
Data handling
Data residency
Hosted on Supabase (AWS us-east-1 by default). Regional hosting (EU, APAC) available for Enterprise. Data never transits to AI providers without explicit opt-in.
AI data handling
QAMO uses Groq (llama-3.3-70b) for inference. No training on customer data. Groq's data processing agreement is available. OpenAI is used only for embeddings — optional, configurable off.
Retention and deletion
Customer data deletion is available on contract termination. Audit log export before deletion is provided. Sub-processor list maintained at thenervos.com/sub-processors.
Under NDA we share: NIST 800-171 control mapping with evidence, CMMC Level 2 alignment matrix, SOC 2 control documentation, sub-processor list, Data Processing Agreement, and a pre-filled SIG/CAIQ-style vendor security questionnaire. Defense and government contractors may request a classified briefing.