Building Verifiable AI Agent Audit Logs With Signed, Hash-Chained Record

The log is held by the party under audit

Agents now read customer records, open pull requests, approve releases and pay invoices. When something goes wrong, the only answer to "what exactly did the agent do?" is a log file held by the party with the strongest reason to edit it. The operator, the agent itself (which usually has write access to its own logs) or an attacker with the agent's credentials can delete a step, change what a tool returned, or add a check that never ran. An auditor has to take the operator's word for it. Write-once cloud storage does not fix this: the operator still owns the bucket, decides what goes in, and is the only one who can query it.

In a separate HackerNoon submission I looked at co-signing a single AI output; this one is about the whole sequence of actions an agent takes on the way there.

The design: one action, one entity

Every step of a run becomes one entry:

{ "v": 1, "agent_id": "release-checker", "run_id": "run-20261009T152956", "step": 2,
  "action": "tool.call", "tool": "http_get",
  "note": "GET https://api.github.com/repos/ttimesai-star/sitelog/commits/main",
  "input_hash": "0x371d…", "output_hash": "0x7864…", "prev_entry_hash": "0x4557…",
  "timestamp": 1791559811222, "signer": "0x3ad7…c546",
  "entry_hash": "0x7580…", "sig": "0x9cc9…" }

• input_hash and output_hash are SHA-256 over canonical JSON of the tool arguments and result, or of the LLM request and reply. Raw content never goes on chain.
• prev_entry_hash links to the previous step. Delete, reorder or edit a step and every link after it breaks.
• sig is the agent wallet's EIP-191 signature over entry_hash, so an exported run stays verifiable after the on-chain entities expire.
• run.end seals the run with the step count and head hash. A run without a seal is reported as OPEN, so a truncated run cannot pose as a finished one.

On the agent side, logging is a wrapper:

const log = new AgentLog({ wallet, publicClient, account,
  agentId: "my-agent", runId: `run-${Date.now()}`,
  custodian: "0xAUDITOR" })               // optional

await log.start({ task })
const search = log.wrap("web_search", webSearch)   // hash in, hash out, signed, on Arkiv
await log.record({ action: "llm.call", tool: model, input: request, output: reply })
await log.seal({ result })                          // run.end + 180-day retention

wrap() also logs failures as tool.error. A CLI covers agents written in other languages, and agentlog verify exits with code 2 on a broken run, so it can gate a CI job.

What lives where

Each entry lands on Arkiv as one entity. What Arkiv gives this design, and the code uses:

• $creator is set by the chain. Anyone can write an entity that claims to be step 2 of my run. Only entities whose $creator is the agent wallet count, and that filter runs on the node.
• Readonly entities. Nobody can patch a step after it lands, the agent included.
• Ownership transfer inside the creating batch. This is the part I did not expect to work. predictEntityKeys returns the keys a batch is about to mint, together with salts that pin them. The same executeBatch then creates the entries and hands them to a custodian wallet:

const predicted = await publicClient.predictEntityKeys({ owner: agent, count: creates.length })
predicted.forEach((p, i) => (creates[i].salt = p.salt))
const ownershipChanges = predicted.map((p) => ({ entityKey: p.key, newOwner: custodian }))
await wallet.executeBatch({ creates, ownershipChanges })

There is no block in which the agent alone owns its log. I tested it: the agent's own deleteEntity and patchEntity on a logged step are both rejected with "entity 0xadef…08ab is owned by 0xBDe3…C6f0, not 0x3ad7…c546". $creator stays the agent, so trust is unaffected.

• Expiration with permissionless extension. A live run's steps lease 14 days; the seal moves the whole run to 180 days. An auditor can extend a run further but cannot change or shorten it.
• Attributes are the index. "Every http_get of this agent" is one query, and so is "which entries claim to follow this hash", which is how a fork (two histories signed by one key) shows up. No indexer of mine.

The verifier (agentlog/src/core.ts) is the same code in Node and in the browser: it recomputes every hash, recovers every signature, follows the links from step 0 and reports gaps, forks, edits and foreign signers.

The demo: a real agent, a real attacker

release-checker is small and real: check the repository's latest commit on GitHub, check that the live page responds, check that Arkiv is reachable, write a three-line status report. The model picks the tools; both are read-only (http_get on two allow-listed hosts, and arkiv_status). The demo run used openai/gpt-oss-20b through NVIDIA's free NIM endpoint; any OpenAI-compatible API with tool calling works.

