A tamper-evident audit log is an append-only record in which every entry is cryptographically chained to the one before it. It does not claim that records cannot be altered — it guarantees something stronger in practice: that any alteration, including a deletion, can be detected by recomputing the chain.
Tamper-Evident, Not Tamper-Proof
"Tamper-proof" is a claim almost no operational system can honestly make. Someone administers the database; someone holds the credentials. A tamper-evident design accepts that and shifts the guarantee from prevention to detection. Each entry incorporates a hash of its predecessor, so the log forms a chain in which every record depends on the entire history behind it. Edit one field in a year-old entry and every subsequent link fails to verify. Delete an entry outright and the gap is visible, because the next entry references a predecessor that no longer exists.
This is the property an auditor is actually asking about. The question is rarely "could an administrator alter this record?" It is "if someone had altered this record, would you know?"
What Belongs in the Log
For governed agents, a decision log alone is not enough. The record must also cover the governance actions that shaped those decisions, or an auditor cannot reconstruct why a given action was permitted:
| Entry type | What it proves |
|---|---|
| Agent decision records | What the agent proposed, what the runtime decided, and under which rules. |
| Policy publishes | Which reviewed revision became enforceable, and when. |
| Reviewer approvals | Which named human authorized an escalated action, and on what rationale. |
| Escalations created and resolved | That high-risk actions were routed to a person rather than executed. |
| Bundle syncs | Which rule set a given runtime was actually enforcing at a point in time. |
| Token issuance and revocation | Which identities could act, over which windows. |
Retention and the Deletion Problem
Retention requirements and tamper evidence pull in opposite directions. Privacy regimes require that records be deleted after a defined window; hash chaining is precisely the technique that makes deletion detectable. A governed system resolves this by treating retention as a policy of its own: entries past the retention window are archived and exportable before removal, and the removal itself is a recorded, expected event rather than an unexplained gap. An organization can then show an auditor both that old records were disposed of as required and that nothing else was quietly disposed of alongside them.
Verification in Practice
- Chain on write. Each new entry commits to the current head of the log, making the record append-only by construction.
- Re-verify continuously. The chain is recomputed on a schedule, so a break surfaces as an alert rather than as a surprise during an audit.
- Export for review. Entries are retrievable programmatically and filterable by agent, connector, status, risk level, and date range, so evidence for one incident can be produced without handing over the whole log.
- Attribute precisely. System-generated entries and human reviewer actions are attributed separately, so an approval can never be mistaken for an automated allow.
Why This Underpins Everything Else
Every other governance control depends on the credibility of the record it writes. A human-in-the-loop approval is only meaningful if the approval record cannot be fabricated after the fact; policy enforcement is only demonstrable if the decisions it produced are still there to inspect. Tamper evidence is what turns a log from an operational convenience into evidence.
See how decisions, approvals, and evidence are recorded, or read the AI agent governance overview.