A tamper-evident log is a log designed so that any alteration, deletion, or insertion of past entries can be detected. The standard construction chains records cryptographically: each entry includes a hash of the previous entry (or the records are organized in a Merkle tree), so modifying any historical record breaks every hash that follows it. The log does not prevent tampering — no data structure can stop an administrator with write access — but it guarantees tampering cannot happen silently, which is the property that gives records evidentiary weight.
The distinction from an ordinary audit log matters more than it first appears. A conventional log's integrity rests entirely on access control: anyone who can write to the storage can rewrite history, and an investigation cannot prove they didn't. A tamper-evident log shifts the guarantee from "we restricted access" to "any change is mathematically detectable" — a claim that survives even the compromise of the logging system's own administrators.
How the construction works
The minimal hash-chain version: entry n stores hash(entry n-1) alongside its own content, and each entry's own hash covers that link. Verification walks the chain recomputing hashes; any mismatch localizes the tampering. Production systems add refinements — periodic signed checkpoints (so verification doesn't require the full history), Merkle-tree batching (so a single record's inclusion can be proven efficiently), and external anchoring of checkpoint hashes (so even a wholesale rebuild of the chain is detectable against the anchored value). Deletion and truncation are covered too: a missing tail shows up against the latest anchored checkpoint, and a gap breaks the chain.
The engineering details and trade-offs are covered in tamper-evident audit logs with cryptographic proofs.
Why AI agent systems specifically need it
Tamper evidence was a nice-to-have when logs recorded human actions at human speed. Agentic systems change the calculus in three ways:
- The log is the accountability layer. Agents act autonomously; the audit trail is often the only authoritative account of what an agent did and why. If that record can be silently edited, attribution collapses — and with it incident response, behavioral baselining, and trust scoring.
- Attackers who compromise agents want the logs next. Rewriting history is the natural second step of any successful agent compromise. A hash-chained log converts "cover the tracks" from an edit into a detectable event.
- Regulation assumes it. The EU AI Act's logging obligations for high-risk systems require records that support post-hoc accountability, and auditors under SOC 2 and ISO 42001 increasingly ask how log integrity is protected rather than just whether logs exist. Evidence produced from a tamper-evident store answers the question structurally — the compliance context is laid out in audit trails that hold up.
Design considerations
Three practical points recur in real deployments. Append-only semantics: the write path should not expose update or delete operations at all; retention-driven removal happens through auditable, policy-governed processes (and where GDPR erasure applies, through anonymization that preserves chain integrity — see GDPR for AI systems). Completeness: tamper evidence protects what was written; events that never reached the log are invisible, so log emission belongs at the enforcement point where actions are allowed or denied, per the runtime security model. Verification as routine: a chain nobody verifies is decorative — integrity checks belong in scheduled operations, with a broken chain treated as a security incident, not a data quality ticket.
Common questions
What is a tamper-evident log in one sentence? A log constructed — typically with cryptographic hash chaining — so that any alteration, deletion, or insertion of past entries is mathematically detectable, giving the records evidentiary integrity beyond access control.
Does tamper-evident mean tamper-proof? No. Anyone with sufficient access can still modify stored bytes; the guarantee is that the modification breaks the hash structure and is therefore detectable. Detection plus anchored checkpoints is what makes tampering pointless: the attacker cannot produce a consistent forged history.
How is this different from write-once (WORM) storage? WORM prevents modification at the storage layer; hash chaining proves integrity at the data layer. They compose well — WORM raises the difficulty of tampering, the hash chain proves whether it happened — but the chain's guarantee travels with the data (exports, backups, replicas), while WORM's stops at the storage boundary.
Can a tamper-evident log support GDPR erasure? Yes, with design: separate identifying attributes from the event structure, so erasure anonymizes the personal data while the chained event skeleton — and thus the chain — remains intact. The event that something happened is preserved; who it concerned is removed.