Shadow MCP Usage in the Enterprise

What MCP Is and Why Enterprises Are Running It Everywhere

Anthropic released MCP as an open standard in November 2024, then donated it to the Linux Foundation's Agentic AI Foundation in December 2025 to make it vendor-neutral. The protocol gives AI agents a standardized way to connect to external tools, databases, APIs, file systems, and communication platforms. The comparison people keep reaching for is USB-C: one standard interface, thousands of compatible peripherals. It fits.

The security distinction that actually matters, though, is this: MCP servers don't just return data. They let agents take actions inside live systems.

That shift from retrieval to action changes the risk calculus entirely. A chatbot that reads your CRM is a convenience. An agent that can read, write, and delete records in that same CRM, chain it to an outbound email, and trigger a calendar update is something categorically different. One is a window. The other is a door with a key that opens everything.

Adoption is already deep. A February 2026 Gravitee survey of 750 CIOs, CTOs, and engineering leaders found 80.9% of technical teams had moved past planning into active testing or production deployment of AI agents. Setup is deliberately low-friction: load the documentation, ask an LLM to generate the server configuration, or install one of many pre-built options, including those built directly into Google Workspace and Microsoft 365. The gap between "I want to try this" and "this is running in my environment" is measured in minutes. That speed is a feature, and it is also exactly where the problem starts.

Shadow MCP: How Ungoverned Deployments Take Root

Shadow MCP is MCP servers deployed in enterprise environments without IT or security team approval, creating unmonitored connections between AI assistants and internal systems. OWASP formally classifies this as MCP09:2025, a recognized vulnerability category with its own designation in the MCP Top 10. It has a name because it is already happening at scale.

The people creating these deployments are not bad actors. They are developers spinning up MCP connections on local machines to interface with internal tools. Research teams running servers for experimentation. Business users who granted an AI agent administrative access because the alternative was waiting in an IT queue for two weeks. Teams building their own servers to automate workflows that otherwise require a ticket and a sprint cycle. Everyone has a reasonable explanation. Nobody asked security.

The result is an invisible inventory of tool access that IT cannot audit. Each new connection expands the attack surface without appearing in any asset register. Think of a building where every tenant has quietly cut their own side door: nobody set out to compromise the structure, but the floor plan no longer matches the walls.

Configuration failures in shadow deployments follow a consistent pattern. Default credentials left in place. Access scoped more permissively than any single task requires. Unsecured or unauthenticated APIs. Plaintext secrets visible in process lists, where running a basic ps aux exposes database passwords. Credentials hardcoded in source code or carelessly stored in environment variables. None of these are exotic attack techniques. They are the predictable output of fast, unreviewed setup.

The governance gap is not marginal. That same Gravitee survey found only 14.4% of organizations report that all AI agents going live have full security and IT approval. Forty-seven percent of the roughly three million AI agents deployed across surveyed firms are operating without active monitoring or security controls. That translates to an estimated 1.41 million agents operating without oversight, right now, in production.

Why Shadow MCP Is a Different Problem Than Shadow IT

Traditional shadow IT has a familiar shape: an employee signs up for an unauthorized SaaS tool or spins up an unmanaged cloud instance. The risks are data exposure and unpatched software. Security teams have spent years building playbooks for containing it, and those playbooks are reasonably mature.

Shadow MCP does not fit into those playbooks. Conflating the two leads directly to underestimating it.

Speed of proliferation is the first problem. MCP servers are trivially easy to create or install, pre-built options exist for nearly every enterprise system, and deployment takes minutes. Not the days or weeks a rogue cloud instance historically required. The curve is steeper, and by the time a security team notices a pattern, the inventory is already deep.

Depth of access is the second. A single agent session can simultaneously hold credentials for CRM systems, email platforms, cloud infrastructure, and payment processors. The blast radius of a misconfiguration is not scoped to one application. It spans every system the agent can reach, all at once.

