{"slug": "how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you", "title": "How to prove what your AI agent actually did (to someone who doesn't trust you)", "summary": "A developer built Soma, an open-source tool that creates verifiable audit trails for AI agent actions. The tool uses a hash chain to record every action in an append-only JSONL file, allowing anyone to independently verify the log with standard command-line tools like shasum. Soma also enforces governance rules before an agent runs, blocking prohibited commands and recording the refusal as part of the tamper-evident record.", "body_md": "You let an AI agent edit your repo, run commands, call tools. The next morning someone asks: *what did it actually do?* And you realize the only honest answer you have is \"trust me.\"\n\nThat answer does not survive contact with a client, a security reviewer, or an auditor. I got tired of it, so I built a tool that produces an answer a skeptic can check on their own machine. This is a walkthrough of how it works, with commands you can run in about two minutes.\n\nThe tool is [soma](https://github.com/radotsvetkov/soma), an open-source (Apache-2.0) runtime. But the interesting part is not the tool, it is the four ideas it stitches together. You could rebuild any of them yourself; the point of this post is the pattern.\n\nEvery big vendor shipped agent governance this year (Microsoft Agent 365, OpenAI Frontier, Google's agent platform). They are good at managing fleets. But the audit trail they produce lives inside the vendor's cloud. To believe the log, you have to believe the cloud that produced it.\n\nThat is fine until the person asking does not trust your cloud, your machine, or you. A freelancer cannot show a client their M365 tenant. A regulated team cannot put an American cloud in the trust path. An auditor wants to verify, not to take your word.\n\nSo the design goal is unusual: **evidence that survives leaving your trust boundary.** A record that a stranger can verify with tools they already have, no special software, no account.\n\nAgents are good at finding paths around guardrails you put *inside* the loop. So the check happens before the process exists.\n\n```\n# Install: one binary, zero dependencies to fetch.\ngit clone https://github.com/radotsvetkov/soma && cd soma\ncargo build --release\nalias soma=$PWD/target/release/soma\n\nsoma init --name demo --with-builtins\n\n# Govern any agent CLI. The launch is checked before anything runs.\nsoma wrap --label fix-tests -- claude -p \"fix the failing tests\"\n```\n\nIf the command matches a deny rule or the autonomy level forbids it, nothing spawns:\n\n```\nsoma wrap -- sudo rm -rf /tmp/something\n# refused, exit non-zero, and the refusal is recorded with the rule that fired\n```\n\nThe key move: the agent never gets a chance to run, and the *refusal itself* is part of the record. You can prove later that something was blocked.\n\nEvery action becomes a line in an append-only JSONL file. Each line carries the SHA-256 of the previous line. That makes the file a hash chain: change any line and every line after it no longer matches.\n\n```\nsoma log verify\n# recomputes the whole chain from scratch\n```\n\nLet's break it on purpose:\n\n```\n# edit one byte of history\nsed -i.bak 's/governed/harmless/' .soma/events.jsonl\n\nsoma log verify\n# TAMPERED at line 7: stored hash mismatch   (exits 1, names the exact line)\n\n# restore it byte for byte\nmv .soma/events.jsonl.bak .soma/events.jsonl\nsoma log verify\n# chain valid again\n```\n\nThis is the part that makes a demo land. You can *see* the tamper get caught at the exact line, and you can see the chain heal when you restore the byte.\n\nA hash chain you can only check with my tool is not much of a proof. So the export bundles everything a stranger needs, plus a `VERIFY.md`\n\nthat spells out the checks in plain shell.\n\n```\nsoma export\n# produces a bundle in exports/ with manifest.json, events.jsonl, VERIFY.md\n```\n\nOn the skeptic's machine, with no soma installed, two checks:\n\n```\n# 1. every file digest matches the manifest\nshasum -a 256 events.jsonl   # compare against manifest.json\n\n# 2. recompute the chain by hand: for each line, sha256 of the line with its\n#    own hash field removed must equal the stored hash, and each \"prev\" must\n#    equal the previous line's hash.\n```\n\nThe verification cost is seconds, on their hardware, with `shasum`\n\nand a JSON reader. No trust in me required. That is the whole point.\n\nHere is the honest hole in everything above: I control the binary, the journal, and the machine. The hash chain proves the file was not *casually* edited. It does not prove I did not regenerate the whole thing.\n\nThat is what timestamp anchoring is for. soma submits the chain head to a public [RFC 3161](https://www.rfc-editor.org/rfc/rfc3161) timestamp authority and stores the response.\n\n```\nsoma preset apply hybrid-default   # opt in to network (fresh projects are local-only)\nsoma anchor now                    # timestamps the chain head at a public TSA\n```\n\nNow anyone can verify the timestamp with stock `openssl`\n\nagainst the authority's certificate. After an anchor, I cannot backdate or rewrite history that crosses it without the public timestamps contradicting me.\n\nWhat this proves: this exact journal state existed at time T, and everything after extends it. What it does **not** prove: that the events were true when written. Nothing prevents an operator writing fiction forward; everything prevents *revising* it after the fact. That is a much smaller and checkable claim than \"trust my logs.\"\n\nAn evidence tool that oversells itself is broken on arrival, so:\n\n`wrap`\n\nis not a sandbox.`src/`\n\n. TLS deliberately is not; that goes through system `curl`\n\n. The trade is an audit surface you can read in a sitting, and `cargo tree`\n\nis one line. Reviewing the supply chain is reviewing `src/`\n\n.Nobody reads audit logs, which is the usual objection. True. The design does not optimize for reading; it optimizes for *disputes*. Nobody looks at the journal until something goes wrong, and then the only question is whether the record settles the argument or becomes another argument. A bundle that verifies in seconds on the skeptic's machine settles it.\n\nIf you run agents for clients, or compliance keeps asking you questions you can only answer with screenshots, this might be useful. The repo is [github.com/radotsvetkov/soma](https://github.com/radotsvetkov/soma), there is a desktop cockpit at [github.com/radotsvetkov/cockpit](https://github.com/radotsvetkov/cockpit), and I would genuinely like to hear where it breaks. The honest-limits list grows with every good objection.\n\n*What evidence do you wish you had the last time an agent touched something that mattered?*", "url": "https://wpnews.pro/news/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you", "canonical_source": "https://dev.to/radotsvetkov/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesnt-trust-you-b3a", "published_at": "2026-06-13 12:21:01+00:00", "updated_at": "2026-06-13 12:47:55.889412+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools"], "entities": ["Soma", "Microsoft Agent 365", "OpenAI Frontier", "Google", "M365"], "alternates": {"html": "https://wpnews.pro/news/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you", "markdown": "https://wpnews.pro/news/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you.md", "text": "https://wpnews.pro/news/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you.txt", "jsonld": "https://wpnews.pro/news/how-to-prove-what-your-ai-agent-actually-did-to-someone-who-doesn-t-trust-you.jsonld"}}