shadow MCP
Shadow MCP is a Model Context Protocol (MCP) server an employee or team has connected to without security approval. The connection might launch a local process from a client configuration, or point the client at a remote endpoint. Either way, the server sits outside the organization’s review, identity, and monitoring processes.
The OWASP MCP Top 10 catalogs the risk as MCP09:2025 Shadow MCP Servers, defining shadow MCP servers as “unapproved or unsupervised deployments of Model Context Protocol instances that operate outside the organization’s formal security governance.” OWASP notes they are often spun up by developers, research teams, or data scientists for experimentation or convenience, frequently with default credentials, permissive configurations, or unsecured APIs.
Shadow MCP describes a population rather than a register. Finding those servers, recording them, and closing them are separate operations. Cloudflare describes the same condition from the connection side. Shadow MCP is “a connection to a server the organization has not approved.” Endpoint telemetry can reveal local configuration and stdio servers. Network telemetry can reveal remote connections on managed paths. Each view has blind spots, so neither is a complete inventory by itself.
How does shadow MCP differ from shadow AI?
Shadow AI is the broader category. It includes models reached through personal accounts, internal agents that have not been registered, skills loaded out of band, and MCP servers installed without review. What is shadow AI covers that category end to end, including the detection architecture.
Shadow MCP focuses on one object type: the server, the tools it exposes, and the identity associated with its connection. That focus gives security teams a consistent record to govern. A personal AI account, an unreviewed skill, and an unsanctioned server need different controls, while an MCP inventory can assign each server an owner and disposition.
Why do asset inventories miss shadow MCP servers?
An asset database can record an approved client application without recording every server that client can invoke. A local stdio server can be configured as a command in a client configuration file. A remote server can be configured as an endpoint and only appear as traffic when the client connects. The software inventory therefore needs a companion record of the server, its owner, the tools it exposes, and the identity used on the connection.
A survey has a different timing problem. Wiring up a new server can be a config-file edit, so a spreadsheet compiled by asking teams what they run may be stale before the review is complete. MCP inventories and agent inventories are the registers where shadow MCP findings can land. They do not replace the discovery process that finds new connections.
What MCP security risks does shadow MCP create?
An unsanctioned server can bypass the controls the sanctioned path is meant to apply. OWASP identifies three immediate MCP security risks:
- It can bypass centralized authentication, monitoring, and data-governance controls.
- It can create an unmonitored endpoint that expands the attack surface.
- It can complicate incident response when an untracked server delays containment and forensics.
The exposure is in the credential and the tools. A server that bypasses review may use an unapproved credential, expose write-capable tools without an appropriate policy, or send sensitive arguments to an endpoint outside the organization’s monitoring path. That does not mean every shadow server is compromised, but it leaves security teams without the evidence they need to assess the connection before it is used. OWASP identifies data exposure, attack-surface expansion, policy noncompliance, and incident-response complexity among the resulting MCP security risks.
How do you detect shadow MCP servers?
MCP discovery needs more than one signal. Client-side hooks or telemetry can observe the server, tool, and arguments before a supported client serializes a request, including calls to local stdio servers. Network controls can identify remote MCP traffic on managed, TLS-inspected paths. Compare those observed connections with the sanctioned register, then record each exception in an MCP inventory with an owner and disposition. The shadow AI reference covers the wider discovery architecture.
How can you reduce shadow MCP risk?
Closing a finding includes three actions:
- Disconnect the server.
- Revoke or rotate the credential associated with it.
- Give the team a reviewed alternative, such as an MCP registry delivered through MDM or an allowlisted path through an MCP gateway.
Removing a configuration entry without addressing the credential leaves the connection easier to restore.
The rollout order matters as much as the controls. An observability-first rollout flags unsanctioned connections, assigns each finding an owner, and gives teams time to move to the sanctioned path before enforcement begins. Enforcing a policy before a workable alternative is available can encourage teams to bypass it.
When a blocked server might be legitimate, an MCP approval workflow can attach the request, evidence, scope, and reviewer rationale to the same inventory record instead of moving the decision into Slack.
How does the Speakeasy AI Control Plane handle shadow MCP?
Everything above is architecture an organization could assemble itself. The Speakeasy AI Control Plane ships it as one system. Shadow MCP detection recognizes, from instrumented agent traffic, when a session connects to a server outside the sanctioned setup, and surfaces it by URL, host, or resolved identity. Each finding lands in the MCP inventory the platform maintains, as a record with an owner and a disposition next to every sanctioned server. The sanctioned path runs through the platform’s gateway, so approved servers come provisioned with identity, allowlists, and audit logging attached, and traffic can be required to flow through it once the observability-first window closes. To see which servers your agents are already calling that nobody sanctioned, talk to us.