MCP Gateway Architecture as the Control Plane for Fine-Grained Agent Tool Permissions

An MCP gateway with OAuth 2.1 support and tool-level RBAC solves a specific problem: raw Model Context Protocol adoption gives agents a standard way to discover and call tools, but no mechanism for deciding who should be allowed to call which tool, under what conditions. The gateway is the architectural layer that enforces that decision, sitting between every agent and every MCP server, filtering what agents can see, authenticating every call, and logging the result back to a named human. This matters because if you enforce permissions inside agents or inside individual MCP servers instead, it doesn't scale and it doesn't hold up under audit. The rest of this piece explains the mechanics: the four roles a gateway has to perform, why identity has to propagate through every call, which threats gateway-layer enforcement is built to catch, and what to check before picking an implementation.

Raw MCP adoption creates an unmanageable governance problem at scale

MCP's core exchange is simple by design. An agent sends tools/list, the server responds with a structured manifest of available tools, and the agent invokes one with call_tool. That uniformity is the protocol's real contribution: it removes the need for custom glue code between every model and every tool it might touch. But standardizing discovery and invocation is not the same as governing access. MCP specifies how an agent talks to a tool. It says nothing about whether that agent should be allowed to.

The gap appears in the arithmetic. If nothing centralizes the connection, you end up with fifty separate integration paths once five agents each need access to ten enterprise tools. Nobody has a single place to check which agent can reach which system, because no such place exists.

This is not a hypothetical shortfall. The MCP 2026 roadmap itself names audit trails, enterprise-managed auth, and gateway and proxy patterns as gaps the protocol does not close, so the gateway layer is required infrastructure, not an optional hardening step. The N-agents-by-M-tools scaling pattern is already enterprise-wide, and raw MCP adoption leaves it ungoverned.

What an MCP gateway is

The most common mistake is treating an MCP gateway as a routing proxy with a fancier name. A proxy forwards traffic. A gateway inspects it, applies policy, and can refuse to forward it. That distinction is the whole job: an MCP gateway is a control plane layered above execution, deciding who is allowed to speak, to which tools, and under what conditions, before any call reaches a server.

It is not the same thing as an MCP server, either. A server exposes tools. A gateway governs access to those servers, which is a separate function performed by a separate piece of infrastructure. It is not an API gateway either, even though the terminology invites the comparison. An API gateway governs traffic between services at the level of HTTP endpoints. An MCP gateway governs tool-call traffic between agents and MCP servers, where the unit of control is a tool invocation, not a route. That difference matters: the unit of control shifts from endpoints to specific tool calls, requiring infrastructure purpose-built for AI agent governance.

Nor is it an LLM or model gateway. An LLM gateway tracks tokens and models; an MCP gateway tracks tool calls. Each sees only its own boundary, and neither substitutes for the other. What an MCP gateway does, concretely, is sit directly in the request path. Agents connect to the gateway instead of connecting straight to GitHub, a production database, or an internal API, making the gateway the single intermediary through which all tool traffic has to pass.

The four minimum architectural roles a gateway must perform

A system only counts as a control plane if it performs four roles together: discovery control, authenticated routing, pre-call policy enforcement, and audit logging. Dropping any one of them reopens the gap somewhere else in the stack.

Discovery control filters the tools/list response, so each agent or user sees only the tools it can invoke. This is where tool-level visibility policy actually lives: a tool that appears in an agent's manifest is a tool the agent will eventually attempt to use, so controlling what's visible is the first layer of enforcement, not an afterthought. Tool Groups, which curate subsets of tools per team or workflow, are one concrete way gateways implement this.

Credentials sitting inline in config files are how breaches start, and isolating secrets from end users and configuration is precisely what this role exists to prevent.

Pre-call policy enforcement inspects tool call arguments, applies rate limits and quotas, and blocks disallowed operations before a request ever reaches the server. This has to sit outside the model, because policy expressed as prompt text is not a control; it is a request the model can be argued out of. Enforcement here can operate at three tiers: server-level, tool-level, and parameter-level, and each tier closes a different class of over-privilege.

