What Is a Tamper-Evident Audit Log? HMAC Hash Chains Explained

When someone asks “what did your AI agent actually do, and how do we know the log was not edited?”, ordinary logs do not have a good answer. A tamper-evident audit log does. This article explains, in plain terms, what tamper-evidence means, how an HMAC-SHA256 hash chain provides it, and why it matters for anyone running autonomous agents.

Ordinary logs vs. tamper-evident logs

Most application logs are just rows in a database or lines in a file. Anyone with access can edit, delete, or reorder them, and there is no built-in way to detect that it happened. For debugging, that is fine. For audit, proving to finance, a customer, or a security reviewer what really occurred, it is not. If a log can be silently changed, it is not evidence.

A tamper-evident log is designed so that any change to a past record is detectable. You may not be able to stop someone with database access from trying to alter a row, but the structure guarantees the tampering will show up when the log is verified.

The building blocks: hashing and HMAC

A cryptographic hash (like SHA-256) turns any input into a fixed-size fingerprint. Two properties matter: it is deterministic (the same input always produces the same hash), and it has an avalanche effect (change one character and the hash changes completely). So if you store the hash of a record, you can later re-hash the record and check it matches; if someone edits the record, the re-computed hash will not match the stored one.

A plain hash has a weakness for audit: if an attacker can edit a record, they might also recompute and replace its hash. HMAC (Hash-based Message Authentication Code) fixes this by mixing a secret key into the hash. Without the secret, you cannot produce a valid HMAC for altered data. HMAC-SHA256 is HMAC built on SHA-256, a widely trusted, standard construction.

Chaining: making the whole history tamper-evident

Here is the key idea. Instead of hashing each record independently, you chain them: each record’s HMAC includes the previous record’s HMAC as part of its input. Record one is hashed with an empty predecessor, record two’s hash mixes in record one’s hash, record three’s mixes in record two’s, and so on.

Because each link depends on the one before it, editing record two changes its hash, which changes record three’s, and so on, every hash after the edited record breaks. To hide a change, an attacker would have to recompute the entire chain from that point forward, which requires the secret key. That is what makes the log tamper-evident: a single altered entry invalidates everything downstream, and verification catches it immediately. This is the same principle behind blockchains and Certificate Transparency logs, minus the distributed consensus.

Why this matters for AI agents

Agents act autonomously and spend real money. Sooner or later finance asks what you spent on AI, by agent, last month; a customer asks you to prove what your agent did with their data; and security or compliance asks for an audit trail that cannot have been edited after the fact.

If your logs are mutable rows, your honest answer is “trust me.” With a tamper-evident chain, your answer is “here is an export you can verify, the math will tell you if a single record changed.”

How KeyForge implements it

Every call through the KeyForge gateway is written to an HMAC-SHA256 tamper-evident audit chain. You can verify the chain at any time (the system re-computes the links and confirms integrity), export the audit trail for your records, and share a read-only report via a link so a customer or reviewer can see exactly what ran, without access to your account.

Combined with per-agent virtual keys and per-key spend caps, that means you can answer who, what, and how much, and prove it, for every agent. Tamper-evident does not mean tamper-proof: it means tampering is detectable. Prevention is about access control; evidence is about detection. You want both. See a live audit report and start free, no credit card.