Security you can re-verify, not just read about
Thirty non-negotiable invariants, encoded as tests and database constraints, exercised against clean databases on every verification run.
The thirty invariants
These are requirements the test suite must encode — not aspirations. Each is enforced in application code and, wherever possible, again in PostgreSQL constraints and triggers.
| ID | Invariant |
|---|---|
INV-01 | A disabled, revoked, expired, or quarantined principal cannot receive new authorization. |
INV-02 | A denied action cannot execute through any TrustRail gateway. |
INV-03 | Any protected-field mutation after decision or approval invalidates authorization. |
INV-04 | One tenant cannot read, reference, mutate, approve, or execute another tenant's resources. |
INV-05 | Every gateway execution attempt references one valid decision and subject digest. |
INV-06 | Every privileged state transition commits its audit event in the same transaction. |
INV-07 | Published policy and schema versions are immutable and reconstructable. |
INV-08 | Production provider secrets never reach browsers, agents, logs, traces, or analytics. |
INV-09 | An ML or LLM result cannot weaken a deterministic denial or mandatory approval. |
INV-10 | A decision token cannot authorize more than one logical execution. |
INV-11 | Approval votes are bound to the exact subject digest and approval rule version. |
INV-12 | A kill switch or revocation blocks sensitive execution within the stated propagation SLO. |
INV-13 | Child authority is a subset of every ancestor grant and current policy. |
INV-14 | A revoked ancestor makes all descendant authority ineffective. |
INV-15 | Binding commitments cannot be inferred solely from natural-language messages. |
INV-16 | A provider timeout never becomes an assumed failure or assumed success. |
INV-17 | Audit-chain forks are rejected by database concurrency controls. |
INV-18 | No security decision relies on client-controlled tenant, role, risk, time, or digest values. |
INV-19 | Agent-workload egress is denied unless an effective allowlist entry authorizes it. |
INV-20 | Requested host, pinned DNS result, and observed TLS SNI must agree. |
INV-21 | Broker or policy-cache loss fails closed and creates no bypass route. |
INV-22 | Contained agents cannot distinguish containment from an ordinary denial response. |
INV-23 | Automated containment may only restrict authority; widening requires a human. |
INV-24 | Containment tiers are strictly ordered and cannot be skipped toward more authority. |
INV-25 | The forensic plane has no provider credential or control-plane write path. |
INV-26 | No forensic analysis proceeds before the evidence chain verifies. |
INV-27 | Every privileged transition appends evidence in the same transaction. |
INV-28 | No action is called executable without a registered adapter and reconciliation test. |
INV-29 | Untrusted influence may tighten authorization and can never widen it. |
INV-30 | Protected tools execute only against pinned definitions and canonical mappings. |
Each invariant is asserted by a named test that carries its identifier, so the sentence and the assertion can be read against each other. The ones about database concurrency and cross-service authorization are proven in the clean-database rehearsals (scripts/test-*.ts, run by pnpm verify) rather than in unit tests, because asserting them against a fake would prove less than not asserting them at all.
Defense in depth, concretely
Witnessed by a log we do not run
Checkpoints over the audit chain are signed and submitted to a public transparency log. What that buys is narrow and worth stating precisely: here is a root that a log we do not run recorded at a time we could not choose. It does not make the chain unalterable — it makes an alteration something a third party’s record would contradict. A deployment with no log configured says so rather than implying otherwise, and a log that refused is reported as a refusal rather than as a pending state.
Five database roles, one of which does nothing
Application, gateway, worker, forensics, and repair — all NOLOGIN, non-superuser, and unable to bypass row-level security. The worker reads what its loops need and writes only through narrow, column-scoped grants; erasing a payload can update one column and nothing else. Repair holds broad grants it cannot exercise: no row-level policy names it, so it reads zero rows on every protected table. We found that by auditing our own claim and wrote it down as ADR-0033 rather than quietly leaving the sentence up.
Canonicalization as the root of trust
A from-scratch RFC 8785 implementation with golden vectors, duplicate-key detection (including escape-equivalent duplicates), and strict Unicode handling. Every signature and approval binds to its digests.
SSRF-safe provider transport
Exact-origin pinning, HTTPS only, private/loopback/link-local/metadata ranges rejected after DNS resolution, and the resolved address pinned to defeat DNS rebinding between check and connect.
Hardened execution tokens
Ed25519, canonical JSON encoding, closed claim set (unknown claims rejected), 300-second lifetime cap, base64url canonicity checks, revocation-first key lookup, and atomic one-use consumption.
Everything bounded
Body limits, string caps, policy step budgets, response size ceilings, statement timeouts, bounded retries, capped archives. Unbounded input is treated as the primary denial-of-service vector.
Every hop of a delegation chain, not just the first
Each grant is checked against the one before it: it must name its parent, be issued by the previous hop's subject, be unrevoked, fall inside its own validity window, and narrow rather than widen what it inherited. A chain that widens, skips a parent, or continues past a revoked hop is refused with the hop named.
Fail closed, visibly
Missing policy denies. Unknown risk facts count as maximum risk. Stale JWKS is an outage, not a bypass. Readiness endpoints report exactly which dependency failed, with reason codes instead of fabricated success.
Review posture: every milestone ships with a threat model, an executable clean-database rehearsal, and a written review record. Internal deep reviews are complete and documented in-repo; independent external review gates are tracked openly and are never fabricated.