Role-based access control has been the load-bearing wall of enterprise identity for almost three decades. It was a genuine innovation when it emerged, a way to scale access decisions beyond individual entitlement grants, mapping permissions to functions rather than people, making audits tractable and provisioning predictable.
It is also reaching the end of what it can do.
Not because RBAC was poorly designed. Because the identities it was designed to govern no longer represent the majority of what enterprises need to control. RBAC assumes a relatively stable mapping between who an identity is and what it should be able to access. That assumption holds for most human employees and most service accounts. It does not hold for enterprise AI agents, and the gap is becoming the central identity governance problem of this decade.
Here is the core problem in one sentence: RBAC does not scale to populations of identities whose required access changes as fast as enterprise AI agents do. A model built on stable, periodically reviewed roles cannot keep pace with identities whose effective scope shifts within a single session. This is not a minor friction point. It is a scaling failure, and it is the reason the rest of this piece exists.
This is not a hypothetical shift. It is happening now, across the industry, for structural reasons that apply regardless of which vendor or platform you use.
What RBAC Actually Assumes
To understand why RBAC is hitting its limit, it helps to be precise about what it assumes.
RBAC defines a role - Finance Analyst, IT Administrator, Sales Manager - and assigns a fixed set of permissions to that role. An identity is granted the role, and it inherits the role's permissions. The model works because, for most of the identities it governs, the relationship between role and required access is stable. A Finance Analyst needs access to the general ledger and accounts payable system today, and will need substantially the same access next month.
This stability is the foundation the entire model rests on. Stable roles make audits tractable; you can review what a role can access without reviewing what every individual identity holding that role actually does. Stable roles make provisioning predictable: assign the role, the access follows. Stable roles make governance scalable; you manage a manageable number of roles instead of an unmanageable number of individual entitlement decisions.
Take away the stability, and the model does not fail gracefully. It fails because every part of its value proposition depends on the assumption holding.
Why Enterprise AI Agents Break the Stability Assumption
An enterprise AI agent does not have a stable relationship between its identity and its required access, and this is true for reasons that are structural to what agents are, not incidental to how any particular agent happens to be deployed.
An agent's required access depends on its goal, not its role. A support agent summarizing a ticket needs read access to the ticketing system. The same agent, asked to issue a refund, needs write access to the billing system. The same agent, asked to escalate a complex case, needs access to a different team's queue. These are not different roles. This is one agent, whose required access shifts based on the specific task it is executing in a specific moment.
An agent's required access depends on who it is acting for. The same Finance agent invoked by a junior analyst and invoked by a controller may need to operate within meaningfully different boundaries, not because the agent has two roles, but because the appropriate scope of an action depends on the authority of the human on whose behalf the agent is acting.
An agent's required access depends on the environment it is touching. A coding agent operating in a sandbox needs different access than the same agent opening a pull request against production. A data agent querying a test database needs different access than the same agent querying the live customer record system. The environment, not the agent's static role, is what should determine the access boundary in many of these cases.
An agent's effective scope changes faster than any role definition can be updated. New tools get connected. New workflows get built around the agent. New integrations expand what the agent touches. A role defined for an agent on the day it was provisioned is frequently outdated within weeks, not because anyone made an error, but because the pace at which agents are integrated into new workflows outstrips the pace at which anyone is updating governance records to match.
This is the structural mismatch. RBAC requires roles to be stable enough that defining them once and reviewing them periodically is sufficient governance. Enterprise AI agents do not produce stability at that timescale. They produce constant, legitimate variation in what access is actually needed - driven by goal, by principal, by environment, and by the speed at which new capability gets connected.
The False Comfort of Granular Roles
The most common response to this mismatch is to make roles more granular. Instead of one broad "Finance Agent" role, define ten narrower roles: Finance Agent: Reporting, Finance Agent: Reconciliation, Finance Agent: Vendor Payments, each scoped more tightly to a specific function.
This buys time. It does not solve the structural problem.
Granular roles still require someone to anticipate, in advance, every distinct functional context an agent will operate in and define a role for it. Agents do not stay within the functional boundaries anyone anticipated at provisioning time. A reconciliation agent that starts being invoked for exception handling is now operating outside any of the roles that were defined for it, and the governance team is now in a permanent race to keep granular role definitions current with what agents are actually being asked to do.
The granularity treadmill does not change the underlying assumption RBAC depends on. It just makes the consequence of that assumption breaking arrive somewhat later, at somewhat higher administrative cost.
Meet the Guardian Agent
The alternative is not "no roles" or "no structure." It is a different governing question, and a different governing actor.
RBAC asks: what role does this identity hold, and what does that role permit? It answers this question once, at provisioning, and then steps back.
Intent governance works differently. Think of it as a Guardian Agent, a continuous, observant layer whose entire job is to make sure that no matter how fluid an agent's permissions become, it can never veer off course from its approved plan. The Guardian Agent does not grant access. It does not replace the role structure. It watches what an agent actually does and asks, continuously: is this still consistent with what this agent was authorized to accomplish?
This distinction matters because it reframes intent governance from a technique into an actor with a job. RBAC defines the boundaries. The Guardian Agent polices them, in real time, for every action, across every session.
There is a second scenario where the Guardian Agent becomes not just useful but essential: what we call Fluid RBAC. Some organizations, recognizing that narrow roles choke agent productivity, take the opposite approach, granting agents broad, maximum access up front so they are never blocked by a missing permission. This solves the productivity problem. It creates an enormous exposure problem, because broad access with no continuous oversight is exactly the condition that makes a single compromised or drifting agent catastrophic.
This is where the Guardian Agent functions as a safety circuit breaker. When permissions are wide open by design, the Guardian Agent is the only thing standing between "maximum access" and "uncontrolled access", continuously monitoring behavior, comparing it against the agent's actual approved purpose, and intervening the moment behavior diverges from intent, regardless of whether the action was technically permitted.
In practice, intent governance, the Guardian Agent's operating model, works on two levels that work together.
Organizational intent, captured at provisioning. This is still a structured definition: what business function is this agent built to serve, what systems should it be able to reach, what data types should it be able to exchange, and critically, whether it should be able to read, write, or delete. This is not the absence of structure. It is the foundation everything else builds on, and it is the plan the Guardian Agent is enforcing adherence to.
Runtime evaluation against that intent, continuously. Rather than treating the provisioning-time definition as the final word, the Guardian Agent continuously evaluates whether the agent's actual behavior, the tools it is invoking, the data it is touching, the actions it is taking, remains consistent with the organizational intent established for it. Not "does this identity have the role that permits this action" but "is this specific action, right now, consistent with what this agent was actually built to do."
The shift is from a static credential check to a continuous consistency evaluation. RBAC asks the question once, at the moment access is requested, based on a role that was defined in advance. The Guardian Agent asks the question continuously, based on what the agent is actually doing in the moment, evaluated against a baseline that reflects its real purpose.
Why CISOs Should Care About This Shift
For a CISO, the RBAC-to-intent shift is not a technical implementation detail. It changes what your governance program can actually promise.
A governance program built on RBAC for AI agents can tell you, at any point in time, what an agent is technically permitted to do. It cannot tell you, with any confidence, whether what the agent is actually doing right now is appropriate, because appropriateness depends on context that role membership does not capture.
This is the gap that produces the incidents nobody saw coming. An agent operating entirely within its technically permitted role, taking an action that is completely inconsistent with what anyone intended when they built it. The audit log shows a compliant action. The actual outcome is one nobody authorized.
CISOs reporting to the board on AI agent risk need to be able to answer a harder question than "do our agents have appropriately scoped roles." They need to be able to answer "are our agents doing what we built them to do, right now, and would we know if they weren't?" RBAC alone cannot answer the second question. It was never designed to.
Where IAM Effort Has to Shift
For IAM teams, the shift changes where governance effort needs to be invested.
RBAC-centric governance concentrates effort at provisioning - defining roles correctly, mapping identities to roles accurately, periodically reviewing role definitions. This is necessary work, and it does not go away. But for agent populations, it stops being sufficient the moment an agent's first action deviates from what its role definition anticipated, which, given how fast agent capabilities and integrations expand, happens quickly and continuously.
Intent-based governance - the Guardian Agent's operating model - requires IAM teams to build capability they may not have needed before: continuous behavioral observation, baseline establishment for what "consistent with intent" actually looks like for each agent, and drift detection that distinguishes between legitimate adaptation and genuine policy violation. This is a meaningful operational shift, from governance that is heaviest at the moment of provisioning to governance that is continuous across the agent's entire operational lifecycle.
It also changes the skills the team needs. Reviewing role definitions against job functions is a different exercise than evaluating whether an agent's reasoning chain and tool invocation pattern are consistent with its stated purpose. IAM teams building for the intent-based model need visibility into agent behavior at a level of technical detail that traditional access review processes were not built to provide.
RBAC Doesn't Disappear. It Evolves Into a Negative Security Model
None of this means RBAC is obsolete or that organizations should abandon role-based structures for their AI agents. But its job changes fundamentally.
In an intent-driven world, RBAC stops being a clunky, ever-expanding matrix of "allow" rules that someone has to maintain in lockstep with how agents actually behave. It evolves into something simpler and more durable: a Negative Security Model.
Instead of trying to enumerate every permission an agent should have, a losing battle against agents whose effective scope shifts with goal, principal, and environment, security teams define what is critically forbidden. The hard boundaries that can never be crossed, regardless of context: systems that must never be touched, actions that must never be taken, data that must never leave a defined perimeter. A short, stable, defensible list.
Inside those hard boundaries, the Guardian Agent polices fluid execution in real time, continuously evaluating whether what the agent is actually doing remains consistent with its approved intent, intervening the moment it doesn't, regardless of whether the action was technically permitted.
This is the version of RBAC that scales. Not a permission matrix that someone has to keep rewriting every time an agent's workflow changes, but a small number of non-negotiable boundaries, enforced absolutely, with a continuously observant layer governing everything that happens inside them.
RBAC got identity governance this far. The Negative Security Model - RBAC's hard boundaries, governed continuously by the Guardian Agent - is what gets it through what comes next.
The Window Is Now
The industry is converging on this shift quickly. The conversations happening across the identity and security community this year - at conferences, in analyst research, in vendor roadmaps - are increasingly framed around the same recognition: access for autonomous identities needs to be contextual, intent-based, and continuously evaluated, not just role-assigned and periodically reviewed.
The organizations that build this capability now, while AI agent populations are still measured in the dozens rather than the thousands, will have governance infrastructure that scales with them. The organizations that wait will find that the granularity treadmill of ever-more-specific roles cannot keep pace with how fast agent capability is expanding, and that the gap between what their RBAC program can promise and what their board is asking them to guarantee keeps widening.
Define the hard boundaries. Let the Guardian Agent govern everything that happens inside them.
Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.
