RBAC vs ABAC vs PBAC for MCP Access Control

MCP's spec leaves authorization to whoever implements it. No protocol-level guardrails, no default model, no built-in enforcement layer. That single design decision means every organization running an MCP server is, whether it realizes it or not, building its own access control system from the ground up.

Anthropic released MCP as an open standard in late 2024. It connects AI assistants to content repositories, business tools, and development environments through a client-server setup, built for connectivity between systems, not for governing who gets to do what inside them. The Coalition for Secure AI catalogs this gap formally, as MCP-T2, Missing or Improper Access Control, covering both the absence of authorization mechanisms and the failure to enforce permissions at the object level.

It's a standing implementation responsibility that adoption has already outrun: MCP went from a late-2024 launch to a fast-growing base of enterprise production deployments within about a year and a half, per bex.co's enterprise readiness audit, a pace well ahead of any governance framework maturing alongside it. So enterprises now pick between RBAC, ABAC, and PBAC, or just default to whatever their existing identity stack makes easiest, against a protocol that was never built to point them toward an answer. The sections that follow work through what each model actually does when an AI agent, not a person, is the one asking for access.

How MCP's authorization problem differs from conventional access control

A normal application has a clean answer to "who's asking?" A user logs in, a request comes in, the caller's identity is obvious. MCP breaks that chain. A single user request might pass through an orchestrating agent, hop across one or more intermediate MCP servers, and land on a downstream tool or API, and each one of those hops is a place where the system could be tricked into acting for someone it shouldn't.

That changes the question MCP deployments need to ask: instead of who's making a request, it's who authorized the action, through what chain of hops, and with what scope, a framing the Coalition for Secure AI laid out in its recap of RSAC 2026. Without that tracing, an MCP server has no way to verify where a request actually came from, opening the door to impersonation, replay attacks, and what security researchers call confused deputy attacks, where a system with legitimate authority acts on someone else's behalf without meaning to.

A tenant isolation flaw at Asana in June 2025, where data leaked across organizations, traced back to exactly this failure mode: an intermediary holding tokens without validating authorization on each individual request. A WordPress plugin CVE from around the same window showed privilege escalation through improper authorization in an MCP implementation, not some novel exploit, just the expected outcome of shipping without adequate controls.

The stakes compound because of how MCP servers are built. SentinelOne notes that MCP servers aggregate credentials for multiple enterprise services in one place, so a single breached server running without authentication controls can expose every database, file system, and cloud service the assistant touches. Long-lived tokens make it worse. Steal a token in a conventional app and the damage has a ceiling. Steal one in a multi-agent system where that token can travel across servers and authorize a whole chain of actions, and the Coalition for Secure AI finds the exposure grows geometrically. The OASIS Agentic IAM paper, approved by the CoSAI Project Governing Board in January 2026, treats this as reason enough to give agents their own identity category entirely, distinct from human users and from traditional service accounts, each one bound to verifiable claims about its code, its model, and the environment it runs in.

RBAC's limits for MCP workloads

RBAC runs on one assumption: that a role is stable enough to write down and assign. That assumption holds for people. A person's job changes on an HR event somebody can hook a workflow to. An agent's access needs shift the moment someone edits a prompt or registers a new tool, and there's no ticket, no onboarding form, no event for a permission system to catch.

None of that makes RBAC a bad model. It assigns permissions based on predefined roles, grouping people by job function, and it earns its popularity honestly: simple to set up, scales cleanly, and auditors already understand how it works. It's the right tool when the org chart holds still, responsibilities are drawn clearly, and context doesn't change the answer much. Permission checks under RBAC are deterministic and cheap, easy to cache, a real advantage anywhere a system needs to make access decisions fast and at volume.

In the MCP context, Trust3 AI identifies three structural failures that are not configuration problems. RBAC can't tell which hop in a delegation chain is actually making a request, so it collapses distinct identities into one undifferentiated caller. It grants permission at the session level instead of per action, so a single tool invocation inherits the entire permission set tied to a role instead of just what that action needs. And it creates a blast radius problem: compromise one agent, and every permission attached to its role goes with it.

Role explosion, RBAC's classic failure mode, gets worse once agents enter the picture. Roles start needing to encode conditions like time, location, resource type, or agent capability instead of stable job functions, and they multiply into things like Agent_Finance_ReadOnly_EU, as both nhimg.org and Frontegg describe. RBAC doesn't fail with an alarm going off. It fails quietly, through role sprawl and logic nobody trusts anymore, as Sehban Alam has described it.

RBAC still earns its place in an MCP stack under the right conditions: stable, repeatable access patterns, narrow agent capability, low resource sensitivity. Outside that zone, authorization needs to adjust per action, per stated purpose, and per context, which is what RBAC was never built to do.

What ABAC adds and costs

ABAC picks up where RBAC leaves off by evaluating attributes of the subject, the action, and the resource at the moment of the request, instead of relying on a role assigned ahead of time. That solves the problem of evaluating context at request time, but it trades role explosion for a different failure mode: policy logic scattered everywhere, ungoverned, unless someone deliberately centralizes it.

Under ABAC, there's no static permission table to look up. A policy engine evaluates each request live, against rules built from attributes of the subject, the action, the resource, and the environment, as Axiomatics describes it. That runtime evaluation suits MCP well: nhimg.org notes that for non-human identities, ABAC is usually better when workloads are ephemeral or shared across teams, as most MCP agent deployments are. Frontegg and Security Boulevard note it can factor in device posture, location, subscription tier, risk signals, and ownership, the kinds of signals that separate a legitimate agent call from one that looks off.

