{"slug": "tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove", "title": "Tamper-evident tamper-proof: what an agent audit log can actually prove", "summary": "A developer built an append-only, hash-chained audit ledger for AI agents, shipped in the Apache-licensed agenthof tool, that makes any edit, deletion, or reordering of a committed event detectable via `agenthof audit verify`. The developer is explicit that the ledger is tamper-evident rather than tamper-proof: tail truncation is solved for the governance ledger through an independent off-machine anchor, but automatic anchoring for per-run receipts and detection of silently dropped events remain unbuilt, with the latter planned as an ingress-call accounting check rather than a cryptographic fix.", "body_md": "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.\n\nSo let's do the un-sexy thing and be precise. In [an earlier post](https://dev.to/rojaneerdev/from-god-mode-to-governed-an-ai-agent-that-cant-exceed-its-grant-4ilk) I showed an agent acting as a human and leaving a receipt. This post is about **how much you can actually trust that receipt** — what it genuinely proves, the three places it honestly can't, and — the part most \"trust\" posts skip — *which of those are shipped and which I'm still building.* All runnable from the Apache core; verify it yourself.\n\nThe ledger is an **append-only, hash-chained** file: each event carries the SHA-256 of the exact bytes of the event before it, so the records form a chain. `agenthof audit verify <run>` walks it:\n\n``` bash\n$ agenthof audit verify r-85f417c6…\nhead: 4d655340… (13 events)\n```\n\nThat gives you one real, strong guarantee: **any edit, deletion, or reordering of a committed event breaks the chain and fails `verify`.** Change one byte of one event, drop a line from the middle, swap two — the hashes stop matching from that point on. For honest mistakes (a corrupted write, a botched migration) and lazy tampering, that's genuine and it's free.\n\nThat is **tamper-*evident*.** It is not tamper-*proof*, and the difference is the whole post.\n\nThe chain protects *committed* events. But if an attacker controls the whole file, they can delete the **tail** — the last N events — and recompute a perfectly valid chain from a clean point. Nothing inside the file betrays it; a shorter valid chain looks exactly like a run that simply did less.\n\nYou can't win this *locally*. The only defense is a **head recorded somewhere off the machine** — then you compare. Two shipped ways, and they are *not* equally strong, so I'll be exact:\n\n`agenthof audit verify --expect-head sha256:<hex>`. Real, but only as independent as wherever `agenthof audit anchor` pins the current head into a `audit verify control` then checks every recorded anchor against the chain. Now a whole-root rewrite is detectable by a `audit seal` to rotate the ledger into sealed segments. 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 too is **reserved, not yet built.** I'd rather tell you that than let you assume your run receipts are anchored to a transparency log. They aren't yet.\n\nHere's the subtle one, and a reader pushed on exactly it, correctly. `verify` proving the chain is unbroken does **not** prove the chain is *complete*. If a door acted but its event was never written — a transient write failure, or a code path that forgot to record — the chain still verifies *perfectly*. The events that are there are untampered; you just can't tell that one is *missing*.\n\nAnd — important — **cryptography cannot fix this.** You can't cryptographically prove the existence of a record that was never created; a dropped event leaves no missing signature, because the signature would have been *on* the dropped event. Signing gives you integrity, not completeness. Completeness is an **accounting** problem, not a crypto one.\n\nWhere it stands, honestly: 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.** The approach is accounting, not crypto: have the gateway count the calls it handled at its ingress and check that the ledger holds that many, so a missing one *fails* `verify`. I'm building it because the gap is real. When this post says a limit is closed, it'll be because I ran it — and this one isn't closed yet.\n\nThe ledger is written by the operator's own gateway. So \"nobody tampered\" ultimately rests on trusting *your* gateway — and in a regulated setting the first question is *who checks, and what does it cost when it's wrong?* The honest answer isn't \"trust my gateway.\" It's to put the **evidence** somewhere that isn't yours — which is exactly what the transparency-log anchor does for the governance ledger: the corroborator is a party neither the agent nor the operator controls. 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.\"\n\nPut it in one picture:\n\nNone of those rows say \"tamper-proof,\" and that's the point. A guarantee you can **run yourself** and whose **limits are stated** is worth more than a marketing adjective. You don't have to trust me: `agenthof audit verify`, `audit verify control`, and `--expect-head` are in the repo, and the honest-limits are written into the docs, not a footnote.\n\nThis is **[Agenthof](https://github.com/agenthof/agenthof)**, Apache-2.0. It's early, and as you can see I'll tell you exactly where the edges are — including the one I'm still building. If \"tamper-proof\" makes you flinch too, the repo's [here](https://github.com/agenthof/agenthof), and `verify` is yours to try.\n\nNext post: **containment by construction** — an agent with no network and no secrets, so the bad outcome isn't *forbidden*, it's *impossible*.", "url": "https://wpnews.pro/news/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove", "canonical_source": "https://dev.to/rojaneerdev/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove-129b", "published_at": "2026-10-23 02:29:31+00:00", "updated_at": "2026-10-23 02:41:15.153747+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-policy", "developer-tools"], "entities": ["agenthof"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove", "markdown": "https://wpnews.pro/news/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove.md", "text": "https://wpnews.pro/news/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove.txt", "jsonld": "https://wpnews.pro/news/tamper-evident-tamper-proof-what-an-agent-audit-log-can-actually-prove.jsonld"}}