Tamper-evident tamper-proof: what an agent audit log can actually prove
Description and use
A developer learns that Agenthof's audit log provides genuine tamper-evidence for committed events via hash-chaining, but is not tamper-proof: truncation-and-re-forge is solved for the governance ledger via external transparency-log anchoring, solved for per-run receipts only via manual --expect-head comparison, and completeness (missing events) is in design, not shipped.
Problem
How much can a developer trust an append-only hash-chained audit log produced by an AI agent gateway, and which guarantees are genuinely shipped versus still in design?
Outcome
The developer learns that agenthof audit verify provides genuine tamper-evidence for committed events (hash chain integrity), but the audit log is not tamper-proof: truncation-and-re-forge is solved for the governance ledger via automatic external anchoring to a named transparency log, solved for the per-run receipt only via manual --expect-head comparison, and completeness (missing events) is in design not shipped.
Workflow
- Run
agenthof audit verify <run>to walk the hash chain and confirm any edit/deletion/reordering breaks the chain - Check
audit verify controlagainst the governance ledger's recorded anchors for third-party detection of root rewrite - For per-run receipts, save the printed head and later run
agenthof audit verify --expect-head sha256:<hex>to compare against an off-machine head - Do not assume completeness is guaranteed; a missing event leaves no cryptographic signature, so detect it via accounting (ingress call count vs ledger event count) rather than crypto
Evidence
Open any 'AI agent governance' page and you'll find the phrase 'tamper-proof audit log'. Treat it as a tell. No append-only file on a machine someone administers is tamper-proof, and a vendor who says otherwise is either not thinking hard about it or hoping you won't.
That gives you one real, strong guarantee: any edit, deletion, or reordering of a committed event breaks the chain and fails verify.
So the honest scorecard on truncation: solved for the governance ledger (independent anchor, today), and for the per-run receipt it's the manual --expect-head path — bringing automatic anchoring to the per-run receipt is reserved, not yet built.
today sequence numbers catch a dropped tail, and containment means a governed action has to pass through a recording door — but detecting a silently dropped door event is in design, not shipped.
Independence comes from where the record is anchored, not from the gateway being neutral — because it isn't neutral, and claiming it is would be the same move as 'tamper-proof.'
- Record date: 2026-10-23T03:11:52.714Z