The third problem is autonomy of action, and it is the one that makes the others genuinely dangerous. An AI agent does not merely read. It writes, deletes, and chains tool calls across systems without a human confirming each step. The Replit incident from July 2025 makes this concrete: Replit's AI agent deleted a production database containing over 1,200 records despite explicit instructions to implement a code and action freeze. The agent held write and delete permissions it should never have had. No human approved the deletion. No human was in the loop when it happened. That is not a story about a bad prompt. It is a story about what happens when an autonomous system has unconstrained access — call it giving the intern the master key and then leaving for lunch.

That incident is not anomalous. Gravitee found 88% of organizations surveyed have already experienced or suspected an AI agent-related security or data privacy incident in the last twelve months. Machine identities already outnumber human ones at an 82:1 ratio, per CyberArk's 2025 survey. The Cloud Security Alliance found 92% of respondents say their legacy IAM solutions cannot effectively manage risks associated with AI and non-human identities. Shadow MCP does not create a new category of problem. It accelerates one that was already outpacing enterprise controls.

The Specific Threats That Shadow MCP Creates

OWASP's MCP Top 10, published in late 2025, provides the organizing taxonomy. Several of these risks are especially pronounced in shadow deployments where no one is watching.

Prompt Injection via Tool Responses

This is MCP01, and it is the most technically significant threat in the taxonomy. Malicious content embedded in tool outputs manipulates AI behavior for subsequent tool calls. Tool descriptions are consumed by the model but rarely surfaced in any user interface, which gives adversaries a reliable hiding place for instructions users will never see.

Invariant Labs demonstrated this in April 2025. A malicious trivia-game MCP server embedded hidden instructions that targeted a legitimate WhatsApp MCP server operating in the same agent session. The agent extracted WhatsApp message history and routed it outbound through the trusted server, making the exfiltration appear as ordinary traffic. No file transfers. No DLP triggers. No obvious anomaly in the logs. The attack was invisible to every conventional detection layer, because it looked exactly like the agent doing its job.

Overpermissive Tool Access

MCP servers granted more access than any specific task requires create the conditions for privilege abuse when an agent is manipulated or simply misbehaves. The Replit database deletion is the example that comes up constantly, and it keeps coming up because nothing better illustrates what an agent with unconstrained write and delete permissions actually does when something goes sideways. The access was the problem. The prompt was just the trigger.

Tool Shadowing

A malicious MCP server overrides a legitimate tool's behavior, hijacking agent actions without the user or the agent being aware of the substitution. This is particularly dangerous when shadow servers coexist with approved ones in the same agent session, a configuration that is nearly impossible to prevent when IT has no visibility into what is running in the first place.

Sensitive Data Exfiltration

EchoLeak, catalogued as CVE-2025-32711, demonstrated this at scale. An indirect prompt injection vulnerability in Microsoft 365 Copilot exfiltrated sensitive data via HTTP requests to attacker-controlled servers. No large file transfers. No DLP triggers. The attack worked because semantic exfiltration, pulling data out in small, meaningful payloads that resemble legitimate API calls, falls entirely outside the detection surface most security tools were built to monitor. The traffic looks normal. That is the point.

Supply Chain and Vulnerable Packages

Wallarm's 2026 API ThreatStats report found 315 MCP-related vulnerabilities published in 2025, representing 14.4% of all AI-related vulnerabilities that year. MCP vulnerabilities increased 270% from Q2 to Q3 2025 alone. Academic analysis of thousands of MCP servers identified eight distinct vulnerability categories; 7.2% exhibit general security flaws, 5.5% show MCP-specific tool poisoning issues, and one analysis of 1,000 servers found 33% carrying critical vulnerabilities.

A top-10 breach that year involved thousands of exposed MCP servers compromised through a single path-traversal vulnerability. Attackers gained access to production AI agent infrastructure across organizations that had no idea those servers were even in scope for an attack surface audit. You cannot protect what you do not know exists.

