Agent forensics in five minutes: what it did, and proof the log wasn't edited A developer released pod v0.3.2, an Apache-2.0 tool that gives AI coding agents a hash-chained audit trail for incident forensics. The tool records each tool call with an argument hash, decision, outcome, and the policy version in force, then lets operators verify the log hasn't been edited and export a portable evidence bundle. "Edit any historical entry and verification fails immediately," the developer writes, arguing the chain proves "the log itself wasn't edited after the fact. An agent incident ends one of two ways. Without an audit trail, you guess: what it did, when, with which arguments, under which policy, approved by whom. With a hash-chained audit, five minutes gets you a full timeline — and a way to show the timeline itself hasn't been edited since. I run agents on my own laptop Claude Code, Cursor, OpenClaw, DSH , so I've had this happen. Here is the whole runbook, on real output. A real call from my machine — the policy stopped it: bash $ pod timeline --since 2h --tool delete file 2026-09-01 01:40:08 deny delete file filesystem agent=openclaw-main args=cb1533f3… pol=0.1.0 reason=tool "delete file" is denied on "filesystem" blocked ~~~ Three seconds to read three things: who openclaw-main , what it wanted to do delete file , why it didn't happen policy deny, with the policy version in force at that moment — 0.1.0 . Step 1 — replay the timeline 2 minutes ~~~bash pod timeline --since 2h everything, last two hours pod timeline --since 24h --tool write file only writes pod timeline --agent openclaw-main only one agent ~~~ Every row carries: time / tool / server / agent / argument hash / decision / outcome / approver / the policy version in force . Arguments are stored as hashes only — during an incident that means you don't leak more than you have to, while still being able to prove the call happened. Step 2 — prove the log wasn't touched 1 minute ~~~plaintext $ pod verify-audit openclaw-main/filesystem.jsonl - status: hash chain intact - entries: 8 - head hash: f7a56fb90350… - tail hash: 06f31666c4e8… conclusion: every record verifiable, none modified ~~~ Each record locks in the hash of the one before it. Edit any historical entry and verification fails immediately. That's a stronger claim than "the log shows it": it's "the log itself wasn't edited after the fact". Step 3 — package the evidence 2 minutes ~~~console $ pod export-evidence evidence bundle: ~/.pod/evidence/pod-evidence-2026-09-01.json audit files: 1 | policy snapshots: 1 top-level hash: 9f9e6ed35ed1c0b9… one-page report: ~/.pod/evidence/pod-evidence-2026-09-01.json.md $ pod verify-evidence --out ~/.pod/evidence/pod-evidence-2026-09-01.json ✅ evidence bundle valid top-level hash matches, nothing modified ~~~ One file to hand over: the audit, the policy snapshot that was in force , the self-check result, and a top-level hash. Whoever receives it can verify the bundle themselves — no need to trust your machine. Optional: cross-agent evidence in the cloud ~~~bash pod sync ~~~ The control plane lives in the same Apache-2.0 repo bash deploy/install.sh . The data direction is one-way: only SHA-256 hashes go up, the audit text stays on your machine, and the cloud being down doesn't affect local enforcement. Why a hash chain instead of plain logs | | Plain log | pod hash-chained audit | |---|---|---| | Records the call | yes | yes | | Records raw arguments | yes that's the leak surface | no — hash only | | Records the policy version in force | no | yes | | Provable that nobody edited it | no — anyone can edit a log | yes — one edit breaks the chain | | Portable, verifiable evidence bundle | no | yes | Not every agent behaves. The audit's job is narrower and more useful: what it did, it can't deny. Install v0.3.2 : ~~~bash curl -fsSL https://gitee.com/suhuisoftwares/pod/raw/v0.3.2/scripts/install.sh | sh pod init --template baseline pod serve --agent