Guide

Tamper-Evident Audit Logs for AI Agents: Why Immutable Is Not Enough

By Dor Sharoni, Founder of Pruvz | 10 min read | Updated August 2026

A tamper-evident audit log proves that a record has not been silently altered since capture. It does not prove that the record was true when it was captured, and for AI agents that distinction decides whether a record counts as evidence or merely as a claim: when an action is disputed months later, the organization producing the record also operates the database it lives in. Trustworthy agent evidence therefore has two halves. Capture fidelity asks whether the record was right at write time: independent verification against the system of record, a decision-time policy snapshot, evidence labeled by source and trust level. Post-capture integrity asks whether it has changed since: append-only ordering with server-assigned sequence numbers, hash chains, Merkle trees with verifiable proofs, and external anchoring through trusted timestamps or write-once storage. The integrity mechanisms form a ladder in which each rung answers a doubt the previous one leaves open, and none of them can repair a record that was unreliable when captured, which is why capture discipline comes before cryptographic sealing, not after.

The question every disputed record eventually faces

An AI agent issues a refund in March. In September the customer disputes it, and the organization produces its record: the context the agent saw, the policy that applied, the decision, the executed action, the confirmed outcome. Then comes the question that decides whether any of it counts: how do we know this record says what it said in March? The company operates the database. The company is a party to the dispute. If the record could have been edited between March and September, the record is not evidence. It is a claim.

Human-run processes have always faced this question, but AI agents sharpen it twice over. First, the records are produced by the same automated infrastructure whose behavior is being questioned, so "the system says the system behaved" carries no independent weight. Second, the volume is different: an agent workflow can generate thousands of consequential records a day, and a challenge to the integrity of the store is a challenge to all of them at once. An audit trail that captures everything but cannot show it was never altered fails at the exact moment it exists for.

Integrity is not truth: the two halves of trustworthy evidence

Everything in this article rests on one distinction. Tamper evidence proves that a record has not changed since it was captured. It proves nothing about whether the record was true when it was captured. The two properties fail independently and are built with different tools: a record can be wrong and sealed, or right and editable. Only one combination survives a dispute, which is right at capture and provably unchanged since.

Question	Property	What delivers it
Was the record true when it was captured?	Capture fidelity	Independent verification against the system of record, evidence labeled by source and trust level, a decision-time policy snapshot, capture-time timestamps, a complete sequence with nothing missing
Has the record changed since capture?	Post-capture integrity	Append-only ordering, server-assigned sequence numbers, content hashes, hash chaining, external anchoring

The fidelity half, meaning what belongs in the record and how the outcome is confirmed, is the subject of the audit-trail guide linked above and the guide to verifying agent actions against systems of record. This article is about the integrity half: what "immutable" can actually mean, which mechanism proves what, and why the strongest cryptography still depends on the fidelity work being done first.

Tamper-evident, not tamper-proof

Start with the honest version of the goal. A tamper-proof record would be one that cannot be altered at all. For a system the operator administers, that claim does not survive scrutiny: someone holds root on the database, someone can restore from a modified backup, someone signs the deploys. Security engineering settled instead on a weaker property that can actually be delivered: tamper evidence, meaning any alteration of the record after capture becomes detectable.

The distinction is codified in the controls auditors already use. Control AU-9 of NIST SP 800-53, the control catalog behind most United States federal and many enterprise security programs, requires audit information to be protected against unauthorized modification and deletion and requires alerting when such modification is detected. Its cryptographic enhancement, AU-9(3), calls for cryptographic mechanisms to protect integrity, and its discussion offers signed hashes over the audit information as the worked example, so integrity can be verified by anyone holding the public key. The regulatory posture is detection, not impossibility, and a vendor that claims its logs are "tamper-proof" is claiming something no operated system can honestly promise.

The integrity ladder

Integrity mechanisms stack. Each rung of the ladder answers a doubt the previous rung leaves open, and each costs more to operate than the one below it. Knowing the ladder matters because "our logs are immutable" can describe any rung, and the rungs prove very different things.