Fine-grained, role-aware permissions must live at the gateway layer, not inside agents or servers

Pushing permission logic down into individual agents or individual MCP servers reproduces the N-by-M scaling pattern one layer deeper, as policy sprawl this time. The gateway layer is the only place this class of enforcement can actually work.

Inside the agent, permissions get expressed through prompts, and any rule written in prompt text can be overridden by a sufficiently persuasive input. That's an implementation detail, and it reflects the nature of how these models process instructions. A single agent also commonly runs under one service identity while it acts on behalf of many different humans across a day, so per-agent policy can't represent that multiplicity even if the prompt-injection risk weren't there.

Inside the MCP server, the picture is worse in a different way. Server-side auth, where it exists at all, amounts to per-server consent prompts, which is exactly the pattern the MCP Enterprise-Managed Authorization extension was promoted to stable status to replace, swapping scattered consent prompts for a centralized, identity-provider-backed flow.

The gateway works because it sits in the request path for every agent-to-tool interaction regardless of agent SDK or runtime. It can correlate the human identity propagated from an SSO session through to the tool call itself, connecting role-based policy to real people. And it enforces that policy uniformly without requiring any modification to agents or servers: an MCP firewall running at the gateway layer can intercept any MCP-compliant agent's tool calls without depending on a specific SDK. Other specialized gateways, the LLM gateway, the data gateway, each see only their own boundary, which leaves the gateway layer as the one place where cross-cutting identity and policy can actually be applied.

The obvious objection is that enterprises already have IAM, so why build another layer. Traditional IAM assumes a principal on one side of a policy boundary and a resource on the other. IAM built for human users logging into applications doesn't map onto that shape, so you need the gateway layer as a distinct architectural requirement, not a redundant one.

How identity propagation connects human users to tool-level permissions

Fine-grained permissions only work if the gateway can resolve every single tool call back to a specific human identity. That resolution depends on an identity propagation chain running from SSO authentication, through the agent session, to the gateway, on every call, without gaps. Skipping a link in that chain degrades the audit log back into "the agent used the service account," which answers nothing when an incident response team needs to know who actually authorized an action.

The practical path for most organizations is integrating the gateway with identity providers they already run, rather than standing up a parallel identity system just for agents. Microsoft Entra Agent ID reached general availability in April 2026 and extends existing Entra machinery, Conditional Access, an Identity Protection concept for "risky agents" that flags anomalous behavior, and access reviews, to agents as a new category of non-human principal. Okta for AI Agents reached general availability on April 30, 2026, with a different but complementary set of capabilities: it detects unsanctioned agents through OAuth consent-grant analysis, registers agents as first-class identities in the Universal Directory with a named human owner, and, following the addition of Third-Party IdP Support announced at Oktane 2026, works alongside non-Okta identity providers for human users.

Both products are pointed at the same underlying problem: shadow AI, meaning agents running in production that were never registered anywhere and that nobody can govern because nobody knows they exist. Detecting unsanctioned agents through OAuth consent-grant analysis is the agent-era equivalent of discovering shadow IT, and it only matters because the gateway is the enforcement point downstream of it. Once an identity token is validated, the resulting permissions determine which tools show up in an agent's manifest and which tool calls get allowed through. Identity without a gateway enforcement point is a policy with no lock attached to it.

The security threats that gateway-layer enforcement must intercept in real time

The tool-call surface that MCP opens up is an active target, not a theoretical one, and the gateway is the layer positioned to catch these attacks before they land.

Prompt injection hides adversarial instructions inside content an agent reads during normal operation: code review comments, web pages, documents. The goal is hijacking a tool call the agent would never have made on its own initiative. This risk has moved well past the hypothetical stage, with concrete CVEs now on record for exploited prompt injection against agentic systems. Pre-call enforcement is what gives the gateway its position to stop it: it inspects tool call arguments for anomalous or injected instructions before execution, a function that belongs at the gateway, the layer generating the call.

