There is a question that ends most conversations about AI governance, and it is not a technical one.
Show me what your agents did last Tuesday,
and prove it.
Not a dashboard. Not a confidence level. A record of what was requested, what was permitted, what was refused and why, that holds up when someone outside your organisation examines it and has no reason to take your word for anything.
Most organisations running agents today cannot produce that. Not because they are hiding something — because nothing was built to produce it.
Logs are not evidence
Almost everyone has logs. Very few have evidence. The gap between the two is where this gets uncomfortable.
Logs record what a system decided to write down. Evidence has to satisfy someone who suspects the system. Those are different bars, and the second one is much higher.
Three things usually break.
The decision is not in the record
Application logs capture that a tool was called. They rarely capture what the agent was permitted to do at that moment, what it asked for, and why the answer was yes. The interesting question is never “did this happen.” It is “why was this allowed.”
Refusals disappear
Almost every system records what it did. Very few record what it declined to do. But refusals are the proof your controls were working. A record showing only successful actions cannot distinguish a well-governed month from a month with no controls at all.
Nothing stops a rewrite
If the record lives in a database your own team administers, it is exactly as trustworthy as your own team — which is precisely the assumption an auditor is not allowed to make. It is not a comment on anyone’s integrity. Unfalsifiable claims carry no weight.
Why agents make this urgent
We tolerated weak audit trails for a long time because a human sat behind every consequential action. If the record was thin, you could ask the person. Their memory, their email, their colleague’s recollection — the record was thin but the accountability was thick.
Take the person out and that scaffolding collapses.
The rate changes. A team of agents can take more consequential actions in a day than a department takes in a year. “We’ll reconstruct it if we need to” quietly stops being possible somewhere in that increase.
The reasoning is not reproducible. Run the same agent on the same input tomorrow and you may get a different action. So you cannot recover what happened by re-running it. Either it was recorded when it happened, or it is gone.
And the accountability question sharpens. When an agent issues a refund it should not have, “the system did it” is not an answer anyone accepts. Somebody authorised that agent to hold that capability. Increasingly, regulators want to know who, on what basis, and whether anyone reviewed it since.
The EU AI Act’s transparency and record-keeping obligations point this way. So does every financial regulator that has looked at automated decisioning. The direction of travel is consistent: if a system acts on your behalf, you are expected to be able to explain and evidence it. Not describe your intentions — evidence it.
A retail bank tries to answer the question
The bank below is composite and unnamed; the scramble is not.
Six weeks after the incident, the regulator asks a narrow question. On the fourteenth, a goodwill credit was issued to an account that had no open dispute. Who authorised it, and what controls applied?
The bank has a lot of material. The disputes agent’s application log shows the credit was created, with a timestamp and an amount. The core banking system shows the ledger entry. The model provider’s console shows a conversation took place.
None of that answers the question.
What was the agent permitted to do at that moment? The log records the action, not the authority behind it. What did it ask for that it did not get? Nothing captured refusals, so there is no way to show any control was engaged. Who granted the underlying access? A ticket from fourteen months earlier, for a different service, that the agent inherited. Has anyone reviewed it since? The access review covers named human owners; the shared integration account has one, and he moved to another team in January.
So the team does what every team does. They reconstruct. Three engineers, most of a week, assembling a narrative from four systems, and the narrative is probably right.
Probably right is a very uncomfortable thing to send a regulator.
The painful part is that the bank’s controls may well have worked correctly that day. Something may have been refused. The agent may have stayed inside every limit but one. Nobody can demonstrate it, because the only events anyone wrote down were the ones that succeeded — and a record of successes cannot distinguish a well-governed system from an ungoverned one.
The awkward test
Here is a way to find out where you stand, and it takes about an hour.
Pick one action an agent took last week. Something with a consequence — a payment, a record change, a message sent outside the company.
- 01What was the agent allowed to do at that moment?
- 02What did it ask for?
- 03What was it refused, if anything?
- 04Who granted that authority, and when?
- 05Has anyone reviewed it since?
- 06Could someone outside your team verify all of it without asking you?
Most teams get about a third of the way through and stop, because the answer is that some of it was never captured, and the rest lives somewhere it could have been edited.
That is not a failure of diligence. It is what happens when you deploy something faster than the controls around it. But it is worth knowing before someone else asks the question in a setting you do not control.
What actually helps
The instinct is to log more. That mostly produces expensive noise.
What helps is narrower and harder.
Record the decision, not just the action — what was permitted, what was requested, what was refused. Refusals belong in the record as first-class entries, because they are the only positive evidence a control existed and worked.
Make it structurally difficult to rewrite. Not policy-difficult. Structurally difficult, so that tampering is detectable by someone who never trusted you in the first place.
Let it be checked externally. A record that only you can vouch for asks the reader to trust the party that wrote it, which is the exact thing a tamper-evident record is supposed to remove.
And make it survive scale. A verification process that works for ten agents and takes a week for ten thousand is not an audit trail. It is a story about one.
The part I find genuinely interesting
Everyone frames this as a compliance cost. In practice it is closer to the opposite.
The organisations that can evidence what their agents do are the ones that end up letting agents do more. They can give an agent a consequential capability because they can demonstrate afterwards exactly what it did with it. The organisations that cannot evidence anything end up keeping agents in a sandbox indefinitely, extracting a fraction of the value, because nobody will sign off on the risk.
Provability is not the tax on autonomy. It is the thing that makes autonomy approvable.
Pick one agent action from last week and try to prove it.
Whatever stops you is your roadmap.
Where Aribot fits
Aribot governs what AI agents are allowed to do — authority sized to the task rather than the job, enforcement that sits outside the model rather than asking it politely, and a record of what was permitted and what was refused that someone outside your organisation can check. It works with the identity stack you already run.