Governing MCP Tool Permissions With RBAC

That kind of growth curve doesn't leave much room for the governance layer to catch up, and it hasn't. Agents multiply faster than the policies meant to govern them, which is a fairly normal outcome whenever a useful protocol spreads before anyone finishes the paperwork.

This isn't a gap discovered by outside critics. MCP's own 2026 roadmap names its shortcomings directly, calling out missing audit trails, the absence of enterprise-managed auth, and the lack of settled gateway and proxy patterns. The specification even tells you who's supposed to fix it. It states that "there SHOULD always be a human in the loop with the ability to deny tool invocations," which is a polite way of saying enforcement is somebody else's job. The protocol describes the door. It does not install the lock.

So picture the resulting shape of a typical enterprise deployment: dozens of agents, hundreds of connected servers, and in a lot of cases a single credential sitting behind the whole arrangement, granting access to everything the fleet can reach. That's a real risk in enterprise deployment, not a hypothetical scenario dreamed up for a slide deck. It's the default architecture when nobody has gone in and drawn boundaries yet, and boundary-drawing was never MCP's job to begin with. Enterprise MCP adoption has crossed 78% in production AI teams, and the public MCP registry has surpassed 9,400 servers, marking the protocol's shift from emerging standard to enterprise default in under two years AI Governance Tools With RBAC for Enterprise Teams (2026).

Server-level permissions failing when a single server exposes both safe and dangerous tools

Most early MCP rollouts scope access at the server level: one credential, one blanket grant, every tool on that server included, harmless or catastrophic. Servers don't only ever expose one kind of tool, so scoping access at the server level fails to hold up. A CRM server routinely bundles lookup_customer next to delete_customer, and there is no version of "server-level access" that lets you grant one without the other. The same pattern appears in database servers pairing query next to drop_table, and in filesystem servers pairing read next to delete. Different risk profiles, same key.

That forces a choice nobody actually wants to make. Either grant blanket access and hope nothing goes sideways, or refuse and watch teams route around the restriction by standing up parallel MCP servers for every permission tier they need, which is operational paralysis dressed up as caution. Neither option is really a solution. One just fails faster than the other.

OWASP's Top 10 for LLM Applications, updated in August 2026, ranks Excessive Agency as LLM03 and traces it to three root causes: excessive functionality, excessive permissions, and excessive autonomy. Reading that list against the CRM example makes the diagnosis write itself. Three failure modes recur wherever tool-level control is missing. A prompt injection buried in an ordinary document coerces a model into calling a tool it technically has access to, because some other workflow needed that access and nobody scoped it back down. Customer-facing agents end up with a path to internal-only tools, because one MCP fleet quietly serves both audiences off the same server-level grant. And a single leaked API key hands over the entire tool surface, not just the sliver an attacker actually wanted, because the credential was never scoped narrower than "everything". None of these are exotic. They're what happens by default when the infrastructure to express narrower scope doesn't exist yet, and building that infrastructure is exactly the gap a gateway is meant to close.

Tool-level RBAC: subject, action, and resource scoping per agent identity

Tool-level RBAC ties each agent or consumer to a specific, named list of tools, not to a server, a session, or a static key floating around in an environment file. That's the entire conceptual shift, and it sounds small until you consider that most deployments have never done it.

A workable model expresses scope along three dimensions. Subject scoping means each credential maps to a specific consumer, an agent, a team, a customer integration, rather than some undifferentiated service identity that everyone shares because setting up separate ones felt like extra work. Action scoping means permissions attach to individual tools, so filesystem_read and filesystem_write, even coming off the same server, become independently grantable rather than a package deal. Resource scoping groups the right tools together for a given role, environment, or tenant, so a support team's agent and a finance team's agent draw from genuinely different pools rather than the same firehose with a filter bolted on after the fact.

Enforcement then has to happen twice, not once. At tool-discovery time, the model should never even see a forbidden tool sitting in its context window, since a tool it can't see is a tool it can't be tricked into calling. At tool-execution time, any attempt to call something outside the granted scope gets a flat denial, regardless of how convincing the prompt injection was or how creatively a misbehaving client tried to route around it. Belt and suspenders, except the belt is doing actual load-bearing work.

OAuth 2.1 does not solve this by itself. It handles authentication and broad grants, the "this client may talk to this MCP server" layer, but the MCP authorization specification never standardized scope conventions for individual tools, leaving that gap for RBAC to fill with explicit per-tool decisions. RBAC sets the baseline by role, while ABAC evaluates attributes such as team, model, or specific tool at the moment of the request, and production gateways in practice run both together, role as the floor and attributes narrowing it from there. Deny-by-default is the design principle that produces this: an identity with no configured tool list should reach exactly zero tools, not the full catalog by accident.

