// Trust Center

Security Architecture

The verified security posture of AuthorityRail's execution authority infrastructure. Designed to align with SOC 2, ISO 27001, and NIST AI RMF principles; specific attestations are listed on the compliance posture page with truthful status indicators.

Last revised: 2026-05-17 · Version v1.0

Doctrine

Fail-closed. When AuthorityRail's gate cannot evaluate an authorization request — for any reason — it returns DENY, never ALLOW. Probability ≠ Permission. The gate's value claim is provable execution authority; falling back to "best effort" would violate that claim.

Zero-bypass architecture. No customer integration path issues an ALLOW decision without producing a Certified Action Record. There is no debug endpoint, no admin override, no superuser bypass.

Cryptographic execution evidence

Ed25519 signing

Every Certified Action Record (CAR) is signed with an Ed25519 key whose public counterpart is published at gate.authorityrail.com/v1/keys.

Independent verification

Customers and auditors verify CARs locally with a standard Ed25519 implementation — without trusting AuthorityRail's runtime.

Chain version

CAR envelope is versioned (chain_version); v1.1 seals engine-health attestation into the signed digest per Hardening Pass 1 closure.

Key custody

Primary signing key kept in Supabase Vault, rotated on the schedule defined in docs/runbooks/06-car-signing-key-incident.md; emergency rotation drilled via the same runbook.

Multi-tenant isolation

AuthorityRail is multi-tenant by design. Customer data and operational state are isolated at the database layer:

Row-Level Security (RLS) enforced on every public table. Pre-launch hardening reduced rls_disabled_in_public from 96 unprotected tables to 0 across two Hardening Pass cycles.
Per-org tenant scope helpers across 19 files / 80 routes in the gate and WorkforceRail-verify services.
Idempotency cache re-keyed per-tenant to prevent cross-tenant cache pollution.
API key issuance gated by per-org subscription state; revocation invalidates the gate's LRU cache within ~1 second via Supabase Realtime.

Transport and network

TLS 1.3 enforced at every customer-facing surface (Cloudflare zone setting).
HSTS with strict transport policy at both authorityrail.com and workforcerail.com zones.
CAA records pin certificate issuance to Let's Encrypt and Google Trust Services on both zones.
DNSSEC active on both zones.
WAF Cloudflare-managed ruleset + Bot Fight Mode + AI Bots block.
Rate limiting at the edge on the gate's /v1/execute hot path.

Email authentication (operational sender posture)

SPF with -all hard fail on both zones.
DMARC at p=reject on both zones.
DKIM TXT records published; Workspace-side activation closure tracked.

Detection and response

The operational doctrine is Detection → Classification → Communication → Recovery, governed by:

SEV ladder + escalation paths
status.authorityrail.com for customer-facing communications
Five critical runbooks: signer failure, Supabase outage, Railway outage, deployment rollback, customer key compromise
Sentry application monitoring (activation per Sprint Closure #2)
Better Stack uptime monitoring (activation per Sprint Closure #8)
PagerDuty on-call routing (activation per Sprint Closure #9)

Disclosure

Security vulnerabilities should be reported per the CVD policy. AuthorityRail commits to a 90-day disclosure window from acknowledgement to public advisory (or sooner where appropriate) under the AuthorityRail Standards Foundation CVD doctrine.