How the cryptographic chain runs through every Certified Action Record

Every authority decision the gate renders produces a Certified Action Record (CAR). Each CAR is sealed with an Ed25519 signature over a deterministic JCS canonicalization (RFC 8785) of the sealed fields, plus a SHA-256 digest of the canonical bytes. The signing standard is published as ARES-v1 under the AuthorityRail Standards Foundation; ARES-v1.1+ (CBOR / COSE_Sign1) is tracked as DRAFT under the spec-version governance decision at standards/governance/active-spec-version-2026-05.md.

• Algorithm. Ed25519 over a SHA-256 digest of the JCS-canonicalized sealed fields. Hex-as-UTF-8 signing input convention pinned in the spec.
• Multi-key with rotation. Current key plus a transitional key with overlap so signing-key rotation never breaks an in-flight verification. Rotation procedure: docs/runbooks/06-car-signing-key-incident.md. Public-key feed at /v1/keys (alias /.well-known/jwks.json).
• Public-key embedding. Every persisted CAR row contains the issuing public key, key ID, algorithm, and signer string — verifiers re-check end-to-end without trusting AuthorityRail. See docs/CAR_VERIFICATION.md.
• Durability before issuance. A CAR is not “issued” until its row is durably persisted to the execution ledger. POST /v1/execute does not return success until the underlying INSERT is confirmed. See docs/CAR_DURABILITY.md (Phase 2.6 / R-20).
• Replay and freshness. Every POST /v1/execute carries a caller-supplied request_id + timestamp. The gate enforces a ±60s freshness window and a 24-hour idempotency store keyed on (org_id, request_id). See docs/REPLAY_FRESHNESS.md (Phase 2.7 / R-21).

Per docs/AUTH_IDENTITY_MODEL.md (added in commit 0da8125, Phase 1.6 R-12 / R-13 closure), AuthorityRail runs a dual-identity model. The two surfaces never share a session.

Tenant isolation is enforced at Postgres via row-level security policies on every tenant-bearing table. The single point of truth is the auth.org_id() SQL helper at supabase/migrations/20260505000100_rls_helper_fn.sql. Tenant-scoped policies cover ~37 tables in the Phase 1.6 RLS hardening migrations (20260505000200…0700). Cross-tenant test assertions: services/gate/__tests__/rls-isolation.test.ts and tenant-isolation.test.ts.

Agents authenticate to the gate using JWTs from an OIDC provider (Okta, Azure AD, AWS IAM, or any compliant OIDC IdP). Verification result (verified, identity_provider, identity_trust_adjustment) is sealed into the CAR. See services/gate/src/lib/nhiVerifier.ts.

Key custody

Data security

• In transit. TLS 1.2+ on every surface — marketing, standards site, gate, voice gateway, dashboard, internal service-to-service. Static origins via Cloudflare; application origins via Railway, both with platform-managed certificates.
• At rest. Cloud-provider-managed encryption (Supabase / AWS managed keys). Backups inherit the same encryption.
• CAR storage. certified_action_records has an immutability trigger preventing UPDATE/DELETE outside the documented retention path. Rows include public key + signature so verifiers can re-check end-to-end without trusting AuthorityRail.

Failure posture — fail-closed

Every authority-bearing path runs fail-closed. When a critical dependency is unreachable the default outcome is DENY or ESCALATE — not ALLOW. Phase 2.5 (R-19 closure) classified every fail-open path; the table is appended to standards/audits/launch-readiness-audit-2026-05-03.md. Documented operational behavior: docs/FAILOVER_SPEC.md and docs/FAILURE_MODES.md.

• RAAS unreachable → CAR with decision_hint:"ESCALATE", risk_level:"HIGH", raas_score:1000, marker raas_engine_unavailable_fallback.
• Policy engine unreachable → CAR forces ESCALATE; no silent ALLOW.
• Boot guard refuses to start the gate in production with POLICY_FAIL_OPEN=true unless an explicit POLICY_FAIL_OPEN_FORCE=true override is set.
• CAR persist failure → 503 with CAR_PERSIST_FAILED; never a fake-success CAR (Phase 2.6).

Incident response and breach notification

Operational logs flow to Sentry + Better Stack. Critical paths emit structured ERROR lines that page on-call via PagerDuty. Authentication anomalies, signature-verification failures, and abnormal denial rates are alarmed.

On confirmed Personal Data Breach affecting Customer Personal Data, AuthorityRail notifies the affected Customer without undue delay, and in any event within seventy-two (72) hours of confirmation. The notification covers the nature of the breach, categories and approximate number of records affected, likely consequences, measures taken or proposed, and a contact for further information. The full obligation is in Section 8 of the DPA at /legal/dpa. 72 hours is the binding floor; the internal target is faster.

Security researchers should follow the Vulnerability Disclosure Policy for coordinated disclosure on a 90-day standard window.

Compliance and audit posture

The Trust page at /trust documents the regulatory and certification posture in detail. Honest disclosure: claims of audit completion appear there only when the audit has actually completed.

• SOC 2 Type II — planned for post-launch (Q3 2026 target). No audit in progress today.
• HIPAA — not currently HIPAA-eligible. BAA may be available for Enterprise tier on a per-deployment basis (see /trust).
• GDPR / UK GDPR / FADP — covered by the DPA at /legal/dpa (EU SCCs Module 2/3 + UK Addendum + FADP modifications).
• CCPA / CPRA — covered as a service provider under DPA Section 12.
• EU AI Act Article 14 — Human Decision Records under DRI-v1 provide the regulator-facing artifact for human oversight of high-risk decisions.

AuthorityRail is mapped, not yet third-party audited. The mapping work is published; the audit work is on the roadmap.

Contact

• Security report (vulnerability): security@authorityrail.com — see /security/disclosure.
• General security questions: hello@authorityrail.com.
• Compliance and DPA: hello@authorityrail.com.