AI agent audit trails: what makes a log hold up as evidence

Why ordinary logs fail under audit

Ask a simple question of a typical AI activity log: how would a third party know this row was written on the date it claims, and has not been modified since? For most systems the honest answer is that they would have to trust the operator.

That is acceptable for debugging and inadequate for compliance. If the record is the basis of a regulatory claim, its integrity has to be demonstrable by someone who has no reason to trust you.

How hash chaining works

Each entry stores a cryptographic digest computed over its own content and the digest of the entry before it. The entries form a chain in which every link commits to the entire history preceding it.

Change a value in entry 400 and its digest changes. Entry 401 committed to the old digest, so it no longer matches, and neither does every entry after it. There is no way to alter one historical record without rewriting the entire tail of the chain.

Bulwark uses HMAC-SHA256 over a canonical JSON serialisation, so the digest depends on content rather than formatting, and two systems computing it independently agree.

The part that matters: independent verification

A chain you can only verify with the vendor's own software is a weaker claim than it appears — you are still trusting the vendor, one level removed.

The stronger property is a verifier that re-implements the hash rule from the published specification rather than importing product code, and that runs with no dependency on the vendor at all. An auditor can then take an exported bundle and confirm the trail is intact without running, or trusting, anything of ours.

This is also what protects the customer if the vendor disappears. Evidence that requires a live vendor to verify is evidence with an expiry date.

What to record

Integrity is worthless over an incomplete record. At minimum, each governed action should capture:

• The agent identity and the human or system on whose behalf it acted.
• The action attempted and the resource involved.
• The verdict — allowed, escalated, denied — and the specific rule that produced it.
• For escalations, the reviewer, their decision and their recorded reason.
• A timestamp and the chain digest linking it to everything before.

The tension nobody mentions

An append-only chain is in genuine tension with the right to erasure. You cannot delete one record from the middle without breaking the chain, which is precisely the property that makes it evidence.

The practical resolutions are to minimise what enters the chain in the first place — store metadata about actions rather than their content — and to scope erasure at the tenant level rather than the record level. Any vendor claiming to offer both per-record deletion and an intact chain is describing something that does not hold.