Why Role-Based Access Control Breaks Down for AI Agents

A role is a bet. More precisely, it's a bet that the person asking for something today is doing roughly the same kind of operation as the person who asked for it yesterday, and that both of them are who they say they are. For decades, that bet paid off reliably enough that nobody questioned it. Humans have stable job functions. One person reasonably has a consistent set of intentions per session. The whole architecture of role-based access control is built on that assumption.

Then AI agents showed up and broke that assumption in two fundamental ways. First, a single agent session now carries multiple identities, the agent itself and the entity that invoked it. Second, agents act non-deterministically, so tasks cannot be pre-provisioned. This article covers the nuances of both conditions and where that leaves teams implementing access control for agentic systems.

The agent identity problem

An agent authenticates to your backend systems once, as itself, using its own credentials or service account. It then serves a stream of different humans through that single authenticated identity. No re-authentication happens as each new person arrives because agents were not built to work that way.

So two employees, one in finance and one in operations, ask the same AI assistant the same sensitive question on different days. The agent answers both of them from inside the same authenticated session, pulling from the same data it has access to. There is no way to distinguish who is actually asking at the moment data is touched. From the system's perspective, both employees are the same identity. The agent is correctly answering for the identity it has, which is its own. The problem is that "itself" is doing the work of a dozen different people with different clearance levels. Nothing downstream can tell the difference.

The instinct is to reach for more roles. Give the agent a more specific role. Map roles to departments, to data domains, to use cases, to teams. But a role describes a category of person. It doesn't restore the missing link between a specific question and the specific human asking it. More categories just make the composite more difficult to reason about. The issue is actually a layer deeper.

The non-determinism problem

An agent session doesn't have a fixed shape. What starts as a simple lookup can become a cross-system (or even cross-agent) aggregation. That aggregation can become the input to a write action. All of this can happen in the same exchange, with follow-up questions that seem perfectly reasonable in sequence even if the session starts heading into sensitive territory.

This is where the other half of the original assumption falls apart. Role-based access control relies on two things being stable: who is asking, and what kind of tasks they're doing. A payroll manager doing payroll manager tasks makes complete sense; however, a payroll manager whose session has silently ventured into cross-system reporting and is now about to write a record somewhere is a different situation entirely. The common approach is to create a single role broad enough to cover every plausible action the agent might take. This prevents the system from breaking, but dissolves least privilege entirely.

The same fix

The two breaks look separate only because governance efforts are typically split across teams, one for identity, one for task scope. They are the same failure, and it must be addressed at the architectural layer.

Roles operate at the level of the actor. They describe a category of person, assigned in advance, applied at login, and held constant for the session. What's actually needed is a decision made at the level of the individual query, at the exact moment it touches real data.

When policy is evaluated at runtime, identity is checked with all relevant context and carried to the data layer. When a specific query hits a specific record, the system knows not just that an authenticated agent is asking, but who is behind the request at that moment. Roles become one input among several that help feed into the authorization decision.

Closing thoughts

Simply put, decisions are being made one level too high in traditional RBAC. Vetting whether a system can handle AI agents is straightforward. Ask at what level does it actually make permission decisions. Does it decide at the level of the person, the role, or the query? Most systems decide at the role level, because that's where the tooling is mature and the mental models are established.

Now, the decision must move down to the query. Peaka is built to solve this problem. It is a data virtualization layer that sits on top of the systems a team already runs, including warehouses, databases, internal APIs, and operational systems. It exposes all of these systems through a single SQL interface, so every query an agent issues passes through one place before it reaches any underlying source. Peaka resolves each of those queries under the caller's own identity and applies classification and audit at that same layer.

That design holds up in the aggregation and write scenarios described earlier. When a session drifts from a simple lookup into cross-system reporting or a write action, each step is evaluated as its own query against the acting user's permissions. No single broad role has to be provisioned in advance to cover whatever the session might become, given that the access decision is made per request rather than at login. That is what lets a single agent hold one set of credentials to your systems while still answering each person according to what that person is allowed to see.

If you’re looking to establish access controls at the query level, book a demo with Peaka.