Run run-20261009T152956 has nine steps: run.start, four llm.call, three tool.call and run.end, each in its own transaction with the custodian set.

Then a second wallet played the attacker (agentlog/examples/forge.ts) and wrote two records into the same run: a fake step 2, "FORGED: all checks passed, approved for release", and a byte-for-byte replay of the genuine step 1, carrying the agent's valid signature. Both are on chain; neither enters the run, because their $creator is 0x0757…d29b. The replay is the instructive case: a signature check alone would have accepted it.

Three other runs from the same afternoon stop early and show OPEN: two died on the LLM provider's quota, one on a malformed tool call. Their trails show exactly how far each got.

Attack it yourself

Open ttimesai-star.github.io/sitelog. I loaded it in headless Chromium on 10 October; it read the run from the public Tiramisu RPC and showed INTACT: 9 steps by the agent wallet, 9/9 entries verified in the tab, sealed with run.end, 2 forged records ignored, owner of every entry the custodian.

The button Tamper with a copy in your browser edits a local copy four ways and re-verifies each one. Verbatim results from the live page:

• edit what a tool returned (step 4) → BROKEN: step 4: content does not match entry_hash (edited after signing)
• delete a step (step 3) → BROKEN: step 3 is missing (deleted, expired or never written): the chain is broken here
• drop the seal → OPEN: no run.end seal: the run looks unfinished
• re-sign step 1 with another key → BROKEN, on both the hash and the signer

Check raw inputs and outputs loads the off-chain evidence file (raw LLM requests, replies and tool results) and checks it against the on-chain hashes: all nine steps match. In a real deployment that file stays private and goes to the auditor.

An exported run verifies offline with the same verdict, and the page prints the exact arkiv_query it ran as a curl command, so the run can be read with no code of mine at all.

A 2:55 walkthrough video is attached to the repository's GitHub release.

What it does not protect

An audit log that overclaims is worse than none, so:

• An agent that lies at the moment of writing. If it hashes a fake tool output, the log faithfully records the fake. The log proves what was written and when, not that it was true. The evidence file narrows this; it does not close it.
• A stolen agent key can write a second history, visible as a fork only if both histories reach the chain.
• The agent's clock. timestamp is the agent's; trust the block number.
• The custodian can delete entries. Pick one you trust, or a multisig.
• Privacy relies on discipline: only hashes, tool names and a short note go on chain. No secrets or personal data in note, agent_id or run_id.

Friction: two SDK findings worth knowing

I kept a friction report with exact repro steps. Two findings matter to anyone building this way.

F8: the documented example cannot run on one client. The JSDoc of predictEntityKeys shows one client calling predictEntityKeys and then executeBatch. In SDK 0.8.1 no client has both: the first exists only on the public client, the second only on the wallet client. Hence the publicClient option in AgentLog.

F9: permissionless extension can block an owner's atomic batch. An extension is rejected unless it moves the expiry later. Since anyone may extend a permissionless entity, a third party can push one of my entries to 365 days, and my "write the seal, extend everything to 180 days" batch then reverts as a whole ("would shorten its life"). The flag that lets an auditor keep evidence alive also lets anyone block an atomic seal. My mitigation: seal() catches the revert, lands run.end alone, then extends the rest one by one. The real fix belongs in the protocol: an "extend to at least" mode.

The report also covers cursor pagination that breaks after one block unless pinned with atBlock(), and a public RPC quota of roughly 100 queries per hour per caller.

Status, honestly

Arkiv Tiramisu testnet only, four synthetic wallets, no users: the only agent writing to it is my demo agent. 44 unit tests pass (npm test), covering hashing, tamper cases, the writer, custody, and the construction-site log the project started from. MIT licence, built during the Arkiv Global Tour Stop (9 to 18 October 2026).

Links:

• Live page: https://ttimesai-star.github.io/sitelog/
• Source, schema and friction report: https://github.com/ttimesai-star/sitelog
• Demo video: https://github.com/ttimesai-star/sitelog/releases/tag/demo-video-agentlog

What decides whether this is useful is the next step: an agent framework calling log.wrap() on its tools by default, and an auditor who is willing to be the custodian.