The Model Context Protocol started as a way for AI clients to discover and call tools. It is becoming something bigger: the identity plane your agents are operating on. The November 2025 spec defines what that plane should look like for remote servers (OAuth, tokens scoped to a named server, real authorization rather than a shared key in a config file) but it is optional, and the field reflects it. A May 2026 measurement study of 7,973 live remote MCP servers found that 40.55% expose their tools with no authentication at all, and among the smaller set of OAuth-enabled servers tested, every single one exhibited at least one security flaw. More than 300 CVEs have been filed against MCP infrastructure to date. The identity plane is forming with or without your security team. The question is whether the authorization model that accompanies it is one you would accept anywhere else.
Every MCP server is an identity issuer now
An MCP connection is an identity exchange, even when neither side is describing it that way. When an agent connects to a server, the server holds credentials, defines what tools exist, declares what scopes those tools require, and authorizes every call coming in. The user sees a tool catalog. The server is running an authorization system on the user’s behalf.
When the server is set up correctly (i.e. with a user-bound OAuth token, scoped to that server, evaluated on each call), identity flows cleanly from the user, through the server, to the underlying app. When it is not, the agent inherits whatever credentials the server happens to hold. A static key in the server’s environment becomes the de-facto identity for every call routed through it.
That compounds across servers. Each new MCP server an agent connects to adds another identity-bearing surface, with its own credentials and its own posture on caller verification. The agent’s effective access is closer to the union of every connected server than to what the user was ever granted. MCP inverts the familiar model: the server in the middle is the new identity layer, and most of them are not built like one.
That union framing is also too simple in the other direction. Agent access ends up governed by whatever policy rules the server implements, and those rules can be more or less permissive than the user’s own entitlements, not simply an intersection or union of them. A poorly scoped server can just as easily grant an agent less than the user has, or something the user never had at all. Call it blended identity: the effective actor behind any given call is some blend of the user, the agent, and the session, not a clean handoff from one to the next, and most authorization models still assume the clean handoff.
Inheritance is the default failure mode
According to the same measurement study, every OAuth-enabled server tested exhibited at least one authentication flaw, and 96.6% had vulnerabilities in dynamic client registration alone. A server that bothers to authenticate its callers at all is still routinely misconfigured enough to accept the wrong ones. This is the confused deputy problem applied to AI tools: the server acts on its own credentials while believing it is acting on the user’s, and the backend grants the request because the caller looks privileged.
Tool poisoning amplifies the same failure. Invariant Labs’ April 2025 disclosure showed that hidden instructions in one MCP server’s tool descriptions can hijack a separate, legitimate server running on the same agent. Their proof of concept exfiltrated WhatsApp message history through a trivia-game server installed minutes earlier. Simon Willison’s “lethal trifecta” provides a name for the structural problem: an MCP-connected agent has private data, untrusted content, and external communication available simultaneously. Every mitigation that actually works starts with tightening the identity the tools run under. The protocol provides the primitives. Most deployments do not use them.
Shadow MCP is shadow IT with credentials attached
Shadow IT was always a visibility problem. Shadow MCP is a visibility problem and an identity-infrastructure problem at the same time. Every unsanctioned MCP server an engineer installs is itself a credential-holding resource: it defines its own scopes, authorizes its own calls, and grants the connecting agent whatever access it was configured with. Security did not issue any of it. Compliance cannot see it. The agent inherits all of it. A renegade SaaS tool on a marketing card had a known auth model and a bounded blast radius. A local MCP server sitting next to a developer’s coding agent has neither.
The difference is not just posture, it is mechanism. An agent that goes through a broker for scoped, ephemeral credentials never touches the underlying secret. A local agent holding the raw credential directly has no boundary to bypass, because there was never a boundary in the first place. That is the pattern showing up across agentic deployments right now: agents acquiring credentials outside any enforcement boundary at all, not agents breaking through one.
A February 2026 Gravitee survey of over 900 enterprise executives and technical practitioners put a number on the scale: only 47.1% of the AI agents those organizations had deployed were actively monitored or secured, and 88% had a confirmed or suspected agent incident in the prior twelve months. The unmonitored ones are not just workloads no one has cataloged. They are workloads holding credentials no one issued, talking to servers no one approved.
The protocol is not going to solve this on your behalf. In April 2026, OX Security publicly disclosed a structural flaw in MCP that yielded remote code execution against six live production platforms. Anthropic declined to fix it at the protocol level. Whatever governance shadow MCP gets, the organizations deploying it will apply.
Recommendations
– Treat MCP as identity infrastructure, not plumbing. Every internal MCP server is a resource server in your identity perimeter. Govern it like any internal API holding OAuth scopes.
– Inventory every MCP server reachable from an agent. Discovery is the prerequisite for everything else; shadow MCP servers cannot be scoped or revoked until they are visible.
– Require OAuth 2.1 with resource indicators on internal servers; refuse static API keys for production agents. The spec ships the primitives. The path of least resistance (like a long-lived key in an .env file) is not one of them.
– Bind authorization to the caller identity, not to cached session state. Every tool invocation should be evaluated against the user who actually triggered it, not whoever authorized the server first.
– Issue credentials scoped to the call, not the session. A short-lived, narrowly scoped credential minted per invocation limits the blast radius of any single compromised call. A broad credential cached for the life of a session does not.
– Run agent tool calls through a gateway that enforces approval on destructive operations, at the argument level, not just the tool level. Approving that an agent can call a tool is not the same as approving what it passes to that tool. Tool descriptions are not policy; they are content the model reads, and an attacker who controls a connected server can rewrite them. A gateway alone is not enough: if enforcement lives only there, any path that reaches the resource directly (a raw credential, a second connector, a misconfigured scope) bypasses it entirely. Enforcement has to sit at the entitlement layer and evaluate identity at the moment of action, not just at the gateway in front of it.
– Scope and lifecycle the agent’s OAuth grants using workload identity federation, not shared service accounts. Treat them as non-human identities subject to JIT issuance and revocation, not standing authorizations that outlive the project that requested them.
In a nutshell…
MCP is doing for AI tools what OAuth did for SaaS, except OAuth took a decade and several painful breaches to settle on the right primitives, and MCP is shipping them faster than most teams can read them. The protocol says the right things but the deployed reality is more than half of credential-requiring servers on long-lived static secrets, nearly half exhibiting authorization defects, and a growing pile of CVEs against the rest. The identity plane your agents run on is whatever the last MCP server someone installed decided it should be. That is not the layer to leave to chance.