Runbook: the audit chain

Every privileged action - a credit grant, a key rotation, a device revocation, a role change - is written to a hash-linked audit chain. Each entry commits to the one before it, so the history is tamper-evident: you can't alter a past event without breaking every hash after it.

What is recorded

• Actor - who took the action.
• Event - what happened (e.g. key.rotate epoch→8, device.revoke, role.change → admin).
• Target - what it affected.
• Hash - a link to the previous entry, and a timestamp.

seq 4021 · admin@acme · credit.grant +500 · target sara@acme.dev · a91f…3c2
seq 4020 · superadmin   · key.rotate epoch→8 · target signing      · 77be…901

Why hash-linked

A plain log can be edited after the fact. In a hash chain each entry includes the hash of its predecessor, so changing entry 4019 changes its hash, which breaks the link recorded in 4020, and so on to the head. An auditor recomputes the chain and any gap or edit shows up immediately.

Reading it

The audit history is available to owners and admins with drill-down into any entry. Signing-key rotations recorded here are how you know which epoch key was active when a given receipt was signed.