Authorization cannot live inside the agent or the MCP server: the gateway as the natural enforcement point

Every tool call an agent makes already has to travel through some routing layer to reach its destination. The gateway, not the agent and not the individual MCP server, is where enforcement belongs. No per-server code changes, no per-agent instrumentation bolted on after the fact. One choke point, one policy engine, and every call passes through it before it reaches anything downstream. Splitting enforcement across multiple layers builds gaps by design, because governance only holds when every call crosses the same checkpoint.

A gateway layer covers ground that raw RBAC alone doesn't touch. Centralized authentication folds in OAuth 2.1, OIDC, SSO, and per-user identity propagation so the system knows not just which agent is calling but which human stands behind it. Traffic routing aggregates calls across multiple downstream MCP servers, and threat protection covers tool poisoning, rug-pulls, and shadow MCP usage.

Gartner's guidance on emerging practices recommends treating MCP with the same gateway-centric architecture organizations already apply to any other API surface, which is really just an argument that MCP isn't as novel a problem as it looks. The same ungoverned pattern that defined shadow IT for a decade now defines shadow AI, and a gateway with no reach into desktop AI apps that were never pointed at it in the first place can't see them any better than a firewall sees a personal hotspot. IBM's Cost of a Data Breach Report found that 97% of organizations reporting an AI-related security incident lacked proper AI access controls, which turns "the enforcement gap matters" from an argument into a measured outcome AI Governance Tools With RBAC for Enterprise Teams (2026). Governance built on data permissions from the start beats governance bolted onto an agent that already had the run of the place.

The agent identity problem that RBAC alone cannot solve

RBAC needs something stable to bind permissions to. A verifiable identity is required, or the whole role-assignment exercise turns into paperwork nobody can enforce. Agents are everywhere, but the identity layer beneath them is still being built, and that gap is what drives the quiet problem with tool-level access control.

AI agents are in use at 91% of organizations today, yet only 10% have anything resembling a formal strategy for managing non-human identities: that is what Okta's 2026 AI Agents at Work report found. Only 34% of organizations apply the same security controls to agents that they apply to human employees. The identity gap predates the tool-permission gap and probably explains a good chunk of it. You can't scope access precisely for an identity you haven't decided how to treat.

Multi-agent chains make it worse. A May 2026 paper by Krti Tallam of Kamiwaza AI, "Authorization Propagation in Multi-Agent AI Systems," formalizes the problem of authorization moving correctly across a chain of agents as a workflow-level property, one that RBAC, ABAC, and relationship-based access control don't resolve on their own. The proposed fix is a dual-identity model: every request carries both the agent's identity and the identity of the human acting through it, and the effective tool list becomes the intersection of the two scopes rather than whichever grant is more generous. An agent with broad permissions acting for a narrowly-permissioned user should inherit the narrower list. Anything else defeats the point of having a user in the loop.

Identity providers are catching up unevenly. Microsoft Entra Agent ID reached general availability in May 2026 and extends Conditional Access and Identity Protection to non-human identities, explicitly blocking a set of high-risk Graph permissions, though agents still can't sign in through OIDC or SAML the way a human user would. Okta formalized its agent identity stack at Oktane 2026, pairing an Agent Gateway released in research form with Agent SSO now bundled into the core platform, and its XAA protocol reaches native integrations across more than 25 major cloud, developer, and enterprise SaaS platforms; Okta is also now a featured identity provider for Claude Enterprise AI Governance Tools With RBAC for Enterprise Teams (2026). Google Cloud IAM and Ping Identity each ship distinct agent identity types. Keycloak offers delegation and credential primitives but stops short of a first-class agent object, while Auth0 has moved further, treating agents as first-class identities since its Auth0 for AI Agents feature went generally available in late 2025⟦c33⟢. Google Workspace now supports agent identities through Workspace Studio and the Gemini Enterprise Agent Platform, though the older mechanism, service accounts with domain-wide delegation, remains available and hasn't gone anywhere.

The mechanism gaining the most traction for connecting these pieces is token exchange. An agent takes the token issued by its identity provider and exchanges it, under RFC 8693, for a short-lived assertion scoped to one specific downstream resource, an approach profiled as the Identity Assertion JWT Authorization Grant, or ID-JAG. That draft reached revision 04 on May 21, 2026, and remains an active Internet-Draft on the IETF's standards track rather than a ratified RFC, so treat it as a strong signal of direction rather than a settled standard. On the MCP side specifically, the Client ID Metadata Document was adopted into the specification in November 2025, and the 2026-07-28 release deprecates dynamic client registration while keeping it around for compatibility. CIMD replaces DCR with a URL hosted on the client vendor's own domain, one the authorization server fetches and verifies, which turns client identity into a domain name a policy can actually reference rather than an opaque registered string.

