What is tamper-evident logging?
Tamper-evident logging is a way of writing logs so that any later alteration — editing, deleting, reordering, or backdating an entry — becomes mathematically detectable, even by a verifier who does not trust the system or the operator that produced the logs, when the mechanisms below are layered through to external anchoring.
The word to take seriously is evident. Tamper-evidence is about detection, not prevention: it does not stop anyone from changing a record, it guarantees the change cannot pass verification afterward. That makes it a different property from tamper-proof (preventing modification) and from immutable storage (preventing deletion), and the three are often confused.
Last updated: 2026-06-10
Mechanisms
How tamper-evidence is built
Four mechanisms, usually layered. Each strengthens or scales what the previous one provides.
Hash chaining. Every entry includes a cryptographic hash of the entry before it. Change any record and every hash after it stops matching, so an edit anywhere in the middle of the log is visible to anyone who walks the chain. On its own, though, a chain only proves the log is internally consistent — whoever can rewrite the whole chain can rebuild a consistent forgery.
Digital signatures. Entries (or the chain itself) are signed with a private key, so a forger now needs the key, not just write access to the storage. Signatures also add attribution: the record is bound to a key holder, verifiable by anyone with the public key.
Merkle trees. Entries are leaves of a hash tree, so a verifier can confirm a record is included (an inclusion proof) and that a later view of the log is an append-only extension of an earlier one (a consistency proof), each with a proof logarithmic in the log's size instead of re-reading everything. Detecting a forked log — different views served to different verifiers — additionally requires verifiers to compare signed tree heads with each other or with an external anchor. This is the structure behind transparency logs (RFC 6962, RFC 9162).
External anchoring. Periodic checkpoints of the log's state are published somewhere the log's own operator cannot rewrite: a public transparency log, a WORM bucket in a separately administered account, a counterparty's system. This is what defeats the operator who holds the signing key: a rewritten history can no longer reconcile with the anchored checkpoints.
Disambiguation
Tamper-evident, tamper-proof, immutable
| Property | Guarantee | Typical means | Limit |
|---|---|---|---|
| Tamper-evident | Alteration is detectable on verification | Hash chains, signatures, Merkle proofs | Detects, does not prevent; needs anchoring against the key holder |
| Tamper-proof | Modification is prevented | Hardware security modules, sealed devices | Genuinely hard; in software, claims of tamper-proof usually mean tamper-evident or access-controlled |
| Immutable storage | Stored bytes cannot be changed or deleted during retention | WORM media, S3 Object Lock (COMPLIANCE mode) | Says nothing about whether the bytes were authentic when written |
The strongest practical designs compose all three: a signed, hash-chained log (tamper-evident) whose checkpoints land in immutable storage (anchoring), with keys in hardware (tamper-resistant custody).
Limits
What tamper-evidence does not protect against
Lies at write time. A tamper-evident log preserves exactly what was written, including a false report. The cryptography proves who wrote what, unaltered since — including the timestamp the writer asserted — not that any of it was true. This is why serious designs also bind each entry to an accountable identity, so a false report is at least attributable.
Truncation and the whole-log delete. A chain that simply ends looks valid. Detecting that the tail was cut — or the entire log discarded — requires externally anchored checkpoints or counterparties who hold receipts for entries the log no longer shows.
The operator who holds the signing key, unless anchoring is in place. A key holder can rewrite and re-sign a consistent history; external anchoring exists for exactly this adversary.
Availability. Tamper-evidence makes destruction detectable, not impossible. Keeping the log existing and readable is a backup and retention problem, which is where immutable storage earns its place.
In practice
Where tamper-evident logging is used
Web PKI. Certificate Transparency (RFC 6962, RFC 9162) puts every issued TLS certificate in public Merkle-tree logs, so a mis-issued certificate cannot stay hidden — one of the largest tamper-evident systems in deployment.
Software supply chain. Sigstore's Rekor transparency log records signing events for software artifacts; in-toto attestations and the IETF SCITT architecture define signed, verifiable statements about how artifacts were produced.
Cloud audit trails. AWS CloudTrail can emit signed digest files that let an auditor validate log-file integrity; several SIEMs offer per-segment hashing of their stores. These verify within the operator's trust domain — useful, but a weaker claim than third-party verifiability.
AI and automated systems. Regulation now requires durable event logs for high-risk AI (EU AI Act Articles 12 and 19), and AI agents acting across hand-offs and organizational boundaries raise the question logs alone cannot answer: who authorized this, and can an outside party check the record? That is the subject of AI accountability.
Implementation
Building or adopting one
You can assemble tamper-evident logging from open components: an append-only table, a hash-chain discipline, signatures with a well-managed key, and a checkpoint job that writes anchors somewhere the operator cannot reach. The hard parts are operational — key custody and rotation, verifier tooling someone else can actually run, and keeping the anchoring honest over years.
AGLedger is one implementation, applied to AI-agent and automated work rather than general logs: a self-hosted, signed, hash-chained record of what automated work intended and reported, verifiable offline against published keys, with optional external anchoring to Object Lock storage. For how it compares to keeping logs in a SIEM with WORM storage, see the SIEM + Object Lock comparison.
FAQ
Common questions
Is tamper-evident the same as immutable?
No. Immutable storage (WORM, S3 Object Lock) prevents stored bytes from being changed or deleted for a retention period. Tamper-evidence makes any change detectable by cryptography, wherever the bytes live. The two compose well: a tamper-evident log kept in, or anchored to, immutable storage covers both alteration and deletion.
Does tamper-evident logging require a blockchain?
No. A hash chain with digital signatures provides tamper-evidence with a single writer. Blockchains add distributed consensus — agreement among mutually distrusting writers — which most logging scenarios do not need. Certificate Transparency, Sigstore Rekor, and signed audit chains are all tamper-evident without being blockchains.
Can the administrator still tamper with a tamper-evident log?
An administrator who controls both the log and the signing key can rewrite history and re-sign it. Defeating that requires moving some piece of evidence outside the administrator's control: checkpoints published to a transparency log, or to a WORM bucket in a separately administered account. Without external anchoring, tamper-evidence holds against everyone except an adversary holding the signing key and write access to the store.
Is WORM storage tamper-evident?
Not by itself. WORM storage prevents deletion and overwrite of what was stored, but nothing in the stored object proves it was authentic when written, and verifying it requires trusting the account that holds it. WORM provides retention; tamper-evidence requires cryptography that travels with the record.
Do regulations require tamper-evident logs?
Increasingly, in effect if not always in name. The EU AI Act requires automatic event logging for high-risk AI systems (Article 12) and retention of those logs (Article 19); evidential weight in practice depends on the records being trustworthy. Frameworks like NIST AI RMF and ISO/IEC 42001 similarly call for reliable records of system operation. Tamper-evidence is the technical property that lets such records stand up to a skeptical reviewer.
Go deeper
The category that builds on tamper-evidence: integrity plus attribution plus independent verifiability.
Retention versus authenticity, in depth, against the most common substitute.
What an offline verification pass checks, and what a pass does and does not prove.
The concrete artifact for agent work, built on these mechanisms.
The record-keeping obligation for high-risk AI systems, explained.
The architectural argument for signatures over plain audit rows.