A tamper-evident log is a log designed so that changing a recorded entry 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, inserting, or deleting a historical record breaks every hash that follows it. The chain alone cannot show that the newest entries were removed, or that it was rebuilt from an altered entry onward; catching those takes a checkpoint anchored outside the system. The log does not prevent tampering — no data structure can stop an administrator with write access — but a recorded entry cannot be edited silently, and with an external anchor neither can the log be cut short or rebuilt. That 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 "altering a recorded entry is mathematically detectable." Anchor its checkpoints outside the system and that guarantee holds even if the logging system's own administrators are compromised; without an external anchor, removing the newest entries, or rebuilding the whole chain, cannot be detected.
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 the AI agent audit trail guide.
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 changing a recorded entry is mathematically detectable, while removing the newest entries or rebuilding the chain is detectable only against a checkpoint anchored outside the system, giving the records evidentiary integrity beyond access control.
Does tamper-evident mean tamper-proof? No. Anyone with sufficient access can still modify stored bytes. Editing a recorded entry breaks the hash chain and is therefore detectable, but the chain alone cannot show that the newest entries were removed or that it was rebuilt from an altered entry onward. Detection plus checkpoints anchored outside the system is what makes tampering pointless: the attacker cannot produce a forged history that matches the anchors.
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.