Loading page...Загружаем страницу...正在加载页面...
AtlasRepo

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 control against 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.

Source

That gives you one real, strong guarantee: any edit, deletion, or reordering of a committed event breaks the chain and fails verify.

Source

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.

Source

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.

Source

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.'

Source

  • Record date: 2026-10-23T03:11:52.714Z