Key facts.
- RBAC was built for predictable, deterministic systems and stable human job functions, neither of which describes an AI agent. source
- An agent's path is non-deterministic and expands to fill whatever access is available; authenticating it without scoping leaves the reach decided by model inference at runtime. source
- When an agent runs on behalf of a user, it often inherits that user's session permissions, silently gaining elevated rights far beyond the task. source
- The confused deputy problem (a privileged program tricked into misusing its authority by a less-privileged caller) maps directly onto an injected agent, and the MCPTox benchmark shows it in practice: malicious instructions hidden in tool metadata steered 20 production agents into misusing their own legitimate tools at attack success rates up to 72%. source
Why does a human permission model break the moment an agent uses it?
A human in the finance role opens the finance tools, does the task, and stops. The role and the behavior line up because a person exercises judgment about what they actually need. An agent in the same role does not stop at intent. It explores. If the role can reach a tool, the agent can reach it too, and a single injected instruction can point that reach somewhere you never planned. The permission model never lied. It simply assumed a human's restraint that an agent does not have.
Privilege inheritance makes this sharper. Run the agent under a user's session and it picks up that user's rights wholesale. Give it to an admin and you have handed an admin's keyring to a system that decides what to open based on a probabilistic guess. That is the confused deputy in modern dress: the agent has real authority and an attacker supplies the intent.
What replaces role-based access for agents?
Scope below the role. Give each tool the least privilege it needs, issue short-lived credentials instead of standing ones, and isolate the agent's identity from the user's so it cannot inherit a person's full rights. Evaluate access against the resource, not the agent's self-reported intent, so the agent cannot talk its way into something it was never granted.
| Question | Human RBAC answer | What an agent needs |
|---|---|---|
| What can it reach? | Everything in the role | Only the resource this task needs |
| Whose identity? | Inherits the user's | Its own, isolated from the user |
| How long? | Standing credentials | Short-lived, task-scoped tokens |
| Decided by? | Stable role assignment | Deterministic policy on the resource |
RBAC fits one human role; an agent fills the open reach at runtime, and a more capable model only widens that door, so rework lands on whoever skips scoping. (arXiv:2508.14925)
This is permission as a pattern property, which is exactly what the Pattern Intelligence Layer is for. Reliability at the pattern level means scope and identity are enforced around the agent's behavior on every run, not granted once to a role and hoped to hold. The agent gets exactly the reach the task needs, the confused deputy has nothing to exploit, and the model underneath can change without reopening the door.
Frequently asked questions
Can't we just give the agent a restricted role?
A restricted role still grants everything inside it, and an agent fills the whole grant. You need scoping below the role, at the tool and resource level.
What is the single biggest mistake here?
Running the agent under a user's session so it inherits that user's privileges. Isolate the agent's identity from the user's.
Does fine-grained authorization fix the confused deputy?
Largely, yes. Evaluating access against a resource graph rather than the agent's stated intent means it cannot reach what it was never granted.