How to Make Your AI Agent Audit Trail Tamper-Evident

The most common “audit trail” for an AI agent is a database table the application writes to with a plain INSERT. It is better than nothing, and it is not evidence. The problem is simple: the same credentials that write the log can rewrite it. A row you can UPDATE or DELETE tells an auditor what the database currently says happened — not what actually happened. There is no way to distinguish an untouched history from one that was quietly edited after an incident.

For agent decisions, that gap matters more than for ordinary logs, because the stakes are actions: a payment that moved, a record that was deleted, an email that went out. When a security review or a regulator asks you to prove that every agent action was policy-approved or human-reviewed, “here is our logs table” is not an answer. “Here is a record you can verify yourself, and here is the math” is.

Tamper-evident is not the same as tamper-proof. You cannot always stop someone with deep access from attempting to change history. What you can do is guarantee that any such change is detectable — that the record carries its own proof of integrity. Three properties, together, get you there:

• Append-only. The store physically rejects updates, deletes, and truncation. New events can be added; existing ones cannot be changed or removed.
• Hash-chained. Each event embeds a hash of the previous event, so the records form a chain in which any alteration cascades.
• Independently verifiable. A third party can re-compute the chain from the data and a public key, and confirm it — without trusting the system that produced it.

Drop any one and it stops being an audit trail. Append-only without chaining can be bulk-replaced. Chaining without append-only can be re-chained. Either without independent verification asks the auditor to take your word for it — which is the one thing an audit exists to avoid.

The mechanics are not large, but the order and the details matter. This is the build, step by step.

1. 1

   Make the event store append-only at the database

   Enforce it where the data lives, not in application code that a bug or a console can bypass. In Postgres, that is triggers that raise on UPDATE, DELETE, and TRUNCATE against the events table. If a delete fails there, that is the protection working.

2. 2

   Serialize each event canonically

   A hash is only stable if the bytes are stable. Define a canonical serialization — a fixed set of fields, in a fixed key order — so the same logical event always produces the same string. Without this, two correct systems compute two different hashes and verification is meaningless.

3. 3

   Chain each event to the previous with SHA-256

   Compute each event’s hash over the previous hash plus the canonical event, per tenant. Now every hash depends on all history before it.

4. 4

   Anchor the arguments by hash — never store raw PII in the chain

   Include a hash of the approved arguments in the chained payload, not the arguments themselves. This binds “these exact arguments were approved” into the chain while letting you null the raw personal data later for a GDPR erasure request without breaking verification.

5. 5

   Sign exports so they verify offline

   Let anyone export the chain with an Ed25519 signature over the exact canonical bytes. The signature is what makes the export verifiable away from your database, by a party who does not trust you.

6. 6

   Verify continuously, and let others verify too

   Provide a function that walks the chain and returns OK or the first event whose hash does not match. Run it on a schedule, and publish it so a customer or auditor can run it themselves.

# Per tenant, for each event n:
hash[n] = SHA-256( hash[n-1] || canonical(event[n]) )

# canonical(event) = a fixed-field, fixed-order serialization
# event payload contains a HASH of the approved args, not the raw args

# Verify online — returns OK, or the id of the first broken event:
SELECT * FROM pliuz_verify_chain();

The EU AI Act (Regulation (EU) 2024/1689) is the concrete forcing function behind a lot of audit-trail work right now. The relevant parts for agent decisions:

• Article 12 — Record-keeping. High-risk AI systems must technically allow the automatic recording of events (logs) over the lifetime of the system, to ensure a level of traceability appropriate to its purpose.
• Article 14 — Human oversight. High-risk systems must be designed so humans can effectively oversee them, including the ability to intervene or interrupt — which is exactly what a runtime approval gate provides.
• Article 26 — Deployer obligations. Deployers of high-risk systems must, among other things, keep the logs the system generates.

Here is the part vendors rarely say: hash-chaining a log is becoming table stakes. Standards bodies are working to standardize chained, verifiable logs; audit-only products already market the same SHA-256 framing; the technique is well understood. If your entire pitch is “we hash our logs,” that is not a durable difference.

The difference that lasts is the combination: a record that is verifiable and a gate that blocks the action before it executes — so you are not only documenting what an agent did, you are deciding whether it gets to. Add EU data residency and a clean answer to the erasure test, and you have something an audit-only logger cannot match. A tamper-evident trail tells you the truth about the past; pairing it with a runtime gate lets you change the future.

The whole point of a tamper-evident trail is that you do not have to trust the vendor — including us. With Pliuz there are two paths. Online, call pliuz_verify_chain() and it returns OK or names the first broken event. Offline, export the chain as Ed25519-signed JSONL and run the open-source verifier: the server emits the exact canonical bytes it hashed, the signature covers them, and the verifier checks sha256(prev || canonical) against each stored hash. Pin the signing key through an independent channel — a key shipped inside its own export proves consistency, not identity.

That is the bar to hold any vendor to, ours included: not “we keep good logs,” but “here is the record, here is the public key, verify it without us.”