Complete Mediation Principle in MCP Deployments

The Model Context Protocol is an open standard Anthropic released in late 2024, built to connect AI assistants to enterprise data sources, tools, and APIs through a client-server architecture. That description sounds familiar. The security implications are not.

In a conventional architecture, a user authenticates, an application makes a defined request, and the identity of the caller is unambiguous at every step. The call graph is static. You can enumerate it in advance, draw a boundary around it, and put a mediation mechanism at that boundary. The mechanism is hard to route around because the routes are known and finite.

MCP dissolves that assumption. A user's intent originates in a prompt, passes through an orchestrating agent, traverses one or more intermediate MCP servers, and finally reaches a downstream tool or API, with each hop acting on behalf of the original caller. The AI model decides at runtime which tool to invoke and with what parameters. The call graph cannot be enumerated in advance. It is different every time, shaped by the model's inference rather than a developer's code.

This is not a refinement of the old problem. It is a categorically different one. Conventional perimeter controls and identity systems were designed for a world where the caller is a human or a deterministic application. Neither assumption holds for an AI agent operating across multiple MCP servers at runtime.

The MCP specification states explicitly that the protocol "cannot enforce these security principles at the protocol level," placing the entire implementation burden on whoever builds on top of it. Saltzer and Schroeder's principle of complete mediation requires the mediation mechanism to be positioned so it cannot be subverted. MCP's design installs no such mechanism, by design. Every team building on MCP has to construct their own complete-mediation layer from scratch.

The authentication question MCP introduces is harder than anything that came before it. It is not just "who are you?" It is "who authorized this action, through what chain of delegation, with what scope, at this specific moment in this specific call graph?" That question has to be answered at every hop. The architecture either makes that answerable or it does not.

How Fast MCP Adoption Outran the Security Infrastructure Needed to Mediate It

By 2025, MCP had accumulated over 97 million monthly SDK downloads and more than 10,000 active public servers. First-class client support spans ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. The protocol achieved near-universal adoption across the AI tooling ecosystem in roughly a year.

The security infrastructure did not keep pace. Independent scans repeatedly find between 30 and 82 percent of public MCP servers carrying exploitable flaws. According to The State of MCP Server Security 2025, only 8.5 percent use OAuth, meaning the overwhelming majority operate with no standardized authentication mechanism, and only 18 percent of MCP server deployments implement any form of access scoping for tool permissions.

The adoption-to-maturity gap is legible in the deployment numbers. Roughly half of organizations are actively experimenting with MCP servers, but only 11 percent have reached production. Pre-production deployments have not been through formal security review. Authorization wrappers get added opportunistically rather than by design. The embedded assumption is that security is something you add before you ship, not something you architect from the start. That posture is precisely what incomplete mediation looks like in practice.

Cisco's State of AI Security 2026 found that 83 percent of organizations plan to deploy AI agents into core business functions, but only 29 percent feel their security posture is ready for it. That confidence gap mirrors the adoption-maturity gap almost exactly.

Incomplete mediation is the current default state of most MCP deployments. The gap between what is deployed and what is mediated is wide, and it is growing faster than the tooling available to close it.

The Confused Deputy Attack as the Canonical Violation of Complete Mediation in MCP

The confused deputy problem is one of the oldest in computer security. MCP's architecture gives it new surface area at every layer.

Here is how it manifests in MCP terms. A user authorizes Application A to access enterprise data through an MCP server. Without proper controls, a malicious Application B presents the same user credentials to the same MCP server and gets in. The MCP server becomes the confused deputy: it holds legitimate authorization but applies it incorrectly, treating user authentication as implicit authorization for any client that presents valid credentials. The check that should have happened did not.

In a single-hop system, there is one trust relationship to verify. In an agentic chain where a user delegates to an orchestrator, which calls MCP server A, which calls MCP server B, which reaches a downstream API, each hop is a potential confused deputy. Complete mediation requires every hop to independently verify both identity and authorization. Skip any single hop and the principle has failed, regardless of what every other hop did correctly.

