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."
That 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.
The tool is 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.
Every 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.
That 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.
So 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.
Agents are good at finding paths around guardrails you put inside the loop. So the check happens before the process exists.
git clone https://github.com/radotsvetkov/soma && cd soma
cargo build --release
alias soma=$PWD/target/release/soma
soma init --name demo --with-builtins
soma wrap --label fix-tests -- claude -p "fix the failing tests"
If the command matches a deny rule or the autonomy level forbids it, nothing spawns:
soma wrap -- sudo rm -rf /tmp/something
The 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.
Every 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.
soma log verify
Let's break it on purpose:
sed -i.bak 's/governed/harmless/' .soma/events.jsonl
soma log verify
mv .soma/events.jsonl.bak .soma/events.jsonl
soma log verify
This 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.
A 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
that spells out the checks in plain shell.
soma export
On the skeptic's machine, with no soma installed, two checks:
shasum -a 256 events.jsonl # compare against manifest.json
The verification cost is seconds, on their hardware, with shasum
and a JSON reader. No trust in me required. That is the whole point.
Here 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.
That is what timestamp anchoring is for. soma submits the chain head to a public RFC 3161 timestamp authority and stores the response.
soma preset apply hybrid-default # opt in to network (fresh projects are local-only)
soma anchor now # timestamps the chain head at a public TSA
Now anyone can verify the timestamp with stock openssl
against the authority's certificate. After an anchor, I cannot backdate or rewrite history that crosses it without the public timestamps contradicting me.
What 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."
An evidence tool that oversells itself is broken on arrival, so:
wrap
is not a sandbox.src/
. TLS deliberately is not; that goes through system curl
. The trade is an audit surface you can read in a sitting, and cargo tree
is one line. Reviewing the supply chain is reviewing src/
.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.
If 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, there is a desktop cockpit at github.com/radotsvetkov/cockpit, and I would genuinely like to hear where it breaks. The honest-limits list grows with every good objection.
What evidence do you wish you had the last time an agent touched something that mattered?