Axiomatics ran a demonstration in June 2026 using a fictional company it called Meridian Corp, showing ABAC enforcement over an MCP-connected finance agent, and it's a useful window into how this actually plays out at the tool level. A procurement manager, given the name Alice in the scenario, asked the agent in a single prompt to create a purchase order and then approve it. The agent created the PO without issue, then got blocked the instant it tried to approve its own creation, a separation-of-duties rule enforced right at the tool-invocation layer, not buried somewhere in the agent's prompt instructions. When Alice then asked it to approve every pending order company-wide, the system denied Marketing's POs for being outside her department, denied an Engineering PO over $25,000 for exceeding her approval limit, and cleared the rest. Three externalized policies did all of that work, in place of what would otherwise have turned into a mess of application-level checks, duplicated roles, or logic buried inside the agent's own system prompt.

None of that comes free. ABAC policy management gets complicated fast, and evaluating a long list of attributes on every single request can slow a system down at scale, Frontegg notes. The deeper cost is governance: ABAC logic scattered across services becomes difficult to reason about at scale, a policy may change in one place and still exist elsewhere in an outdated version, and no single team has a complete picture of what the system will allow, as Security Boulevard notes. The attribute evaluation itself works fine. It's that there's no governed home for the logic to live in, which is exactly the space PBAC is built to occupy.

What PBAC adds: externalized, versioned, auditable authorization logic

PBAC pulls authorization logic out of application code entirely and turns it into something managed on its own: authored, reviewed, versioned, audited, independent of whatever service happens to be calling it. Sehban Alam frames the underlying case for it bluntly: once a single policy change requires touching multiple services, and no one team can list every place that policy logic lives, governance has already failed.

Treating policies as first-class artifacts means changes go through the same discipline infrastructure-as-code gets: review, version history, an audit trail, rather than sitting buried in middleware or hardcoded into an agent's prompt. Trust3 AI points to a variant gaining traction specifically for MCP: purpose-based access control, where the agent's declared reason for requesting access right now becomes a direct input into the authorization decision, not just a side note. Roles describe who someone is in the org chart. They say nothing about what an agent should be allowed to touch at this specific moment for this specific declared reason, and that's the gap purpose-based PBAC closes.

Frontegg describes PBAC policies as capable of folding in both static role structure and dynamic attribute evaluation, essentially absorbing what RBAC and ABAC each do well into one policy-driven model. That matters directly for controlling delegation across MCP's chain of hops. The OASIS Agentic IAM paper, from January 2026, calls for scope to narrow at every delegation hop, never expand past what the delegating principal originally granted, and a PBAC setup enforces that cleanly because each hop's policy is versioned and can be audited on its own. CoSAI's guidance that delegation tokens should carry explicit actor and subject claims lines up with the same requirement: the authorization chain has to be visible and checkable at every step, not just at the start.

That governance layer already exists in working form. Permit.io runs as an authorization platform for fine-grained, policy-based control across APIs, data layers, and AI agents, built on OPA and OPAL, supporting Rego and Cedar-style policy languages, with the decision point running inside the customer's own environment and marketed as MCP-aware as of its 2026 listing. Separately, MCP Manager, now part of Usercentrics and built by a team with deep AI infrastructure experience, functions as a control layer for enterprise MCP deployments, handling the gateway, guardrails, and access controls that enforce authorization policy across MCP servers and giving organizations the observability PBAC depends on. Neither is the only way to build this. Both point to the same conclusion: for MCP workloads, where agents cross multiple servers and every hop is a fresh authorization boundary, the practical question isn't which named model wins on paper, it's whether the authorization logic gets externalized at all, and for MCP the answer is yes.

Matching each model to MCP workload risk

Two variables decide which model fits: how much an agent can actually do, and how sensitive the resource is that it's trying to touch. The OASIS Agentic IAM paper turns that into a formal capability-risk matrix, mapping the strength of control required to where those two variables intersect.

Low capability against a low-sensitivity resource, an agent pulling answers from a public FAQ, for instance, needs nothing more elaborate than a narrowly scoped service account under RBAC. The blast radius is small and the role is stable enough to define cleanly. High capability against a high-sensitivity resource, such as an agent processing invoices and triggering payments, requires the full apparatus, per the Coalition for Secure AI: ephemeral identities, on-behalf-of delegation, token exchange per RFC 8693, ABAC/PBAC policies, continuous evaluation, and a human in the loop before anything irreversible happens.

nhimg.org's heuristic gives a workable shortcut: RBAC for access patterns that stay stable and repeat, ABAC once access has to shift with context or resource type or environment, and externalized PBAC once the authorization logic itself needs governance, auditing, and safe change management across more than one service.

Some conditions push the answer toward PBAC regardless of where an agent lands on the capability-risk matrix. If more than one team is standing up MCP servers independently, fragmented policy authorship is already a governance failure in progress, not a risk waiting to happen. Regulatory obligations that require authorization decisions to be auditable and explainable point the same direction. Capability and sensitivity set the floor for how strong the controls need to be. Organizational sprawl and audit requirements decide whether that logic needs a single governed home, and for most enterprises running MCP at any real scale, it does.