Access control asks a simple question: may this principal perform this action on this resource? Decades of engineering have gone into answering it quickly and correctly, and the answer is generally right. Autonomous agents break the model not by defeating it but by satisfying it.
When an agent acts on a user's behalf using that user's credentials, every check in the path evaluates the user's permissions and returns the correct result. If the user may read the document, the agent may read the document. The system has no way to express the thing an administrator actually cares about, which is whether reading this particular document, at this moment, in service of this task, is a reasonable thing to be doing.
Aggregation is the characteristic failure
The failures that matter here are rarely single unauthorised actions. They are large numbers of individually authorised ones. A support agent granted read access to customer records to answer a question can, in the course of answering it, read a great many records. Each read passes. The aggregate is a data exposure that no individual permission check could have caught, because at no point was anything impermissible done.
This is why rate limiting and volume anomaly detection have become part of agent governance discussions rather than purely operational concerns. They are among the few controls that operate on the aggregate rather than the individual action.
Delegation as the unit of governance
The control that is missing is one that carries purpose alongside permission. A delegation record states what an agent was asked to do, what it was authorised to touch in service of that, and when the authorisation lapses. An action can then be evaluated against the delegation rather than only against the identity — and an action outside the delegation can be refused even though the underlying identity permits it.
Several vendor frameworks now describe something along these lines under varying names. The common elements are a scoped, time-bounded grant; a record of what the agent was actually asked to accomplish; and an enforcement point that sees both.
What incident response needs and usually does not have
Reconstructing an agent incident requires knowing not only what the agent did but why it did it — which tool it selected, on what basis, and what it had in context at the time. Most logging captures the first and none of the rest. An organisation that can list every API call an agent made and cannot say what prompted any of them will find the review taking weeks rather than hours.
Organisations deploying agents against production data should establish, before an incident, whether they could answer that question. The answer is usually no, and it is much cheaper to discover that in advance.