Agent Flight Recorder

Blog · ← All posts

Hash-Chained Logs: Why Tamper-Evidence Matters for Agent Audit Trails

By the Ingenious AI team · Last updated: October 13, 2026 · 7 min read

Illustrative scenarios: the incidents in this post are composites of real failure patterns, with names, numbers, and details changed. No real company or customer is depicted.

A procurement agent at a mid-size distributor wired $12,400 to the wrong vendor. The finance lead pulled the agent's logs, which showed the agent had followed its instructions: the vendor record in the database had the wrong account number, and the agent used what it was given. Clean story. Except the operations manager didn't believe it. His exact words: "How do I know you didn't edit the log after the fact?"

Nobody had edited anything. But he had a point, and it's the point this whole post is about: when an agent touches money, data, or anything a regulator cares about, a log that could have been edited is not evidence. It's a memo. And memos don't settle disputes.

The problem with ordinary logs

Almost every agent in production today logs to something editable. A Postgres table. A cloud logging service. A JSON file on a server. All of them share one property: someone with enough access can change a row, and nothing in the system will complain.

That's fine for debugging. You want to be able to prune, annotate, and reorganize debug logs. But the moment the log is the record of record: the thing you show the auditor, the customer, or the court, editability becomes a liability. Consider the scenarios:

None of these require malice to be a problem. They just require the possibility of editing. Doubt is enough to sink a log's value as evidence.

What hash-chaining actually does (no jargon)

Here's the whole mechanism, plainly: every record in the ledger carries a fingerprint of the record before it. Record #47 contains its own data plus the fingerprint of record #46. Record #48 contains the fingerprint of #47. And so on, back to the first record.

The fingerprint is a one-way computation (SHA-256): easy to compute forward, impossible to reverse. Change one character in record #46 and its fingerprint changes. That breaks record #47's stored fingerprint, which breaks #48's, and so on down the line. The tampering is visible not because anyone caught it happening, but because the math no longer adds up.

Verification is one click: recompute every fingerprint, check every link. Pass or fail, with the exact record where the chain broke if it failed. A junior analyst can do it. An auditor can do it. The vendor's customer can do it.

Two properties matter here, and they're different:

You want both. Append-only without hash-chaining is a rule nobody checks. Hash-chaining without append-only is math on a system that lets you rewrite history anyway.

What this buys you, concretely

Back to the $12,400 wire. The distributor's team had the agent's actions in a hash-chained ledger. The operations manager's question ("how do I know you didn't edit the log?") got an answer that wasn't anyone's word: a verification run, right there in the meeting, that recomputed the chain and passed. The log showed the agent called initiate_wire with the account number pulled from the vendor record, and the vendor record's value was logged too. The dispute moved from "did you doctor the evidence" to "the vendor data was wrong", which was the actual problem, and got fixed the same day.

That's the pattern. Tamper-evidence doesn't prevent incidents. It short-circuits the second incident — the one about whether the record can be trusted — which is often the one that costs more. Postmortems go faster when nobody is defending the log's integrity. Customer disputes settle faster when the record is verifiable. Audits go faster when the auditor can check the math themselves instead of interviewing your engineers.

Where it breaks (honest version)

Hash-chaining proves the ledger wasn't altered after records were written. It says nothing about what happened before a record was written. If the agent lies in its reasoning field, the chain faithfully preserves the lie. If a compromised agent writes false records, the ledger is a tamper-evident record of falsehoods. Garbage in, cryptographically sealed garbage out.

It also doesn't prove completeness. The chain proves that every record in the ledger is intact and in order; it can't prove that a record wasn't simply never written. If the agent does something and fails to log it, the chain has no opinion. That's why the recording has to happen in the harness, on the critical path of every tool call, not as an optional callback the agent can skip.

And one more: hash-chaining is not a substitute for access control. The ledger should still live behind authentication, with write access limited to the recording service. The chain is your backstop for the case where access control fails or is bypassed: not a replacement for it.

Run a verification yourself

The "one click" claim deserves a look under the hood, because it's the whole reason the math works as evidence. Verification is just this, repeated for every record:

for record in ledger:
    expected = sha256(record.data + record.prev_hash)
    assert expected == record.hash, f"chain broke at record {record.seq}"

That's the entire algorithm. No keys to manage, no certificates to renew, no blockchain. Anyone with read access to the ledger and a SHA-256 implementation can run it: a Python snippet in a notebook, a button in the dashboard, an auditor's own script. The first record's prev_hash is a fixed genesis value so the chain has a known starting point.

One subtlety worth knowing: verification is O(n). For a ledger with ten million records, a full re-verification takes real time — minutes on ordinary hardware, not milliseconds. The practical pattern is verifying incrementally: check each new record as it's written, and run full-chain verification on demand (incident review, audit, dispute). The expensive check only runs when someone's actually asking the hard question, which is exactly when you want it to be cheap to trust.

A second subtlety: the verifier needs to be independent of the writer. If the same service that writes the records is the only one that verifies them, you're back to "trust us" with extra steps. Export the ledger to the auditor. Let them run their own implementation. The math doesn't care whose script does the arithmetic — that's the point.

When you need this

Not every agent needs a tamper-evident ledger. A personal coding assistant writing boilerplate doesn't. The test is simple: would you ever need to prove what the agent did to someone who doesn't trust you? If the agent moves money, touches customer data, makes commitments on your behalf, or operates in a regulated space, the answer is yes, and plain logs won't carry that weight.

When we built the recorder, the hash chain was the first feature, not the last. Everything else (the replay view, the anomaly alerts, the audit reports) sits on top of a ledger whose integrity doesn't depend on anyone's good behavior. Because the incident that matters is never the one where everyone trusts each other. It's the 6 AM meeting where they don't.

Start logging your agents free → The free tier includes the full hash-chained ledger and one-click chain verification: the integrity proof, not just the logs.