Compliance & Governance

Audit vault

Every routing decision, policy update, reviewer action, drift snapshot, and corrective action is appended to a tamper-evident vault and chained into a daily Merkle root. The vault is the single source of truth for any regulator question, dispute, or post-incident investigation.

Properties

  • Append-only. Entries can be redacted (cryptographic deletion of payload ciphertext at retention expiry) but never replaced or removed silently.
  • Merkle-chained. Each entry includes the SHA-256 hash of the previous entry in its category. Any tamper attempt downstream invalidates the chain hash.
  • Tenant-scoped. Every query filters on tenantId from the auth context. Cross-tenant reads are not possible.

What gets stored

Each vault entry is filed under a category for queryability:

CategoryWhat it captures
policy_updateDeployer policy publish / sign events.
red_team_runScheduled red-team snapshots.
regulator_accessSuccessful regulator-credential validations.
drift_detectionRising-drift snapshots.
corrective_actionOpen / status-change / close events on the corrective-action workflow.
scc_acknowledgmentBYOK SCC ack events for non-adequate-jurisdiction provider keys.
retention_eventCryptographic-deletion proofs at retention expiry.

Tamper evidence

Each entry stores prevHash (SHA-256 of the previous entry in its category). The first entry of each category uses a deterministic genesis hash. To detect tampering, walk the chain — any altered entry breaks every subsequent prevHash until the next published Merkle root.

Query API

MethodPathPurpose
GET/api/v1/vaultQuery vault entries (filter by category, action, time range).
GET/api/v1/vault/regulator-accessReal-time feed of regulator-access events for the deployer dashboard.
POST/api/v1/vault/credentials/validateValidate a regulator-access credential.
GET/api/v1/audit-logsQuery the activity-log table (auth events, key mutations, role changes).

Regulator access

Regulators use a separately-issued, time-bounded, read-only credential that scopes them to one tenant's vault entries. Every successful validation is itself logged to the vault under regulator_access — so the deployer sees exactly who looked at what, when. Failed validations (bad / revoked / expired token) deliberately do not audit, to avoid creating a probing oracle for stolen tokens.

Retention

Per-tenant retention policies determine how long full prompt/completion ciphertext is held. The retention scheduler runs daily, redacts expired entries (drops the ciphertext, keeps the metadata), and writes a retention_event proof row so the deletion is itself part of the chain. Default retention windows: 90 days for the standard policy, 5 years for the DORA template, 10 years for medical-device-style retention.