--- title: "Glossary: Audit chain" canonical_url: "https://tokenobserve.com/glossary/audit-chain" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: Audit chain An audit chain is a record of administrative actions in which every entry carries a cryptographic digest computed over its own content and over the digest of the entry before it, so the entries form one linked sequence rather than a set of independent rows. Editing, reordering or removing an entry breaks that sequence at an identifiable point, which is what lets anyone recomputing the digests check the record’s integrity. ## Also called - hash-chained audit log - audit log chain - chained audit trail ## In practice The reason to chain an audit log instead of only appending to it is that the question to ask of one — who widened this permission, when, and did anybody edit the record afterwards — has to be answerable against your own administrators. An append-only table whose append-only property is enforced by the person being constrained is not a control: where the database is a file on that person’s disk, immutability asserted by configuration is a setting they can change and change back. Chaining does not stop them. It makes the change visible to anyone who later recomputes the digests, which is a weaker goal and an achievable one. An entry holds the facts of one administrative act — the actor, the action, the resource, a detail payload, a timestamp — plus a sequence number, the previous entry’s digest and its own. The digest input is the previous digest, a separator, and a canonical serialisation of the entry’s content with its own digest field excluded. Canonical means object keys sorted recursively and no whitespace, so one record has exactly one encoding and two honest parties compute the same value. Excluding the row’s own digest from its own input is not fastidiousness: include it and a verifier recomputing from a stored row would be covering a field the original write never covered, so every verification would fail. The first entry links to a fixed genesis value, conventionally sixty-four zeros, and appends read the current tip and write the new entry inside the same transaction, so two concurrent writers cannot fork the chain. Verification walks the chain and reports three distinct classes of failure, located rather than merely raised. A link mismatch means an entry no longer carries its predecessor’s digest; that is what a deletion from the middle looks like, because the row after the hole still points at something that is no longer there. A content mismatch means an entry was altered. A sequence gap means a row was removed, including a missing prefix: deleting entry 1 and recomputing the remainder from genesis would otherwise leave a chain that begins at 2 and checks out link by link. Sequence numbers should come from a counter that an ordinary delete does not lower, so a removal leaves a hole that no amount of re-hashing can close, and the result should name the first sequence at which the chain breaks. The difference between an investigation and a shrug is that number. Two consequences shape how the chain gets used. Verification is linear in the length of the chain and gets slower every day, which is managed by walking in bounded chunks that yield to other work, caching a verdict for a few seconds and refusing to run overlapping walks — not by pretending the cost is not there. And entries cannot be edited afterwards, which is the design working and is also a constraint on what belongs in them: an erasure that touches a detail field breaks verification from that sequence onward. Keep the chain to governance-plane facts — an agent registered, a permission widened, a kill switch engaged, an approval decided, an evidence bundle exported — and keep request payloads in a separate table with no foreign key between them. That separation is what lets a data subject’s records be deleted while chain verification still passes, and what lets the record that a deletion happened outlive the deleted data. What the chain does not do should be stated in the same breath as what it does. On its own it is evidence only against a party who cannot recompute it; whoever can write every row can rewrite an entry and re-hash everything downstream, and the result verifies clean. Truncation with nothing appended afterwards leaves every remaining link intact, so a shortened chain also verifies clean, and nothing inside the store can fix that: the length has to have been attested somewhere the same operator cannot edit. A chain is not a Merkle tree either: there are no inclusion proofs, so a verifiable subset cannot be handed to a regulator without handing over the rest of the log. ## Example: The row that was meant to disappear An administrator raises an agent’s spend ceiling at 02:14, runs it, and deletes the entry recording the change. The rows either side are untouched, so reading the table shows nothing obviously missing. A verification walk reports valid false, broken at sequence 42, reason: entry 42’s previous-hash does not match the entry before it, because entry 42 still carries the digest of an entry that is no longer in the table. Had the deleted row been the last one, and had anything been logged afterwards, the same walk would have reported a sequence gap instead, because the counter does not roll back on a delete. Neither result says who deleted it. Both say that something was deleted and exactly where, which makes the next question a specific one. ## Routinely confused with Append-only log: Append-only is a property of the storage — writes add rows, nothing updates or deletes — and it is enforced by whoever administers that storage. A chain is a property of the records themselves, checkable by anyone holding a copy, including against the administrator. They are complementary: append-only storage makes alteration inconvenient, chaining makes it visible. Blockchain: A blockchain is a hash chain plus replication and consensus, which puts the record in the hands of parties who do not trust one another. Remove the consensus and what remains is the chain — one writer, one copy, and integrity that has to be exported to somebody else before it constrains the writer. Trace or request log: A trace records what an agent did on one request. The audit chain records changes to the rules that request was judged against. Keeping them in separate tables is deliberate, because the trace is the part you may be required to erase and the chain is the part that must survive the erasure.