Permissions and retention. The floor: nobody has delete rights on the log store, retention policies prevent expiry, access is logged. Necessary, and entirely trust-based. An administrator who edits a row leaves no trace the record itself can show.

Append-only ordering. The store exposes no update or delete path. Every new fact is a new record, and each record carries a server-assigned, strictly increasing sequence number, so later facts cannot masquerade as earlier ones and a gap in the sequence is visible. This is a data-model property, not a cryptographic one, and it does real work: it makes "the review decision was appended after the verification result, and neither replaced the other" a checkable structural fact rather than a convention. What it leaves open is the storage layer itself: someone with direct access to the underlying bytes could still rewrite history without the application noticing.

Hash chains. Each entry embeds a cryptographic hash of the previous entry, so modifying any record breaks the chain everywhere after it. The design goes back to Bruce Schneier and John Kelsey's 1999 paper Secure Audit Logs to Support Computer Forensics, which showed how a machine can write logs such that entries made before a compromise cannot be silently altered or destroyed afterward. The open doubt is wholesale rewriting: an attacker who controls the entire chain can recompute every hash and present a perfectly consistent forgery. A hash chain is only as trustworthy as the custody of its most recent link.

Verifiable log structures. Merkle trees organize the same idea for efficient proof. Certificate Transparency, specified in RFC 6962 and revised in RFC 9162, runs public append-only logs of TLS certificates where a compact consistency proof demonstrates that today's log contains yesterday's log unmodified as a prefix, and a membership proof demonstrates that a specific entry is in the log, without replaying the whole history. The web's certificate infrastructure has run on this construction at internet scale for over a decade, which is a useful existence proof that verifiable logging is practical, not exotic.

External anchoring. Every mechanism so far lives inside one organization's control. The last rung moves a small commitment outside it: a digest of the log handed to a party the operator does not control. That can be a trusted timestamping authority under RFC 3161, which signs a binding between a submitted hash and a time, proving the data existed in that exact form no later than that moment. It can be independently controlled write-once storage, or digests published where rewriting is impractical. Mainstream infrastructure already works this way: AWS CloudTrail's log file integrity validation delivers hourly digest files, each containing SHA-256 hashes of the delivered log files and the signature of the previous digest, signed with a key the account holder does not control. The independence is the point: the operator cannot rewrite what someone else holds.

Mechanism	The doubt it answers	The doubt it leaves open
Permissions and retention	Casual or accidental modification	Any change by a privileged insider
Append-only ordering	Silent rewrites and reordering inside the application	Direct modification of the storage underneath
Hash chain	Alteration of any past entry, given a trusted head	Wholesale recomputation by whoever holds the chain
Merkle tree with proofs	Efficient verification of history and membership	Same custody problem, at a larger scale
External anchoring	Rewriting by the operator itself	Content that was wrong when captured

To see these properties on a concrete record rather than in the abstract, the evidence packet walkthrough shows a captured packet field by field, sequence numbers and trust labels included.

The part cryptography cannot fix

The last row of that table deserves its own section, because it is where integrity projects most often go wrong. A hash chain proves that a record has not changed since capture. It proves nothing about whether the record was worth capturing. If the entry was written hours after the action from reconstructed memory, if it repeats the agent's own success report instead of an independent read of the system of record, if the policy it cites is a link that now resolves to a newer version, then the chain faithfully preserves content that was already unreliable. Tamper-evident garbage is still garbage.

