Agent forensics in five minutes: what it did, and proof the log wasn't edited
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
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.
The script: 01:40, an agent tries to delete a file
A real call from my machine — the policy stopped it:
$ 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 <name> --server <name> --policy ~/.pod/policies/baseline.json --command <cmd>
~~~
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.