A year ago we wrote here about the AI agent identity problem — agents handed a service account with a static key, broad permissions, no MFA challenge, no posture check and no meaningful audit trail, at a point when almost nobody was treating that as an access control question.
Since then the industry has caught up, and a category of products has formed to solve it. That is progress, and the argument we made stands.
This post is about the half of the problem those products do not reach.
Because almost everything being built to govern agents rests on the same assumption.
That the agent tells you what it is.
What is being built
The emerging approach is an identity approach, and on its own terms it is sensible. Agents get registered. They are issued their own credentials rather than borrowing a person’s. They attest to what they are. Their permissions are scoped to a defined task, and their activity is attributed to them rather than disappearing into a human’s audit trail.
If you are deploying agents deliberately — procured, catalogued, wired into systems on purpose — all of that is worth doing, and organizations that skip it will regret it. That is the case we made last October and we would make it again.
But every one of those controls begins at the same place: something arrives, declares itself, and is evaluated on the strength of that declaration.
Two cases the declaration does not cover
The agent operating inside a human’s session
A person authenticates. Correct credentials, compliant device, a session opened for entirely legitimate reasons. Something then acts through that session on their behalf — a browser extension, an assistant with access to the desktop, a tool the user connected to their own account last month because it saved them an hour a week.
At the front door there is nothing to see. The authentication was valid, because it was the human’s. No new principal appeared. No registry was consulted, because nothing asked to be registered.
This is not a hypothetical failure mode. It is the ordinary way agents are reaching enterprise systems today, in most organizations, without anybody having decided that it should be so.
The thing that will not be declaring anything
The second case is simpler. An attacker’s tooling has no interest in attestation. Neither does a script somebody wired up on a Friday, or malware behaving the way malware now behaves.
A governance model built on cooperative declaration governs the cooperative. That is worth saying plainly, because it is easy to buy a registry and believe the problem has been addressed.
Why this cannot be closed at the front door
If the only point at which a system observes access is the moment of authentication, then an agent operating inside an authenticated session is not a gap in the policy. It is invisible to the mechanism entirely.
There is nothing anomalous to detect. The credentials were right. The device was compliant. The decision was correct. Everything the system was designed to examine looked exactly as it should.
An architecture that is not in the path of the session cannot inspect what happens inside it — not because of a missing feature, but because that traffic never passes through it. This is the same structural limit that decides which applications a platform can front, arriving in a different form.
Identification still matters — but only from inside the session
None of this argues that identifying agents is unimportant. It matters a great deal, and the case that matters most is precisely the one a registry cannot help with: determining whether a session that authenticated as a person is actually being driven by one.
That determination is possible. But it cannot be made at the point of authentication, because at that point there is nothing to observe. It can only be made from inside the session, by watching what the session does — the pace and regularity of requests, the pattern of what is reached and in what order, behavior no person sitting at a keyboard would produce.
Which brings the argument back to position. If you authenticate and then abdicate, you have no way to identify malicious behavior during a session. You have a verdict on who knocked, and nothing whatsoever on what came through the door.
Being in the path is not only what lets you contain an agent you failed to identify. It is what gives you the chance to identify it in the first place.
A different question
And identification will sometimes fail regardless. So the second question, asked alongside the first rather than instead of it: what can any session reach if you do not spot what is driving it?
That reframing changes what a control has to accomplish. Identification is a race — new agent types, new tooling, new ways of blending into legitimate activity, and a detection model that must stay current with all of it. Containment is not a race. It does not depend on recognizing the thing at all.
What containment looks like in practice
Total Access Control publishes the resource, not the network.
A session is granted access to specific applications. It does not receive a route onto a network from which other things are reachable, because there is no route to receive. Everything the session does passes through the enforcement point, and the enforcement point is still there for the duration.
So if something is operating inside that session — an agent the user connected, an agent nobody knows about, or something considerably worse — it is confined to what the session was granted. Not because it was identified. Because there is nowhere else to go.
The blast radius stops being “whatever is reachable from the network” and becomes “the resources this session was granted”. For an undetected agent, that difference is the entire outcome.
What is actually being argued
Registering agents, issuing them their own credentials and attributing their activity are all good practice. We said so a year ago and nothing since has changed our view. An organization deploying agents deliberately should do all three.
The argument is about what you depend on, and where the work happens. A model that only works when the agent cooperates has a defined failure mode, and that failure mode is the adversarial case — the one that matters most. Observation from inside the session is what narrows it. Containment is what holds when it fails anyway.
Neither is available to something that stepped out of the path.
The question worth asking
Not: can we tell which agents are operating in our environment?
But: if one is operating that we cannot see, what can it reach — and how would we know what it reached?
If the answer to the first half is “whatever the user could reach from the network”, then the agent question is not really an agent question. It is the same architecture question, arriving with a new name.