Binding IdP groups to tool allow-lists: the mechanics of SSO and SCIM integration in a gateway

In a properly built enterprise gateway, SSO connects the gateway itself to the corporate identity provider over OIDC or SAML 2.0. Instead of handing out raw provider API keys, the gateway authenticates users against the corporate directory and issues virtual keys mapped to their verified group roles and budget allocations. That single design choice, virtual keys instead of raw keys, is what makes everything downstream governable.

SCIM-driven RBAC lets directory groups drive tool access directly: move a user to a new team in the directory, and their tool access updates on its own, no manual re-provisioning ticket required. The virtual key is the actual unit of governance here. It carries a scoped set of MCP client configurations, each one specifying exactly which tools that key can call from that particular client, and a key with no MCP configuration attached exposes no MCP tools at all by default. Request headers can narrow what a key is allowed to touch on a given call, but they can never widen it past the key's underlying grant, an additive-restriction model rather than an additive-grant one.

Execution approval deserves its own line item, because not every permitted tool should be allowed to fire automatically. Side-effecting calls, writes, deletes, message sends, need either a human in the loop or an explicit auto-execute allowlist scoped per client. And even a tool that's fully permitted and approved for auto-execution can still leak secrets, PII, or an unreasonably large payload through its arguments or its return value. Policy needs to read content, not just tool names. A gateway that only checks whether a call is allowed, without looking at what's actually inside the call, is checking half the problem. Joiner-mover-leaver changes in the directory need to propagate automatically to tool access too, since manual re-provisioning in a fast-moving engineering org is less a process than a compliance liability waiting for an audit to find it.

Tool-level RBAC implementation in leading MCP gateway platforms

A few questions separate a gateway that talks about RBAC from one that enforces it. Does it grant access per tool, or only per server? Is an unconfigured identity denied by default? Can some tools auto-run while others sit behind an approval queue? Does upstream authorization support per-server credentials and per-user OAuth, not just a shared key? Can the gateway inspect what's inside a call, not just its name? And is every call logged with the user, team, key, and cost attached to it?

Bifrost, the open-source AI gateway from Maxim AI written in Go, acts as both an MCP client and an MCP server simultaneously, which routes every tool call through a single policy engine rather than splitting enforcement across layers. Virtual keys are its governance primitive, with per-tool allow-lists enforced at both discovery and execution time, and its deny-by-default posture means a key with no MCP configuration reaches nothing. Its Agent Mode runs only the tools explicitly listed under tools_to_auto_execute, returning everything else for approval instead of guessing. The enterprise tier layers in guardrail rules that inspect tool arguments and results, SSO, RBAC spanning 16 resource types, and signed audit logs, with IdP integration across Okta, Entra, Keycloak, Zitadel, Google Workspace, and Auth0 via OIDC and SCIM 2.0.

Kong AI Gateway took a different route, making MCP a first-class traffic type starting in Gateway 3.12, then splitting things further in the 3.14 release into three distinct modes, LLM Gateway, MCP Gateway, and Agent Gateway, all still governed through the same Konnect control plane. The advantage here is inheritance: authentication, rate limiting, and observability policies that already govern REST traffic extend to agent traffic without a separate policy language to learn. Per-tool allow and deny lists apply by consumer or group through Kong's plugin architecture, alongside token-based rate limiting, semantic caching, and per-team cost visibility, though argument and result inspection along with execution approval aren't documented features as of current published material.

Different platforms are solving overlapping pieces of the same problem, server-mode splitting, argument inspection, IdP breadth, execution approval, and none of them cover every axis equally. That's less a knock on any one of them and more a sign of how young this category still is. The gateway layer for MCP is being built in public, in real time, by vendors racing to cover a gap the protocol itself admitted it wasn't going to close. Upstream authorization encompasses per-server credentials, per-user OAuth, and identity token exchange. The approach adds 11 microseconds of overhead per request at 5,000 RPS, with TrueFoundry benchmarks showing roughly 3–4ms response time at 350+ RPS per core for TrueFoundry AI Gateway, while Bifrost adds 11µs overhead at 5,000 RPS 10 Best MCP Gateways In 2026. Virtual MCPs bundle approved connectors and curated tool surfaces behind one governed endpoint for specific teams, roles, use cases, or agents. SCIM-driven RBAC enables directory groups to drive tool access with consistent policies. OAuth brokering adds enterprise authentication to local and hosted MCP servers. Hosted connectors run in MintMCP's data plane with auto-scaling and sandboxed execution. Mint Guard adds managed detection for prompt injection, secrets, PII, and harmful content, while runtime guardrails add declarative and customer-authored policy enforcement.