Audit trails don't get installed. Caches do. So I built one that doubles as the other.
Nobody was recording
In September 2026, a swarm of roughly 10,000 AI agents working together for 88 hours produced a proof about the equations that describe how fluids move — one of the hardest open problems in mathematics. The agents exchanged 2.7 million messages along the way. It's a genuinely remarkable result, and OpenAI published it in detail.
The part that stuck with me wasn't the mathematics. It was a caveat in the write-up.
Two mathematicians had been working on a closely related problem. When questions came up about whether their private research had influenced the swarm, the honest answer available was that it couldn't be ruled out.
I want to be precise about why that's interesting, because it would be easy to read it as a criticism and it isn't one. Publishing that caveat at all was more transparent than most organizations would have managed; plenty would simply have said nothing. And the answer wasn't unavailable through carelessness.
It was unavailable because nothing was recording at the time. That's the whole thing. The cryptography for answering such a question is decades old and thoroughly understood — the hard part was never the maths, it's that no one runs an audit recorder before they need one.
That includes me. I run agents daily and I couldn't have answered it either. So the question I got interested in wasn't "how would you build this?" — several people already have, and I'll name them below. It was: why isn't it switched on anywhere, and what would make someone switch it on?
Why this is about to be everyone's problem
Right now, an AI agent talking to a model is roughly as accountable as a browser tab. It sends a request with an API key. The key says "someone at this company paid for this." It doesn't say which agent, acting for which person, was allowed to do what.
That was survivable when one agent answered one question. It stops being survivable when a thousand agents run unattended across your codebase, your customer data, and each other's output — because when something goes wrong, "we can't rule it out" will be the honest answer, and it won't be good enough.
Plain logging doesn't fix it. Logs are written by whoever is under suspicion, they get rotated and sampled, and anyone with access can edit one. What's needed is a record that is complete, that can't be quietly changed, that says who authorized each action, and that an outsider has some reason to believe.
The tools to do that exist. Almost nobody is running them. That gap — between available and switched on — is the actual problem, and it isn't a technical one.
Why audit tools never get installed
Here's the trap that kills audit tools: the organization that installs the recorder is the same one that might be embarrassed by what it records. Nobody wakes up wanting an audit trail. And a recorder switched on after a question is asked is worthless — the moment that matters has already passed.
So a provenance tool that asks to be adopted on principle will not be adopted. It has to be something people already want for entirely unrelated reasons.
It turns out that at scale, agents ask the same questions over and over. Thousands of workers grinding on one problem re-attempt the same sub-problems constantly. A recorder sitting in that position stores every call indexed by its exact content — which means it already knows the answer to a repeat question — and can return it immediately instead of paying for the model to think again.
The same property lets you re-run a whole job from the record with zero calls to the model. A four-day run that crashed can resume instead of restarting. Change one assumption and only the affected parts re-run.
So the pitch stops being "install this for accountability" and becomes "install this because it cuts your model bill and makes crashed runs resumable." The accountability comes along for free — and, crucially, it is already switched on before anyone needs it.
That inversion is the bet. Everything below is just the machinery that makes it work.
What it is
The usual analogy for this is aviation's black box, and it's the right one: aircraft don't rely on the crew's recollection after an incident, they record continuously whether or not anyone expects trouble. (It's a well-worn comparison in this field — there are papers with it in the title.)
Witness is that idea, applied to AI agents. It's a single small program that sits between your agents and whichever AI model they use. Every call passes through it, and every call gets recorded on the way.
The important design decision is where it sits. Your agents don't import a library or adopt a framework. They change one line — the address they send requests to:
client = anthropic.Anthropic(
base_url="http://127.0.0.1:8787", # the only change
)
That's the whole integration. Anything that talks to a model over the network — a Python script, a big agent framework, someone else's tool you can't modify — works the moment you point it at a different address.
Here's the shape of it:
Four things happen inside that box, and each one answers a different question.
What happens to a single call
Follow one request through and the ordering matters more than it looks.
The agent's identity is checked first, so an unauthorized call never enters the record and never reaches the model. The call is written down second, before anything leaves the machine — so there is no way for a request to reach the model without a record of it existing. Contacting the model comes last, and often doesn't happen at all, for reasons I'll come back to.
Why the record can't be quietly edited
A log file is a promise. This is closer to a proof.
Every record includes a short fingerprint — a hash — calculated from its own contents plus the fingerprint of the record before it. Each entry is sealed to its predecessor, like a chain where every link is stamped with the shape of the previous one.
That has a useful consequence. If someone edits an old record, its fingerprint no longer matches its contents, and every record after it is now sealed to a fingerprint that doesn't exist. One quiet edit doesn't produce one wrong line — it visibly breaks the chain from that point to the end.
That handles internal honesty — you can't rewrite your own history without it showing. But it doesn't yet give an outsider any reason to trust you, since you could rebuild the whole chain from scratch.
So the whole record can be boiled down to one short summary value and published somewhere you don't control. Later, you can prove any single record was part of that run — without revealing the rest of it. The commitment was made before anyone thought to ask, which is the only time such a commitment is worth anything.
This is where that unanswerable question becomes a command:
$ witness audit --contains "private-research-notes"
no record among 3000 verified journal entries contains "private-research-notes"
statement: as of committed root c80c54be…69d8bb (3000 records),
no agent request or response contained it
And when there is a match, it names the exact agent, and the human who authorized it.
Who authorized this agent?
The second question is permission. An API key can't express "this agent may do this narrow thing" — it carries everything its owner can do.
Witness borrows from how authority works among people. A human signs a permission slip granting an agent something specific — say, access to Claude models only. The agent carries that slip with every request. If it spawns a helper agent, it can pass along a slip of its own — but only equal or narrower than what it holds.
An agent that can use Claude models can grant a helper access to one specific Claude model. It cannot grant access to everything, because that would be wider than what it was given, and the mathematics of the signature simply won't produce a valid slip.
Two properties are worth pulling out. This is checked at the door — a request outside an agent's permissions is refused before it reaches the model provider, not flagged in a report afterwards. And it's checked locally, with no permission server to call, because verifying a signature is just arithmetic.
Does it slow anything down?
This is the first question anyone technical asks, so it's worth answering with a measurement rather than a reassurance.
Recording a call adds about a quarter of a millisecond. Checking an agent's signature and its permission chain adds about 20 microseconds — a fiftieth of a millisecond.
For scale: a single AI model call takes somewhere between two and thirty seconds. The recording overhead is around 0.01% of that. In practice, you cannot feel it, and the cryptography — the part people usually assume is expensive — is the cheapest thing in the box.
Who else is building this
If the argument above sounded like "nobody thought of this," let me correct that firmly, because it's the opposite of true. When I went looking properly, I found a busy field — and in some places, people well ahead of me.
Wirken is the closest. Rust, MIT-licensed, actively developed, and it already does per-agent Ed25519 identities signing a hash-chained session log, offline verification, reproducible replay, and delegation to sub-agents under ceilings — plus a credential vault, process isolation and sandboxed execution that I don't have. If you need an agent gateway in production today, start there rather than with mine.
Bifrost signs audit events at creation and archives them append-only, with about 11 microseconds of gateway overhead — considerably faster than mine. It signs with HMAC rather than a public-key scheme, which means only the holder of the secret can verify a record. That's a meaningful design difference: it keeps the evidence self-asserted, which is the problem you were trying to escape.
LiteLLM, the most widely deployed proxy in this space, has open pull requests adding per-call signature chaining — with post-quantum signatures, which is further ahead than anything I've written.
Armalo already anchors Merkle audit logs to Sigstore's public transparency log with inclusion proofs. That was still an open to-do in my own repository when I found them.
And the whole approach is being standardized: an IETF draft specifies append-only per-agent logs bound to Ed25519 keys, checkpointed with signed Merkle heads and countersigned by independent parties. Longer term, conforming to that is worth more than any bespoke format, mine included.
So the honest positioning is narrow. What I think is different is not the cryptography — it's which problem the tool claims to solve. Everything above sells accountability to people shopping for accountability. This one sells a cache to people shopping for a lower bill, and the accountability is what falls out. Whether that inversion actually gets recorders switched on is a bet, not a proven result. It's the only part of this I'd defend as new.
What it can't do
Any tool that claims to establish provenance should be equally clear about where it stops.
It cannot see what a model learned during training. If someone's private work influenced the model itself rather than being fetched during a run, no request record will ever reveal it. That's a fundamental limit, not a to-do item — and it means this class of tool answers "what did my agents read?" but never "what does this model already know?"
It doesn't stop an agent from being manipulated. An agent that has been tricked into misbehaving still holds valid permissions. Narrow permissions limit how much damage it can do and the record shows exactly what happened, but a fully documented incident is still an incident.
A commitment you never publish proves nothing. The summary value has to go somewhere outside your control. Left on your own disk, it's just another file you could have written yesterday.
Try it
It's open source under the MIT license, it's a single file with nothing to install alongside it, and the demo needs no API key or account:
git clone https://github.com/anzal1/witness && cd witness
cargo build --release
./demo.sh
The demo runs the entire story in about thirty seconds against a built-in fake model: a signed request from an authorized agent, an instant answer when the same question repeats, a refusal when an agent reaches beyond its permissions, a verification of the record, a published summary, a proof about a single entry, and an audit.
The part that should worry you
The fluid-equations story was reported as a story about mathematics. I read it as a preview of an operational problem heading for everyone.
Agent fleets are about to touch production systems at volumes where no human reviews any individual action. When something goes wrong — and it will, and it will matter more than authorship of a proof — the question won't be whether your agents did it. It will be whether you can show what they did, to someone who has no particular reason to take your word for it.
"We can't rule it out" is not going to be an acceptable answer for very much longer. The encouraging part is that doing better costs about a quarter of a millisecond per call, and pays for itself on the repeats.