RBAC Design for AI Agents in the Enterprise
Traditional RBAC was engineered around a human principal. A person has a job function; that function maps to a role. The role carries permissions. The person shows up at predictable times, works within observable bounds, and when they leave, someone revokes their access. For twenty years, that was reasonable enough.
The model was built on assumptions nobody bothered to write down: that the principal has a stable function, that sessions are bounded in time, that audit trails connect to a human identity, and that the principal exercises only a fraction of their entitlements at any given moment. Agents violate all four simultaneously. That is not a minor compatibility issue; it is a structural mismatch between a governance model and the thing it is now supposed to govern.
When an agent inherits a user's session scope, it receives every permission that user holds, including the ones with no bearing on the task. In multi-step agent chains, those permissions pass from agent to agent without anyone re-evaluating them at each handoff. Agents provisioned for a project keep running long after the project ends because nobody set a decommission date. And when something goes wrong, the tool calls an agent made are often unattributed to any specific identity, which makes forensic investigation difficult and accountability nearly impossible to establish.
A 2026 survey found that 70% of organizations grant AI systems more access than they would give a human employee doing the same job. [Citation needed for this survey.] That is not malice; that is inertia: the path of least resistance is to provision the agent with whatever the creating user already has.
A person rarely exercises more than a small fraction of their standing entitlements in any given workday; an agent can exhaust the full grant programmatically, in seconds, with no one watching. There is no stable job function to anchor role assignment, task requirements shift per invocation, agents run as parallel instances, and every one of those instances is exposed to prompt injection. Apply inherited-role logic across a hundred agents and you have not built an access control system; you have built a liability that scales with your deployment.
What ungoverned agent permissions actually cost when something goes wrong
IBM's 2025 Cost of a Data Breach Report found that 97% of organizations reporting an AI-related security incident lacked proper AI access controls at the time. That is not primarily an indictment of security teams; it is a description of how agents actually get provisioned: with defaults, not decisions.
The mechanism that converts excessive permissions into a security event is often prompt injection. Malicious instructions embedded in documents, emails, web pages, or code repositories that an agent processes become directives the agent executes with whatever permissions it holds. The agent's permission scope determines the blast radius. Research testing multi-turn injection attacks across open-weight models found success rates as high as 92% under certain conditions. [Citation needed for this research.] In August 2025, Anthropic disrupted a cybercriminal operation that weaponized an AI coding tool to automate reconnaissance, credential harvesting, and network penetration across at least 17 organizations, including healthcare providers, government agencies, and emergency services. [Citation needed for this incident report.] The agents were doing exactly what they were told; the instructions just came from the wrong source.
Identity exposure compounds the problem at scale. SpyCloud's 2026 Identity Exposure Report recaptured billions of exposed records, with millions of credentials or authentication cookies specifically tied to AI tools. A separate vulnerability in a major enterprise AI platform allowed unauthenticated attackers to impersonate any user, including administrators, using only an email address. [Citation needed for this vulnerability disclosure.] When agent credentials are accessible in that way, the standing permissions those credentials carry become the actual risk surface.
Gartner projects that by 2028, 25% of enterprise security breaches will involve the misuse of AI agents. [Citation needed for this Gartner projection.] The conditions for such incidents already exist in many enterprise deployments, sitting quietly beneath provisioning defaults nobody has revisited.
Why agents need to be registered identities before they can have governed permissions
You cannot govern a population you cannot enumerate. That is the foundational problem with agent access control in most enterprises today, and everything downstream of it, all the RBAC tuning, the policy refinement, the observability tooling, is built on sand if this step is skipped.
Machine identities now outnumber human identities by more than 100 to 1 in the average enterprise, and the ratio keeps climbing. [Citation needed for this figure.] In cloud-native environments, the gap is wider still. One audit of a large financial institution surfaced more than 4 million non-human identities against roughly 50,000 human accounts. [Citation needed for this audit.] Most of those machine identities had no owner, no review cycle, and no planned end date.
For agents specifically, a 2025 analysis found that 51% of organizations report no clear ownership of AI identities. Only 44% have implemented any policies to manage them, despite 92% agreeing that governing them is critical. [Citation needed for this 2025 analysis.] That gap between stated priority and actual infrastructure is not subtle.
An agent without a registry entry has no owner, no review cadence, and no one accountable for decommissioning it when the project that created it ends. These are the zombie agents: provisioned for experiments or proofs of concept, still active and still holding credentials months or years later. They are the direct result of skipping identity registration.
Treating an agent as a first-class identity requires specific things. A unique identifier assigned at provisioning, not borrowed from the creating user. An assigned owner who is accountable for what the agent can access. An independent lifecycle covering creation, periodic permission review, and a decommission date that does not depend on whether the owning employee is still at the company. And a record in a registry the organization can actually query. That registry is the infrastructure on which every subsequent access control decision depends; without it, you are applying governance to a population you cannot see.
How to assign permissions agents actually need rather than permissions they happen to inherit
Once agents exist as registered identities, the discipline is assigning permissions that were chosen, not defaulted to.
Least privilege, applied per task rather than per session, is the governing principle. Each agent holds the minimum permissions necessary to perform its designated function, and every tool call is treated as a new authorization event rather than a continuation of a standing grant. A compromised agent can then only exercise what it was explicitly assigned for the current task.
Categorizing agents by function and risk tier is the practical way to make this tractable. Read-only agents retrieve and analyze information; they carry the lowest privilege tier. Action agents execute defined workflows within bounded parameters; they sit in the middle. Orchestrator agents coordinate other agents and systems; they carry the highest privilege tier and warrant different review cadences and approval gates rather than the same provisioning defaults applied uniformly. The categories are not rigid, but they force an explicit decision about where each agent sits before anyone assigns it a single permission.
The choice between standing entitlements and just-in-time grants maps naturally to that tiering. Standing permissions are appropriate for routine, low-risk, fully reversible actions an agent performs continuously. Just-in-time grants, elevated permissions issued for the duration of a specific task and automatically revoked when the task completes, belong on anything touching sensitive data, external systems, or irreversible state changes. Choosing between them requires an explicit decision every time; that is the point.
Human confirmation belongs in this architecture as a deliberate design element, not an afterthought. Irreversible, high-impact actions, sending external communications, executing financial transactions, modifying access permissions, transmitting data outside the enterprise perimeter, should require a human to confirm before the agent proceeds. Scoping those confirmation requirements to action categories rather than to individual agents keeps the system manageable as agent counts grow.
Why pure RBAC is the starting point, not the complete answer, and what to layer on top
RBAC handles baseline permissions cleanly. It is simple to implement, straightforward to audit, and entirely appropriate for stable, predictable agent functions. The problem is that it cannot adapt to context, and agents operate in context constantly. That is not a criticism of RBAC; it is a description of what RBAC was designed to do, and the boundary of where it stops being sufficient.
When the same agent needs different permissions for the same resource class depending on whether it is operating in production or test, during business hours or off-hours, on behalf of a privileged user or a standard one, pure RBAC issues the same grant regardless. It simply has no mechanism for those distinctions.
Attribute-based access control adds the context sensitivity RBAC lacks. It evaluates multiple attributes simultaneously: agent identity, resource classification, environment state, action type, time of day. The same agent receives different permissions for the same resource depending on which combination of attributes applies at the moment of the request. For agents with variable task scopes, this is a prerequisite for accurate access control rather than a nice-to-have.
Policy-based access control centralizes the enforcement logic. A policy engine evaluates complex, conditional rules rather than hardcoding permissions per agent. This matters when you have hundreds of agents and a threat landscape that changes faster than provisioning cycles, because policies can be updated without reprovisioning individual identities.
Task-based access control reframes the question entirely: what does this task require, rather than what does this principal hold? Permissions are issued for the duration of a task and expire when the task completes. This structurally enforces least privilege without depending on manual revocation, and it is especially well-suited to orchestrator-to-subagent delegation chains where standing entitlements should not travel intact down the chain.
The practitioner consensus, reflected in reference frameworks published by Microsoft, Oasis Security, and WitnessAI throughout 2026, is that no single model is sufficient. [Citation needed for these frameworks.] RBAC sets the baseline. ABAC adds context awareness. PBAC centralizes decisions. Just-in-time applies to the highest-risk actions. Which layers to prioritize should be determined by the risk tier of the agents already in production, not by what is theoretically ideal.
The delegation problem: how permissions should travel when one agent hands work to another
Multi-agent systems are the norm at enterprise scale. An orchestrator coordinating a research agent, a payment processor, and a communications agent creates a delegation chain, and each handoff in that chain is a permission decision, whether or not anyone is treating it as one.
Traditional RBAC has no mechanism for reducing permissions at each handoff. The default is that the full grant travels intact. A subagent several steps down the chain is operating with the orchestrator's full permission scope on a task that required only a fraction of it; least privilege was applied once at the top and then abandoned at every subsequent step.
The Model Context Protocol, widely adopted as a standard for tool and resource access in agentic systems, currently provides no standard mechanism for agent-to-agent permission transfer at handoff. [Citation needed for this characterization of Model Context Protocol's current capabilities.] Each subagent authenticates independently, with no way to prove the delegation chain or enforce permission reduction. Without a gateway enforcing delegation rules, a subagent can act on permissions it should never have received.
Safe delegation requires permission reduction at every handoff: a subagent receives only the subset of the orchestrator's permissions that the specific subtask requires, never the full grant. It requires delegation provenance: the system records which agent issued the delegation, what permissions it carried, and what actions the subagent took under that delegation. And it requires no lateral trust by default: a subagent cannot invoke peer agents or external tools that the orchestrator did not explicitly authorized for this task. Omit any one of these and the chain collapses into a single exploitable surface.
Prompt injection is especially dangerous in multi-agent chains precisely because permissions travel unchecked. An injection at the subagent level can be acted on with the orchestrator's full permission scope if no reduction happened at the handoff. The attack surface expands proportionally with the length of the chain, which means longer chains require stricter delegation discipline, not looser.
What real-time observability adds to permissions that static role assignments cannot
A permission configuration describes what an agent is allowed to do; observability describes what an agent is actually doing. In most enterprise environments, the gap between those two things is where incidents develop, quietly, before anyone notices.
Many machine identities across enterprise environments carry excessive privileges that no one has reviewed since the original provisioning. [Citation needed for this claim.] An audit log read after an incident describes what happened; it does not interrupt what is happening. That distinction matters when the actions being taken are irreversible.
Real-time observability changes the operational posture in concrete ways. Behavioral anomaly detection catches an agent accessing resources outside its normal task pattern, which surfaces a prompt injection or credential compromise in progress rather than in retrospect. Permission right-sizing becomes possible when you can observe which permissions agents actually exercise over time, revealing standing entitlements that can be safely removed without breaking function. And delegation chain visibility, knowing which agent invoked which tool, under which delegation, and what data it touched, provides the forensic trail that makes post-incident investigation tractable and regulatory compliance defensible.
Before you can monitor agent behavior, you need to know which agents exist. MCPManager creates that registry at the gateway level, giving organizations a record of which agents exist, who owns them, and what permissions have been deliberately assigned rather than inherited. The registry is the prerequisite; observability makes the registry operationally useful rather than just administratively correct.
None of this requires perfection. It requires intention, applied consistently, starting with the most basic question most enterprises still cannot answer: what agents are running right now, and what can they actually do?
