The assumption scopes were built on
An API key, an OAuth scope, and a role in an RBAC system all encode the same kind of statement: this caller is permitted to use this capability. The model works because the caller is deterministic software whose behavior was reviewed before it shipped. If a service holds a key that can issue refunds, someone decided that issuing refunds is part of its job, and the code path that issues them is the one an engineer wrote.
An agent breaks that chain. The credential is still scoped. What the agent does with it is decided at runtime, by a model responding to input, and that input may be a hostile web page or a document someone poisoned upstream. The permission was granted once, to a job description. The action is taken later, by something that rereads that description every time.
The failure is authorized, not unauthorized
This is what makes agent incidents awkward to reason about. The usual security question is whether an attacker got hold of a credential they should not have. Here nothing is stolen. The agent uses its own valid credential, inside its own scope, to do something nobody wanted, and every log line looks legitimate because by the standards of the access-control system it is.
OWASP catalogues this as excessive agency. The framing matters: the weakness is the breadth of what a credential permits, measured against what any single action should be allowed to do. Tightening scopes helps at the margin, then stops helping, because the useful scope and the dangerous scope are usually the same one. An agent that can send email on your behalf can send the wrong email to the wrong person. No scope tells those two calls apart.
What changes when the action becomes the unit
Moving the decision to the action changes what gets evaluated. Instead of asking whether this identity may call this endpoint, the system asks whether this specific invocation should proceed: these parameters, this recipient, this amount, this hour, this agent's recent behavior, this policy version.
That can only be answered at the moment of the call. It also produces something a scope check never does: a record of a judgment, covering which rule permitted the call and what the alternative would have been.
- A scope is decided at provisioning time. It answers whether an identity may ever do this at all.
- An action decision is decided at execution time. It answers whether this specific call should proceed now.
- The first yields access. The second yields an auditable verdict, plus somewhere to escalate when policy will not settle the question alone.
Why the enforcement point cannot live in the prompt
A recurring mistake is to implement this as instruction: tell the model to refuse dangerous actions, or to ask before spending money. That puts the control inside the system the attacker is manipulating. Anything expressed as text in the model's context can be argued with by other text in the model's context.
The enforcement point has to sit where the model has no reach: the gateway or runtime that performs the call. The Model Context Protocol's authorization specification takes this position for tool access, delegating to OAuth 2.1 rather than trusting the model to police itself. The same logic extends past access to the action itself.
Where this leaves existing IAM
None of this makes identity and access management obsolete. The decision layer consumes it: an action decision is only meaningful if the requesting agent's identity is established, and the scopes it holds remain the outer boundary of what is even considerable. What changes is that the outer boundary stops being the whole answer.
Most teams arrive at two layers. Identity and scope decide what an agent could do. A decision point decides what it may do right now, escalating to a human when the stakes exceed what policy will settle alone. The second layer has no settled tooling yet, which is why most teams building on agents end up writing some version of it themselves.