Audit log

Every governed call writes an audit event: the action, the connection, the policy decision, the outcome, the status code, the duration, and a hash of the arguments. Whether the call was allowed, denied, or held for approval, it's in the log.

Arguments are stored as a SHA-256 hash, never in plaintext — so secrets and PII stay out of the audit trail while integrity is still provable.

Tamper-evident hash-chain

Audit events are chained per environment. Each event stores:

• chain_seq — a monotonic sequence number,
• chain_prev_hash — the hash of the previous event,
• chain_hash — SHA-256(prev_hash + canonical(event)).

The chain starts from a fixed genesis hash and a per-environment head row tracks the latest hash and sequence. Because each event's hash incorporates the one before it, you can't alter, insert, or delete an event in the middle without breaking every hash after it — which makes tampering detectable.

Verifying the chain

Verification walks the chain in sequence order and checks that:

• sequence numbers are monotonic with no gaps,
• each event's chain_prev_hash matches the prior event's chain_hash,
• each chain_hash recomputes from the canonical event, and
• the environment's head matches the last event.

It reports { ok, checked, first_error? }. (Events recorded before chaining was introduced are marked legacy and skipped.)

What's recorded

Action, provider, connection, outcome (success / error / denied / approval / approved / self_approval_blocked / expired / …), HTTP status, duration, the arguments hash, any linked approval_id, and the request/parent trace IDs.

Export it for compliance — see Audit export.