A gateway enforcing least-privilege access can block a tool call that would expose a sensitive field before that call ever executes, rather than discovering the exposure after the fact in a log review.

Shadow AI closes the loop on both of the above. If employees connect personal AI subscriptions through corporate credentials, or quietly wire an agent into a SaaS app without telling IT, they create tool-call paths that are both invisible and unaudited. Every other threat gets worse once it has a path like that to hide in. Real-time detection at the gateway, rather than after-the-fact log review, is the response that matches the speed of the problem.

The MCP gateway in the broader AI control plane

An MCP gateway closes the tool-call governance gap. It does not, on its own, govern model traffic, human approval workflows, or observability across every system an agent might touch. A complete control plane needs five primitives working together, with the MCP gateway responsible for exactly one of them: the tool-call boundary.

Each specialized gateway only sees its own slice. When every gateway only sees its own boundary, nobody sees the whole workflow, which is the structural reason a horizontal control plane layer has to exist above the individual gateways rather than being assembled from them after the fact.

Speakeasy's AI control plane is built around that gap directly. For organizations evaluating whether to assemble several point products or adopt one integrated layer, that's the category Speakeasy sits in.

Evaluating an MCP gateway with tool-level RBAC

The evaluation criteria for an MCP gateway fall out directly from the four roles already described.

Access control depth is the first thing to check: does enforcement happen at the server level, the tool level, or the parameter level. Does the gateway connect to Okta, Entra ID, SAML, or OIDC infrastructure an organization already runs, or does it demand a parallel identity system be built from scratch? Protocol fidelity and agent compatibility decide whether the gateway will actually work with the runtimes already in production, Claude Code, Cursor, Codex CLI, and others, and whether it tracks the MCP specification version those runtimes expect. Deployment model separates vendors fast for regulated industries: some gateways run inside an organization's own cloud environment with VPC isolation, on-prem, or air-gapped, while others are SaaS-only. Finally, whether a given gateway is a point product or a control plane shapes the whole buying decision: a tool that covers only one or two of the five primitives has to be composed with other tools, and teams need to decide up front whether they're assembling a best-of-breed stack or buying one integrated platform.

Several named implementations illustrate how these criteria play out differently in practice. Bifrost, from Maxim AI, is an open-source, high-performance Go binary that unifies LLM, MCP, and agent traffic governance in a single component, supports air-gapped and VPC deployments, and governs access through virtual keys with hierarchical budgets and per-key MCP tool allow-lists. MCPX is open-source under MIT license and purpose-built for multi-team, shared-infrastructure environments, using Tool Groups for discovery control and, at the enterprise tier, adding tool-level RBAC and immutable audit trails across the full User-to-Agent-to-MCP-to-Tool chain; it's recognized by Gartner as a Representative Vendor in the MCP Gateways category and carries SOC 2 certification at the Enterprise tier. Kong AI Gateway with MCP is a paid extension available in Kong Gateway Enterprise and Kong Konnect, building MCP-specific authentication and policy enforcement on top of Kong's existing API gateway plugin architecture, a natural choice for teams already standardized on Kong. IBM ContextForge is open-source and protocol-flexible, developed and released by IBM but not tied to any proprietary IBM software stack, though observability, governance UI, and production tooling generally require additional integration work. Docker MCP Gateway runs each MCP server in its own container with cryptographically signed images and basic secrets management through Docker Desktop, so it works well for local development and container-level isolation, but since it lacks organization-wide RBAC or compliance-grade audit logging, teams typically migrate to a fuller control plane before going to production. And Speakeasy covers the full five-primitive architecture, tool governance, RBAC through existing identity providers, real-time detection of shadow AI and prompt injection, and cost and usage telemetry, aimed at enterprises that want the MCP gateway function delivered as part of one integrated, governed layer rather than stitched together from separate point products.