Two incidents from May 2025, documented by security researchers, illustrate what this failure looks like at production scale. In the first, documented by Invariant Labs, a GitHub MCP agent held a single token spanning both public and private repositories. A malicious public issue steered the agent into reading private-repository data. One over-scoped, reused credential crossing a trust boundary. In the second, an Asana tenant isolation flaw enabled cross-organization data contamination affecting up to 1,000 enterprises, the same class of confused deputy failure operating at a different layer and considerably greater scale.

Neither incident required a novel exploit. Both required only that a legitimate credential be presented to a system that failed to verify whether the requesting party was authorized to use it for that specific purpose. The mediation check was either absent or performed once, at the wrong time. That was sufficient.

Token Passthrough: The Implementation Anti-Pattern That Structurally Breaks Mediation

Token passthrough is the practice of forwarding a caller's inbound token, unmodified, to a downstream MCP server or API. It is common. It is expedient. And it is a complete mediation failure by definition.

The problem is precise. The downstream service receives a token that was not issued for it as the intended audience. Security controls that depend on token audience, including rate limiting, request validation, and traffic monitoring, are bypassed entirely. The downstream service treats the token as implicitly validated by the upstream MCP server, when no such validation occurred.

The MCP authorization specification forbids token passthrough with a MUST NOT, requiring that MCP servers validate that each access token was issued for them as the intended audience and reject anything that fails that check. The June 2025 spec revision made the prohibition explicit. The July 2026 revision went further, removing protocol sessions from the transport layer entirely and closing a class of session-hijacking vulnerabilities that arose from sticky sessions and shared session stores.

The correct pattern is token exchange per RFC 8693. The gateway swaps the user's inbound token for a new, audience-bound token scoped specifically for the downstream MCP server. The user's identity is preserved in an actor claim through the on-behalf-of flow, maintaining the delegation chain without passing credentials beyond their intended scope. Each leg of the chain carries a token minted for that leg.

A supply-chain variant of this same mediation gap appeared in September 2025, when a widely installed email server MCP package pushed an update that silently BCC'd every agent-sent email to an attacker-controlled domain. The package passed standard review at installation time because it behaved legitimately until a later version changed its behavior. The check happened once, at install, and never again. Saltzer and Schroeder warned about exactly this trade-off: checking at authentication time and assuming authorization persists is not complete mediation. It is a vulnerability with a name.

What the Exposure Data Shows About Where Ungoverned Access Paths Concentrate in Real Deployments

The internet scan data gives something specific: a census of unmediated access paths. Servers that exist today, reachable, with tools invocable, and nothing intercepting the request.

Censys data from April 28, 2026 identified 12,520 internet-accessible MCP services across 8,758 unique IP addresses, spanning 56 countries and 425 autonomous systems. By May 6, 2026, that number had grown to over 21,000 servers. The surface area nearly doubled in roughly ten days.

A Trend Micro study from July 2025 found 492 MCP servers exposed to the public internet with zero authentication or encryption, providing access to 1,402 MCP tools. More than 90 percent of those servers allowed direct read access. Seventy-four percent were hosted on AWS, Azure, GCP, or Oracle, meaning cloud-hosted enterprise infrastructure was the primary exposure surface. A follow-up study found the number of exposed servers had nearly tripled to 1,467, and those servers had become active vectors for attacks against the cloud infrastructure hosting them.

CVE-2025-6514 earned a CVSS score of 9.6 and affected the widely used mcp-remote proxy package across hundreds of thousands of installed environments.

In January 2026, tens of thousands of OpenClaw instances were found exposed on the public internet, with more than 1,000 running unauthenticated MCP endpoints that leaked API keys, Slack credentials, and chat histories.

Every one of these exposures represents an access path that exists outside any mediation layer. The vulnerability existed the moment the server went ungoverned. This scan data is not a warning about future exposure; it is a record of decisions made at deployment time to leave access paths open.

