Does RBAC work for AI agents?

RBAC stands for role-based access control: granting permissions by role, such as "support engineer," rather than person by person. It is how most companies manage human access, and it works because humans fit roles. An AI agent is a large language model given tools and permission to act in a loop, and it does not fit a role. It may act on behalf of many different users in one afternoon, need wildly different access from task to task, and exist for minutes rather than years.

If you are approving an agent deployment and the access plan is "we gave it the same role as the team that runs it," that is the part to slow down on. A role sized for a human team is standing, broad access. Handing it to software that acts thousands of times faster than a human, and can be tricked by content it reads, changes what that role means.

Where RBAC strains, and what breaks

The first strain is scoping. Least privilege, the principle that anything should get the minimum access needed for its task, is the stated goal of every access program. Roles approximate it for humans because a human's job changes slowly. An agent's "job" is whatever the current task demands, so any role broad enough to cover all its tasks is too broad for most of them.

The second strain is delegation. When an agent acts for a user, whose permissions apply? If the agent's own role is broader than the user's, you have built a confused deputy: an attacker, or simply a prompt injection hidden in content the agent reads, can use the agent's authority to do what the requesting user never could.

This is measurable, not hypothetical. A 2026 study tested three popular agent frameworks (LangGraph, CrewAI, and AutoGen) plus the Model Context Protocol's authorization model against four attack classes, including confused-deputy and prompt-injection escalation. Three of the four offered no built-in confinement and one offered only partial protection; an external authorization broker the authors built blocked all four attacks (arXiv). The practical reading: the framework your team likes will probably not enforce your access model for you.

None of this means discarding RBAC. It means treating roles as the coarse outer boundary and adding finer controls inside it: permissions scoped to a task, time-boxed rather than standing, intersected with the requesting user's own access, and enforced by something outside the agent's own code.

What to ask vendors

• Can permissions be granted per task and expire on their own, or is every grant standing until someone revokes it?
• When an agent acts on behalf of a user, is its effective access the intersection of its own permissions and that user's?
• Is authorization enforced by an external control point, or does it rely on the agent framework behaving as documented?
• Are high-risk actions gated behind human approval, and can we define which actions count as high risk?
• Does the audit log record the permission that authorized each action, so we can trace a bad outcome back to a bad grant?
• How fast does revocation propagate to an agent already in the middle of a task?