A Hash Chain Is Not Evidence: Where Agent Audit Logs Have To Live

A Hash Chain Is Not Evidence: Where Agent Audit Logs Have To Live

Teams are adding hash chains to their agent audit logs and treating the problem as solved. Each record carries the hash of the one before it, so changing a record breaks every link after it. But anyone holding the log can edit a record, work out fresh hashes for everything after it, and the log will still verify. A chain shows that the records agree with each other. It does not show they are the records written at the time. That is a point about what the control proves, not about anyone’s honesty.

What the regulation actually asks for

Under the EU AI Act, Article 12 says high-risk systems must be able to keep records automatically, and Article 19 says providers have to hold those logs for “at least six months, unless provided otherwise in the applicable Union or national law”.

The deadline has moved. The Digital Omnibus, in force since July 2026, pushed the high-risk duties back to 2 December 2027 for Annex III systems, and to 2 August 2028 for AI built into regulated products. That buys time rather than letting anyone off, and financial firms get no such wait at all.

Neither says how. The closest thing to a format is the Agent Audit Trail Internet-Draft, which describes a JSON record with SHA-256 hash chaining and optional ECDSA signatures. It is an individual draft, “not endorsed by the IETF” with “no formal standing”, and it says nothing about where records are kept.

A mutable database cannot hold evidence

Agent tracing tools tend to keep traces in databases like Postgres and ClickHouse, which are built to be changed, and their retention features delete. Langfuse’s data retention docs put it plainly. “On a nightly basis, Langfuse selects traces, observations, scores, and media assets that are older than the configured retention period and deletes them.” And “Deleted assets cannot be recovered.”

That is a sensible design for observability, where old traces cost money long after they stop earning it, and their own advice for keeping data longer is to export it to blob storage. Holding evidence is a different job.

The two things a chain needs

Write-once storage stops anyone rewriting the chain later, including you.

  • Amazon S3 Object Lock in compliance mode means a protected object version “can’t be overwritten or deleted by any user, including the root user in your AWS account”. It needs S3 Versioning turned on, and Cohasset Associates assessed it for SEC 17a-4, CFTC and FINRA environments. Read that warning literally. “The only way to delete an object under the compliance mode before its retention date expires is to delete the associated AWS account.”
  • Azure immutable blob storage does the same thing. “While in a WORM state, data can’t be modified or deleted for a user-specified interval.” You get time-based retention and legal holds, and a time-based policy has to be locked before it counts.
  • Google Cloud Storage has Bucket Lock, where “Locking a bucket’s retention policy is an irreversible action.”

External anchoring fixes the state of the chain somewhere you cannot reach. Publish the newest digest on a schedule to a public transparency log such as Sigstore’s Rekor, or have it signed by an RFC 3161 timestamping authority. A rewritten chain no longer matches what you published, and anyone can check that without taking your word for it. Neither is a legal guarantee, but both turn a log you vouch for into one a stranger can test.

The cautionary tale

Amazon QLDB was a purpose-built immutable ledger with cryptographic verification. It reached end of support on 31 July 2025, and AWS pointed customers at Aurora PostgreSQL, which has audit logging and retention but cannot prove anything cryptographically. The reason was never explained publicly, and the erasure has been thorough. At the time of writing, aws.amazon.com/qldb/ serves the Aurora page and the QLDB developer guide returns 404.

Evidence has to outlive the vendor who sold you the tool, so build on ordinary parts that nobody can discontinue, like object storage, SHA-256 and a public log.

QLDB is worth understanding precisely, because it is often misremembered. It was not a blockchain and never claimed to be. It was a centralised ledger with a Merkle tree journal, and you verified a record by checking a proof against a digest QLDB computed for you. That catches tampering only if you kept your own copy of an older digest, because the service published them nowhere. The cryptography was sound. The anchoring was left to the customer, which is the gap this whole post is about.

What to do about it

  1. Find where your agent logs live today and read their retention settings.
  2. Write chained records, or periodic batches of them, to a locked write-once bucket on the cloud you already use.
  3. Publish the newest digest on a schedule to a transparency log or a timestamping authority, and keep the receipts beside the logs.

None of this makes a deployment compliant. That is a question for your lawyers. A hash chain does catch accidents and careless edits. What it cannot do is prove anything to someone who has no reason to trust you. Write-once storage, and an anchor held by somebody else, are what turn a consistent log into evidence.