What a Complete-Mediation Architecture for MCP Actually Requires

Non-bypassability determines architecture before it determines configuration. A mediation layer that can be routed around is not a mediation layer; it is a suggestion. Complete mediation requires that every MCP client request pass through a centralized gateway before reaching any MCP server, with direct server access architecturally impossible rather than merely discouraged.

That gateway has to perform several distinct verifications at every request, not at connection time, not at deployment time, at every request.

First, it must verify the identity of the requesting agent as a distinct principal, separate from the user who launched it. The agent is the caller; the user is the delegating principal. These carry different identities with different authorization scopes, and conflating them is precisely where confused deputy vulnerabilities originate.

Second, it must verify that the agent is authorized for the specific tool it is invoking, at the specific scope it is requesting, at the moment of the request. The June 2025 MCP spec revision added native support for defining scopes at the tool level via SEP-835, providing the protocol-level mechanism that makes per-tool, per-agent authorization expressible. Tool-level scopes are necessary but not sufficient. They must be enforced by the gateway. A scope declared by an MCP server and trusted without independent verification is not complete mediation.

Third, the gateway must enforce token audience validation and perform token exchange per RFC 8693, not token passthrough, before forwarding to any downstream service. The specification requires this. It is not a configuration choice.

A central registry follows directly from the non-bypassability requirement. Every MCP server in scope must have a corresponding identity in that registry. A server with no registry entry cannot be mediated, because the gateway has no record of what it is or what it is authorized to do. An unregistered server is, by definition, an ungoverned access path.

RBAC for agents must reflect deliberate organizational decisions about what each agent can do, not inherited permission sets from the user who invoked it. Agents should receive the minimum scope necessary for the assigned task, defined in advance, enforced at the gateway.

The July 2026 spec revision, which moved authorization state off the MCP server and onto the authorization server by removing session state from the transport layer, is architecturally correct for complete mediation. Authorization state that lives with the authorization server cannot be bypassed through session manipulation at the MCP server level.

Real-time observability is a structural requirement, not an operational nicety. An audit log read after an incident is a postmortem. Complete mediation requires that the gateway have visibility into what each agent is accessing at the time it is accessing it, so that anomalous access can be intercepted rather than merely recorded.

Mediation must also extend to the ongoing behavior of MCP packages after installation. A package can pass review at install time and change its behavior in a later update. Behavioral monitoring of what tools actually do in production is part of the mediation surface, not a separate concern.

Where MCP Manager Fits Into a Complete-Mediation Architecture

MCP Manager is built around the gateway model that complete mediation requires. Every request from every MCP client passes through it before reaching any MCP server. Direct server access does not exist as a route; the architecture forecloses it.

MCP Manager enforces the checks the complete-mediation principle demands at every request: agent identity verification as a distinct principal, per-tool authorization against a defined RBAC model, token audience validation, and token exchange per RFC 8693. These are not optional configurations. They are the execution model.

The central registry addresses the ungoverned-server problem directly. MCP Manager maintains a registry of every server in scope, and the gateway enforces that only registered servers are reachable. A server absent from the registry is unreachable through MCP Manager, which is another way of saying it cannot receive a mediated request.

The observability layer is real-time. What the exposure data makes clear is that ungoverned access paths are created at deployment time and remain open until something closes them. Real-time visibility into what each agent is touching, at the moment it is touching it, is what makes interception possible rather than just documentation of what already happened.

The supply-chain dimension is addressed through behavioral monitoring of what registered tools actually do in production, as opposed to what they were approved to do at registration. The check happens continuously, not once at install. That is the specific problem the September 2025 email server incident illustrated, and it requires a specific architectural response.

The scan data, the CVEs, the tenant isolation failures, and the supply-chain compromises documented throughout 2025 and 2026 share a common root: access paths that were never brought under mediation. MCP Manager is designed to address that specific problem, built to the standard the principle actually requires.