Every compliance regime, sooner or later, comes down to a question of trust in records. An auditor doesn't watch your systems run in real time. They read what your systems wrote down and ask: can I believe this? If the answer depends on "well, our admins promise they didn't edit the logs," you don't have evidence. You have an assertion. And assertions are exactly what audits exist to test.
This matters more, not less, in the agentic era. When AI agents take actions on real systems, moving data, changing records, spending money, the log of what they did is often the only artifact a human ever reviews. Nobody watched the agent work. The record is the accountability. So the integrity of that record becomes the whole ballgame. This post explains, without assuming any cryptography background, what makes an audit log tamper-evident: how SHA-256 hash-chains and WORM storage work, and why they let you prove your logs haven't been quietly rewritten.
First, a smaller question: what's wrong with normal logs?
Most systems log to a file or a database table. Useful for debugging, weak as evidence, for one reason: ordinary logs are editable. Anyone with sufficient access can change a line, delete an entry, or insert a fake one, and the log itself gives no sign it happened. The record looks identical whether it's pristine or doctored.
For an auditor, "trust us, nobody touched it" is not a control. The threat isn't only a malicious insider. It's also the ordinary possibility that something altered the record (a bug, a botched migration, a cleanup script) and nobody noticed. A trustworthy audit log needs a property ordinary logs lack: if anyone changes anything, it becomes obvious. Not prevented, necessarily, but unmissable. That property is tamper-evidence, and you build it from two simple ideas.
Idea one: a hash is a fingerprint
A hash function takes any data (a sentence, a file, a log entry) and produces a fixed-length string of characters called a hash. SHA-256 is a specific, widely used, well-vetted hash function; the "256" is the size of its output in bits, written as 64 hexadecimal characters.
Three plain-English properties are all you need:
- Same input, same hash, every time. Hash the exact same data and you always get the exact same fingerprint.
- Tiny change, totally different hash. Change one character (one letter, one digit, a single flipped bit) and the resulting hash looks completely unrelated to the original. There's no "close." It's either identical or visibly different.
- You can't run it backwards. Given a hash, you can't reconstruct the original data, and you can't realistically craft different data that produces the same hash. (This is what cryptographers call collision resistance; you don't need the math, just the consequence.)
Put those together and a hash is a tamper detector for a single piece of data. Record the hash of a log entry, and later anyone can re-hash the entry and compare. Match: the entry is byte-for-byte what it was. Mismatch: it changed. The fingerprint gives away any edit, no matter how small.
But a hash per entry only protects each entry in isolation. An attacker could change an entry and recompute its hash, or simply delete an entry and its hash together. We need to protect the sequence, the order and completeness of the whole log. That's the second idea.
Idea two: chain the fingerprints together
A hash-chain links entries so that each one's fingerprint depends on the one before it. The recipe:
When you write a new log entry, you compute its hash over the entry's data plus the hash of the previous entry.
So entry #5's fingerprint isn't just a fingerprint of entry #5. It's a fingerprint of entry #5 combined with entry #4's fingerprint. And entry #4's fingerprint already folded in entry #3's, which folded in #2's, all the way back to the first entry. Every link carries the entire history forward inside it, like a single thread running through every bead.
Now consider an attacker who wants to quietly alter entry #5. Changing it changes entry #5's hash (property two: tiny change, totally different hash). But entry #6's hash was computed using entry #5's original hash, so entry #6 no longer lines up. To hide the edit, the attacker must recompute #6, which breaks #7, which breaks #8, and so on to the end of the log. One change forces every subsequent link to be rewritten. Deleting an entry breaks the chain at that point too, because the next entry's hash referenced the one that's now missing.
This is what makes the log tamper-evident. You can't change history in one quiet place. You'd have to rewrite the entire chain from the edit point forward, consistently, and if anyone has recorded a later hash somewhere the attacker can't reach (a separate system, an auditor's copy, a periodically published checkpoint), even a full rewrite gets caught the instant the chains disagree. Verifying the whole log is mechanical: walk it from the start, recompute each link, confirm every one matches. Any break points straight at where, and roughly when, tampering occurred.
Idea three: WORM, make editing impossible in the first place
Hash-chains make tampering detectable. WORM (Write Once, Read Many) aims to make tampering impossible at the storage layer. WORM storage accepts data once and then physically refuses to overwrite or delete it for a defined retention period. The record can be read as often as you like but never changed. Many cloud object stores offer this as an immutability or object-lock setting, and regulated industries have used WORM media for decades precisely because regulators trust storage that can't be edited over storage that merely shouldn't be.
Hash-chaining and WORM are complementary, and together they're strong. WORM stops the edit from happening; the hash-chain proves it didn't (and would expose it if the storage guarantee ever failed). Belt and suspenders: one prevents, the other detects. An auditor reviewing a log that is both WORM-stored and hash-chained has two independent reasons to trust it, which is a far cry from "our admins promise."
What good looks like
For a security or compliance audience evaluating an audit system, the bar:
- Append-only and immutable. Records are written once and can't be edited or deleted within the retention window. WORM-backed, not a mutable table.
- Cryptographically chained. Each entry's hash incorporates the previous entry's hash, so any change or deletion breaks verification from that point on.
- Independently verifiable. Anyone with the log can re-walk the chain and confirm integrity without trusting the operator, ideally against an external checkpoint the operator can't alter.
- Complete, including denials. A log that only records successes is a marketing reel. The actions you blocked are often the most important evidence: that the agent tried to write to production and was stopped is exactly what proves the controls worked.
- Attributed. Each entry names which principal did what, and with agents as first-class identities, that means the specific agent, not a shared service account.
- Scoped per tenant. In a multi-tenant system, each tenant's chain stands on its own, so one customer's record is cryptographically separate from another's.
The throughline: the log should be trustworthy by construction, not by promise. An auditor shouldn't have to take anyone's word for it. The math and the storage should make tampering either impossible or unmissable.
Where the record comes from
This is the foundation under Cytra's framing that compliance is a record of how your AI runs. Every tool call that flows through the gateway (the policy decision, the credential brokered, the sandboxed execution, and crucially the denials) is written to a per-tenant, tamper-evident audit log built on a SHA-256 hash-chain with WORM-style write-once retention. Because agents are first-class principals, each entry is attributed to the specific agent that acted, and because the chain is per tenant, records are cryptographically isolated. The goal is a record an auditor can verify independently rather than trust on faith. For compliance officers and security architects, plainly: the Cytra gateway and these capabilities are in private beta, not GA, and the platform is designed to be aligned and audit-ready, not certified. SOC 2 Type II and a HIPAA BAA are in process, not granted.
Takeaway: an audit-integrity checklist
When you evaluate any system that claims a trustworthy audit trail, ask:
- Is it append-only and immutable (WORM-backed), or just a table someone with access can edit?
- Is it hash-chained, so any single change breaks verification from that point forward?
- Can it be verified independently, without trusting the operator, ideally against an external checkpoint?
- Does it record denials, not only successful actions?
- Is every entry attributed to a specific principal, including individual agents?
- Is it scoped per tenant, so records are cryptographically isolated?
You don't need to be a cryptographer to hold an audit log to this standard. You need two simple ideas (fingerprints that change when the data changes, chained so the whole history is locked together) plus storage that won't let the edit happen at all. Get both, and "trust us" becomes "verify it yourself." In a world where nobody watched the agent work, that difference is the entire point.