Can you prove what your agent did?

The audit question arrives earlier in an agent program than anyone plans for, and it arrives from a person with standing: the assessor, the compliance officer, the ISSM. A security practitioner asking it in public phrased the two halves exactly:

How do you scope and grant an agent’s access? Least-privilege for a non-human, task-scoped actor seems like it doesn’t map cleanly. After the fact, can you actually prove what an agent did if an assessor or your ISSM asks? — a governance practitioner, r/cybersecurity

Both halves are really one and the same question. To grant access provably and to prove what happened after the fact are the same requirement facing opposite directions: a record that binds an action to the authority that permitted it.

Inside a real enterprise, the record’s condition is worse than missing. Missing is bad enough. Present but jumbled is worse. An engineer responsible for agent observability described what a multi-team deployment actually produces:

Team A builds a support bot in LangGraph, Team B builds a research agent in CrewAI, and Team C writes raw Python against the Anthropic API… your audit trail is completely fractured. You can’t confidently tell a compliance officer what your synthetic workforce is doing. — a platform engineer, HN

This is the ordinary state of the art, not a pathological one. Three teams, three frameworks, three record formats, and no common notion of what an event is. At enterprises of actual scale, the real problem is ten or a hundred times worse.

The enterprise has not failed to keep records. It has succeeded three times or three hundred times, incompatibly. Records abound, while proof strangely goes amissing.

Identity has no floor

But the fracture is not only in the record-keeping. It runs down to the question of who acted, which in most agent deployments has no answer at all. When several teams shipped early agent-identity systems at once, one builder stated the baseline openly:

AI agents are deployed by third parties, run across organizational boundaries, and interact with services they have no pre-existing trust relationship with… The current state is literally nothing — no identity, no verification, no audit trail, no revocation. — an agent-identity builder, HN

The sentence to sit with is the last one. Not that identity is partial, or immature, or nonstandard. That it is absent. A record of actions without a verified account of which actor took them, under which authority, that anyone can revoke, is not a record an auditor can do anything with. It is a story the system tells about events nobody can attribute.

Why no single framework can fix this

It’s tempting to read these fractures as a tooling accident, as if frameworks had simply not gotten around to a common format. The fractures are structural and the reason is authority.

An audit trail that a compliance officer can act on has to bind each action to three things at once:

1. what was done,
2. which authority permitted it, and
3. a record that provably wasn’t edited after the fact.

A single framework can bind its own actions to its own authority and several do. It cannot bind another framework’s actions to anything, because the authority by which agents act is not a property of any framework. It’s either a property of the platform all the frameworks run on, or it’s not a property of anything at all.

This is why the observability layer cannot close the gap from outside, except, perhaps, in technical monocultures that simply do not exist in any enterprise, and why the engineer quoted above reached the correct conclusion from the pain: observability and governance cannot live inside the agent framework. They live beneath it, where authority is issued, or they live nowhere.

The difference between a description of a run and a reproduction of it—the sealed, replayable record an assessor can check without being asked to take anything on faith—is laid out in Agents need a flight recorder, not a firewall. The point here is the prior question: which layer could produce such a record, given that no framework can.

The word for it

A system that defends itself, that bounds what can happen inside it, catches what should not, and prevents a foreign or faulty agent from doing harm, is self-protecting. The protection that matters for audit is not a guard at the edge. It is a property of the platform itself: that every privileged action crosses one boundary, that the boundary knows which authority was presented, and that the crossing is recorded in a form the party asking for proof can verify independently, provably, at will.

Nothing about this requires the frameworks to cooperate. Point-to-point cooperation between every pair of frameworks scales badly and is commercially improbable. This is where another layer of abstraction is precisely the thing. That is, it requires them to run on something that keeps the record as a condition of running at all, which is what an operating system has always been for: the layer beneath the programs, mediating what they may do, and keeping the account none of them could keep for themselves.

What is an operating system for agents? defines the layer that holds the record. The sealed, replayable form of the record is argued in PLRN-006, and how authority is sealed into each decision rather than logged beside it is the subject of PLRN-014.