Completeness is the other gap, and it comes in two forms. A record that was written and later removed is detectable: it breaks the hash chain, and server-assigned, strictly increasing sequence numbers leave a visible hole where it used to be, which is why the append-only rung matters independently of the cryptographic ones. A record that was never written at all is different: no storage mechanism can flag the absence of an entry it never saw. That failure can only be prevented at capture time, which is why capture discipline belongs before sealing in any build order. What was recorded, when it was captured, from which source, and with what authority (the agent's self-report versus an independent read-back, a decision-time policy snapshot versus a link to the current policy) are data-model decisions. Cryptography can certify them. It cannot repair them.

What regulators actually require

None of the record-keeping rules discussed here orders companies to build Merkle trees, and they do not all ask for the same thing: the SEC asks for recoverability, NIST for integrity protection, the EU AI Act for traceable logging. What they share is the property the ladder exists to deliver: alteration that cannot pass silently.

The clearest example is the SEC's 2022 amendments to the electronic recordkeeping rules for broker-dealers. The older rule required write-once-read-many (WORM) storage. The amendments kept WORM as an option and added an audit-trail alternative: an electronic recordkeeping system qualifies if it maintains records in a manner that permits recreating an original record if it is modified or deleted, with a complete time-stamped record of who changed what and when. Both compliance paths are integrity postures. One prevents modification at the storage layer; the other makes every modification a first-class, attributable event.

AI-specific rules point the same direction without naming mechanisms. Article 12 of the EU AI Act requires high-risk AI systems to be designed to automatically record logs over their lifetime, with traceability appropriate to the system's purpose, and logging whose integrity cannot be demonstrated is weak traceability. For organizations under security frameworks, AU-9 and its cryptographic enhancement are already in the control set their auditors test against. The practical reading across all of them: pick the rungs of the ladder that match the stakes of the records, and be able to explain why.

How Pruvz approaches evidence integrity

Pruvz is a business evidence layer for AI agents, and its integrity model starts where this article argues the work starts: at the data model. Every consequential action's evidence packet is an ordered, append-only sequence. Sequence numbers are assigned atomically by the server, every piece of evidence carries a server-assigned trust level that separates the agent's own claims from independent system-of-record read-backs, and only the verification worker can assign a final verification result. A human review decision is appended as new evidence with its own place in the sequence; it never rewrites the verification result it reviews. Later facts cannot masquerade as earlier ones, and nothing in the packet is ever updated in place.

That data model is public. Here is the evidence sequence from the verified-refund example packet in the open schema repository, abridged to three of its six entries:

evidence items from verified-refund.packet.json in the packet schema repository (abridged: three of six entries, key fields shown)

"items": [
  { "sequence": 3, "type": "AGENT_CLAIM", "trustLevel": "CLAIMED",
    "source": "billing-refunds-agent",
    "summary": "Agent claims refund of USD 42.50 succeeded (REFUND_SUCCEEDED)." },
  { "sequence": 5, "type": "SOURCE_READBACK", "trustLevel": "INDEPENDENT_READBACK",
    "source": "billing-system",
    "summary": "Refund of USD 42.50 recorded as succeeded for payment pay_74001." },
  { "sequence": 6, "type": "VERIFICATION_RESULT", "trustLevel": "PRUVZ_DERIVED",
    "source": "pruvz-worker",
    "summary": "VERIFIED: exactly one succeeded refund of USD 42.50 matched payment pay_74001." }
]

The agent's claim is in the record, labeled CLAIMED, and it decides nothing. The billing read-back arrives under its own sequence number with an INDEPENDENT_READBACK trust level, and only the verification worker writes the VERIFIED result. The full example and the schema it conforms to are published in the open packet schema repository, and the evidence packet walkthrough shows a packet captured end to end in the product demo.

The cryptographic rungs above that foundation (content hashes, chained sealing, external anchoring) are on the Pruvz roadmap, and the packet model is designed so they certify a record whose capture discipline already holds. That order is deliberate. Sealing a record that embeds the agent's self-report as truth would be exactly the tamper-evident garbage described above; the append-only, trust-labeled, independently verified record is what makes the seal worth applying. The security page documents the current trust model and the planned controls in the same honest split.

Pruvz is inviting founding design partners to shape the evidence layer around real production agent workflows. If your agents already take consequential actions and your integrity story for their records today is "we trust our database", that gap is a good starting point for a design-partner conversation. For the wider picture of what belongs inside the record itself, start with what business evidence for AI agents is.

This article is general technical and governance information, not legal advice. Your obligations depend on your jurisdiction, industry, and specific use case.

Frequently asked questions

What is a tamper-evident audit log?

A tamper-evident audit log is a record store designed so that any alteration of a record after it is captured becomes detectable. It does not promise that alteration is impossible, which no operated system can honestly promise, since administrators hold privileged access to storage, backups, and deployments. Instead it layers mechanisms such as append-only ordering, cryptographic hash chains, Merkle tree proofs, and externally anchored digests so that a modified, deleted, or reordered record produces a visible inconsistency that reviewers and auditors can check for.

Are immutable audit logs enough for AI agents?

No. Immutability, where it is real, protects a record after capture: append-only ordering, hash chains, and external anchoring make later alteration detectable. None of those mechanisms establishes that the record was accurate when it was written. A log that faithfully preserves an agent's own unverified success report is immutable and still untrustworthy. Trustworthy AI agent evidence needs capture fidelity first, meaning independent verification against the system of record, a decision-time policy snapshot, and evidence labeled by source and trust level, and post-capture integrity second, so that the record, once right, stays provably unchanged.

What is the difference between tamper-evident and tamper-proof?

Tamper-proof means alteration is impossible; tamper-evident means alteration is detectable. Security practice and regulation are built around the second, because the first cannot be delivered by a system its operator administers: someone always holds root, signs the deploys, or controls the backups. NIST SP 800-53 control AU-9 reflects this posture by requiring audit information to be protected against unauthorized modification and deletion and requiring alerts when such modification is detected, with AU-9(3) adding cryptographic protection as an enhancement; its discussion gives signed hash functions as an example. A vendor claiming tamper-proof logs is overclaiming; the deliverable property is evidence that tampering did or did not occur.

Is an append-only database table enough to make records trustworthy?

It is the right foundation, and it is not the whole answer. Append-only ordering with server-assigned, strictly increasing sequence numbers ensures the application never updates or deletes records, makes the order of facts a checkable structural property, and makes the removal of an already-written record visible as a hole in the sequence. An entry that was never written at all is beyond any storage mechanism, including this one; only discipline at capture time closes that gap. What append-only ordering leaves open is the storage layer itself: an actor with direct access to the underlying bytes could rewrite history without the application noticing. Hash chains, verifiable log structures, and externally anchored digests exist to close that storage-layer gap.

How does a hash chain make an audit log tamper-evident?

Each entry embeds a cryptographic hash of the previous entry, so the entries form a chain in which modifying any record changes its hash and breaks every link after it. Given a trusted copy of the most recent link, a verifier can detect any alteration of past history. The design was worked out for exactly this purpose in Schneier and Kelsey's 1999 paper on secure audit logs, which showed how entries written before a system compromise can be protected from silent modification afterward. The known limit is wholesale recomputation: whoever controls the entire chain can rebuild a consistent forgery, which is why the chain head must be anchored outside the operator's control to carry full weight.

Do regulators require cryptographic sealing of AI agent logs?

None of the rules discussed here mandates a specific mechanism such as hash chains or Merkle trees. What they converge on is the property those mechanisms deliver. The SEC's 2022 amendments to its electronic recordkeeping rules for broker-dealers allow either write-once (WORM) storage or an audit-trail alternative that can recreate an original record after modification or deletion, with a complete time-stamped trail. Article 12 of the EU AI Act requires high-risk AI systems to be designed to automatically record logs over their lifetime for traceability. NIST SP 800-53 AU-9(3) names cryptographic protection of audit information as a control enhancement. The shared expectation is integrity that can be demonstrated, with the strictest regimes, like the SEC's, also requiring that the original state be recoverable; the specific mechanism is left to the organization.

Why can't cryptography alone make AI agent records trustworthy?

Because integrity mechanisms preserve content; they do not improve it. A hash chain over a record that repeats the agent's own success report, cites a policy by a link that now resolves to a newer version, or was reconstructed hours after the action simply preserves unreliable content immutably. Capture discipline has to come first: recording at decision and action time, labeling each piece of evidence by its source and trust level, preserving the decision-time policy, and verifying outcomes independently against the system of record. Cryptographic sealing is then worth applying, because it certifies a record that was reliable when captured.