Most AI agent logging answers "what did the agent do?" A timestamped row says the agent called send_emailat 14:32:07 with certain arguments. That's useful for debugging. It's not useful for an audit, because it doesn't answer the harder question: how do you know that row is what actually happened, and not what someone edited it to say afterward?
The gap between logging and evidence
A standard database table has no built-in resistance to a row being updated or deleted after the fact, by a bug, a well-meaning engineer cleaning up an embarrassing incident, or an attacker covering their tracks. If your only proof an agent behaved correctly is a row in a table anyone with write access could have changed, that proof doesn't hold up to scrutiny. This is exactly the gap regulators are pointing at when they ask for auditable records rather than logs.
How hash-chaining closes it
Hash-chaining is a simple idea borrowed from how blockchains and Git both guarantee integrity: each event stores a cryptographic hash of the event before it. Change a single byte in an old event, and its hash no longer matches what the next event recorded. Every event after the tampered one fails verification the next time anyone reads the chain.
Concretely: if you edit event #14 in a 4,471-event session log, re-verifying the chain doesn't just flag event #14. It flags every event from #14 through #4471, because each one's stored hash depends on the one before it. There's no way to make a silent, localized edit. Tampering anywhere breaks the chain visibly, from that point forward.
Why "we didn't edit it" isn't enough
For an internal debugging trace, trusting your own team not to have tampered with a log is reasonable. For a compliance audit, it isn't, the entire point of an audit is that a third party doesn't have to take your word for it. Hash-chaining closes one specific gap: nobody, including someone with ordinary write access to the log, can edit a row without every event after it failing verification. It doesn't by itself remove trust in whoever hosts the database, that requires a separate, independent witness (for example, periodically anchoring the chain's state somewhere the vendor doesn't control) so a third party can check integrity without taking the vendor's word for it either.
What to check in your own logging
- Can any single row be edited or deleted without affecting anything else in the log?
- If so, is there any independent way to detect that it happened?
- Would your current setup survive an auditor asking "how do I know this log is complete and unaltered?"
- Is the answer verifiable by someone who doesn't have to trust the vendor's own database, or only by the vendor?
If the answer to the last question is "you'd have to trust us," hash-chaining narrows that gap, tampering becomes visible instead of invisible, but doesn't close it fully until the log is also anchored outside the vendor's own infrastructure.