Guides · Audit & evidence
The first serious question after any agent incident is "show me exactly what it did." A plain log file answers that question only if nobody — including you, including an attacker who got in — could have edited it afterwards. Hash chaining is the cheap, old, proven trick that makes edits visible. Here is what to record, how the chain works with real numbers, and how to use it when something goes wrong.
By Ingenious AI · Published 1 November 2026
An audit entry earns its storage if, months later, it lets a stranger reconstruct the event. For each agent action, record:
Two design rules matter more than field lists. First, write the entry before or as the action executes, never reconstructed after the fact — a log written from memory is a story. Second, the agent must not hold the pen alone: entries should land in a store the agent itself cannot rewrite, or every guarantee below evaporates.
A hash chain links each entry to the one before it. Entry n stores a SHA-256 hash computed over its own contents plus the hash of entry n−1. Change anything in an old entry and its hash changes — which breaks the link stored in the next entry, which breaks the next, all the way to the present. Tampering does not become impossible; it becomes evident, and it forces the tamperer to rewrite every subsequent entry and every external copy of the chain head.
A minimal three-entry chain (hashes abbreviated for print; the real values are 64 hex characters):
Now suppose someone edits Entry 2 to read $380.00 instead of $38.00. Recomputing Entry 2's hash over the edited content yields a different value than 41bd…07 — but Entry 3 already stores 41bd…07 as its prev-hash. The chain fails verification at exactly the edited link. To hide the edit, every later entry must be recomputed — and if you periodically anchor the chain head somewhere outside the system (an emailed digest, a second store, a timestamping service), even a full rewrite is detectable, because the anchored head will not match. Verification itself is a five-line script: recompute, compare, walk. Run it on a schedule and after every incident, and log the verifications too.
A trustworthy trail changes three conversations. Incident review: when an agent does something costly — the scenario our prompt-injection guide walks through — the chain tells you which instruction the agent followed, which tool calls it made, and which approvals it collected, in order, with the literal arguments. You are debugging facts, not recollections. Customer and auditor questions: "who approved this charge?" becomes a lookup with a name, a timestamp and a hash, not an apology and a search party. Forensics after the fact: even logs from agents you did not chain at write time can be mined — patterns like credential grabs, forged tokens, scope escapes and unexpected wallet touches are recognisable in raw action logs, which is the post-hoc analysis BoundaryVault performs before assembling a disclosure packet.
Our own implementations: Agent Flight Recorder keeps hash-chained audit logs of agent actions so any decision can be replayed and proven, and Agentic Receipts applies the same sealing to approvals — approver, agent, amount and declared scope, chained before the agent acts, which is the moment the record has to exist to mean anything.