Resource / Definition

What is shadow MCP?

Shadow MCP is an unapproved Model Context Protocol (MCP) server. It is the MCP-specific form of shadow AI, cataloged as MCP09 in the OWASP MCP Top 10.

Scroll for definition
Nolan Sullivan headshotBy Nolan Sullivan, Founding Growth Engineer
Published
Definition

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.


Agent securityDefinitionSpeakeasy

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 shadow MCP discovery worksClient telemetry and managed network telemetry observe different MCP connections. Comparing both sources against the sanctioned register sends unknown connections to an inventory for review, ownership, and disposition.SECURITY OPERATIONS · SHADOW MCPFind the connection before it becomes an exceptionOne source cannot see every connection.ENDPOINT SIGNALClient telemetryLocal stdio servers and tool callsNETWORK SIGNALManaged trafficRemote MCP on inspected pathsCOMPARE WITHSanctioned registerApproved server recordsUNKNOWN CONNECTIONMCP INVENTORYAssign an owner and dispositionAPPROVEGoverned pathREVIEWOwner assignedREMOVECredential rotatedDiscovery creates evidence for a decision. The inventory records the result.

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.

Frequently asked questions

What is shadow MCP?

Shadow MCP is a Model Context Protocol (MCP) server that an employee or team has connected to without security approval. It can be a local process configured in an MCP client or a remote endpoint. The OWASP MCP Top 10 catalogs the risk as MCP09.

How does shadow MCP differ from shadow AI?

Shadow AI is the broader category of AI models, agents, MCP servers, and skills used outside the security perimeter. Shadow MCP focuses on the tool-server slice. It asks which MCP servers an organization's agents call without approval, then records each server, its tools, and its associated identity in an MCP inventory.

Is shadow MCP the same as OWASP MCP09?

MCP09:2025 Shadow MCP Servers is the OWASP MCP Top 10 entry that catalogs the risk. OWASP defines shadow MCP servers as unapproved or unsupervised deployments of Model Context Protocol instances that operate outside the organization's formal security governance. Shadow MCP as a term names the population itself, and MCP09 is where the risk, its impact, and the recommended controls are written down.

How do you detect shadow MCP?

Use more than one signal. Client-side hooks or telemetry can observe servers used by supported clients, including local stdio servers. Network controls can identify remote MCP traffic on managed, TLS-inspected paths. Compare observed connections with the sanctioned register, then record exceptions in an MCP inventory with an owner and disposition.

How do you stop shadow MCP?

Disconnect the server, revoke or rotate the credential associated with it, and give the team a reviewed alternative. The alternative might be a managed catalog delivered through MDM or an allowlisted path through an MCP gateway. An observability-first rollout can flag unsanctioned connections and give teams time to move before enforcement begins.

Does an MCP inventory eliminate shadow MCP?

No. The inventory is the register where discovery findings land, and it also holds sanctioned server records. New unsanctioned connections can appear when a client configuration changes, so a live discovery feed surfaces them as records awaiting disposition.

AI everywhere.

Control here.