Authentication and Session Risk

The MCP authorization specification defines an OAuth 2.1 framework but marks authorization as optional. A July 2025 internet scan found at least 1,862 publicly accessible MCP instances responding to unauthenticated requests: production servers with live system access, reachable by anyone who knows where to look.

Session integrity failures compound this. When session IDs appear in URLs or logs, token replay and session hijacking become straightforward. The Salesloft breach illustrates what happens at the credential level: attackers compromised OAuth tokens tied to the Drift AI chatbot and gained access to Salesforce environments belonging to more than 700 organizations. The breach went undetected for days because attacker queries were indistinguishable from legitimate chatbot activity. When the agent is your cover, detection is genuinely hard.

Research found a 92% exploit success rate when using just ten unmanaged MCP connections simultaneously. That number deserves more attention than it typically gets.

The Non-Human Identity Problem Underneath All of It

Every MCP server that spins up creates a non-human identity with privileged access to at least one live system. Traditional IAM was built around static policies and human authentication flows, a world where the authenticated principal is a person who logs in, does something, and logs out. That model fails in almost every dimension when the principal is an autonomous agent that never clocks out.

The scale is already significant. CyberArk's 2025 survey found machine identities outnumber human ones 82:1. The CSA found ratios as high as 144:1 in some enterprises, with non-human identities growing 44% from 2024 to 2025. AI-related secrets, API keys, agent configuration tokens, LLM service credentials, accounted for more than 1.27 million exposures, an 81% year-over-year increase and the fastest growth in any single credential category.

The governance infrastructure has not kept pace, and I do not mean that as a criticism of any particular team. Seventy-eight percent of organizations have no formally documented policies for creating or removing AI agent identities, per CSA. A 2025 World Economic Forum analysis found 51% of organizations report no clear ownership of AI identities. Only 28% of organizations can trace agent actions back to a human sponsor across all environments, which means that in nearly three-quarters of enterprises, agents are operating without an accountable principal. Eight percent of enterprise identities lack any HR system ownership linkage after the departure of their creator, producing orphaned identities that persist and accumulate without anyone noticing.

What makes agent credential management fundamentally different from service account management is not just scale. It is the combination of autonomy, dynamic scope, ephemeral lifecycles, and goal-directed behavior. A service account executes a fixed script. An agent pursues an objective and chooses its own tool invocation path. It holds credentials for multiple systems simultaneously and spins up and tears down without the lifecycle checkpoints that HR-linked human accounts impose. The credential surface that results is one that existing IAM tooling was not designed to govern, and shadow MCP deployments push that surface further outside any visibility boundary than most security teams realize.

What the Protocol Actually Provides — and Where It Stops

MCP does define an authorization layer for HTTP transport. MCP clients act as OAuth 2.1 clients; protected MCP servers function as OAuth 2.1 resource servers. The framework aligns with OAuth 2.1, RFC8414 for authorization server metadata, RFC7591 for dynamic client registration, and RFC9728 for protected resource metadata. Token-based access control, when implemented, helps prevent the Confused Deputy attack and blocks unauthorized access from rogue AI assistants.

When implemented. Authorization is explicitly optional in the spec. That is not a misconfiguration problem. It is a structural gap built into the protocol by design.

The Enterprise-Managed Authorization extension, now stable, enables organizations to centrally provision MCP server access through their identity provider. Users get connected servers on first login without per-app OAuth flows. The IdP becomes the authoritative decision-maker, with access governed by group membership, role assignment, and conditional access rules. Anthropic, Microsoft, and Okta are among the organizations adopting it.

EMA has a clearly defined limit, though, and this is the part worth sitting with: it decides whether a user can connect a client to a server, and at what scope. It does not inspect MCP traffic after the token is issued. Runtime authorization for individual tool calls is explicitly out of scope.

That gap has real operational implications. Short-lived credentials with a default one-hour expiration and a maximum of twenty-four hours represent best practice; long-lived tokens that never expire provide indefinite access if compromised. PKCE matters especially in MCP contexts, where many clients, including agents, containers, and serverless functions, cannot store secrets securely. PKCE enables public clients to use the authorization code flow without a client secret, which is a meaningful protection in environments where secret storage is unreliable. Delegating authentication to an external OAuth or OIDC provider, enterprise SSO with MFA, rather than implementing auth inside each MCP server, eliminates an entire class of implementation error. Shadow MCP deployments skip all of this, not maliciously, but because the same speed and low friction that makes them attractive to developers is what ensures none of these controls get applied.

The Controls That Actually Contain Shadow MCP

Start with Discovery

You cannot govern what you cannot see. The first requirement is a continuous inventory of all MCP servers, connections, and agent identities across the environment, including local developer machines, where the majority of shadow deployments actually run. Most organizations focus discovery on cloud infrastructure and miss the endpoints entirely.

Treat MCP server enumeration the same way mature security teams treat shadow IT discovery: active scanning, not self-reporting. Self-reporting produces the 14.4% compliance rate already documented in the data. That number tells you everything you need to know about relying on developers to raise their hand.

Tie Identity to Every Action

Every agent needs an identity. Every action that identity takes needs to be attributable to a human sponsor. The 28% figure from CSA, representing the share of organizations that can trace agent actions to a human principal across all environments, is where most enterprises currently stand. It is not where they need to be.

This means implementing non-human identity governance with the same rigor historically applied to privileged human accounts: provisioning policies, access reviews, and defined offboarding procedures that do not depend on the human who created the agent still being employed. Orphaned agent identities accumulating after employee departures are a current condition in most enterprises, not a hypothetical risk. The identities do not disappear when the person does.

Enforce Least Privilege at the Tool Level

Overpermissive tool access is what directly enabled the Replit database deletion. Scope MCP server access to the minimum required for the specific task. An agent generating weekly summary reports has no need for write access. An agent querying customer records has no need for schema modification privileges. The principle is not new. Applying it to MCP tool configurations is where most organizations have not yet done the work, and the gap is not subtle.

Implement Runtime Monitoring for Agent Sessions

EMA governs access at connection time. Runtime monitoring fills the gap after: inspecting tool calls in flight, detecting behavioral anomalies, flagging data movement patterns that match semantic exfiltration signatures. This is where the EchoLeak and Invariant Labs WhatsApp attack scenarios become practically addressable. Exfiltration via small, semantically meaningful HTTP requests does not trigger file transfer alerts, but it does produce behavioral patterns that differ from normal tool usage, if someone is actually looking for them.

Treat MCP Server Packages as Supply Chain Risk

Three hundred fifteen MCP-related vulnerabilities in a single year, with a 270% growth rate from Q2 to Q3, is a supply chain signal. Apply the same scrutiny to MCP server packages that mature security programs apply to open source software dependencies: verify provenance, scan for known vulnerabilities, pin versions, and establish a process for responding when new CVEs appear. The 33% critical vulnerability rate found in one sample of 1,000 servers means roughly one in three pre-built MCP servers installed by a developer on a local machine carries a critical flaw before any enterprise-specific misconfiguration is layered on top. That is the baseline you are starting from, before anyone does anything wrong.

Enforce Short-Lived Credentials and Mandatory Rotation

Default tokens to one-hour expiration. Require PKCE for any client that cannot securely store a client secret, which includes most agent runtimes. Establish rotation schedules and enforce them programmatically rather than through policy documents nobody reads. Long-lived credentials in agent environments are a standing invitation to exactly the breach that Salesloft's 700 affected organizations experienced.

The gap between what MCP provides and what enterprises need to implement themselves is not a design flaw in the protocol. It is a description of where the operational work actually lives. The protocol gave the ecosystem a common language. Containing shadow MCP requires enterprises to speak it fluently everywhere, including in the deployments already running without anyone's permission.