Shadow MCP Servers: The AI Infrastructure You Can't See

In 2012, the "Shadow IT" crisis was employees putting files in Dropbox for convenience. In 2026, the crisis is Shadow MCP.

Instead of a simple file storage app, security teams are now facing unvetted AI agents with the power to read from and write to internal systems. These servers are often running on infrastructure that was never reviewed, never approved, and remains entirely invisible to governance.

For mid-market organizations—where developer self-service is the norm—Shadow MCP is likely already present at an uncomfortable scale. If your team is already drowning in manual context-gathering (with many teams spending 43% or more of their time gathering context instead of deciding or remediating), this invisibility makes the problem materially worse. 

You don't need to work harder; you need visibility into the AI infrastructure already running in your environment.

Defining Shadow MCP

The OWASP MCP Top 10 defines shadow MCP servers as MCP instances that operate outside formal security governance — unapproved, unsupervised, and typically unknown to the security function.

Like their Shadow IT predecessors, they are rarely deployed with malicious intent. The typical origin is a developer experimenting with AI tooling, a data scientist building a prototype, or a research team exploring automation. 

The MCP development experience is specifically designed to be frictionless — setting up a server takes minutes with lightweight SDKs in Python or TypeScript, and connecting it to an AI IDE requires only a configuration file edit. There is no approval workflow. No installation log. No record of it happening.

What shadow MCP servers tend to have in common:

• Default credentials or no authentication.
• Permissive access configurations (broader permissions than necessary for their stated purpose).
• No logging of tool invocations.
• No patch management or version monitoring.
• Potential to process sensitive data without governance controls.
• Possible non-compliance with GDPR, PCI DSS, or SOC 2 obligations, depending on what data they touch.

For most mid-market security teams, the honest answer to "do we have shadow MCP servers?" is: "I don't know," which is itself the answer.

Why is this problem growing faster than you can track it?

Several structural factors make shadow MCP proliferation difficult to control with the tools most mid-market teams currently have.

Installation friction is near zero

A developer adds three lines to a JSON configuration file in Cursor or VS Code, and a new MCP server is active. There is nothing to approve, no package manager flag, no IT request. The security team has no natural detection point.

Tooling ecosystems actively encourage experimentation

The AI IDEs most popular with developers — Cursor, Claude Code, Windsurf — are built around the premise of rapid iteration. MCP server exploration is a first-class feature, not an edge case. The documentation for these tools actively guides users toward community registries to find new capabilities.

No MCP equivalent of automated dependency scanning

Tools like npm audit, Dependabot, Snyk, and others provide passive detection of risky or outdated dependencies in traditional software projects. No equivalent tooling exists for MCP server inventories. Manual review is the only option today.

Shadow AI adoption is accelerating rapidly 

MCP servers are the infrastructure layer of agentic AI. As shadow AI grows, so does the unmanaged MCP inventory beneath it.

For a three-person security team covering five hundred employees with forty active developers, the realistic probability that at least one unapproved MCP server is running in your environment is high. The realistic probability that you know about it is low.

The three dimensions of the Shadow MCP problem

Shadow MCP presents three distinct challenges that require different responses, and conflating them potentially leads to incomplete governance.

Dimension 1: Shadow servers in public registries

This is the external threat. Threat actors can publish MCP servers impersonating your brand, your product names, or the names of tools you use, targeting your employees or, in the case of organizations with developer-facing products, your customers' employees.

An employee searching for an official integration in Smithery or MCP.so may encounter an unofficial server using your brand name before they find the legitimate one. They install it, and from that point, any data that the server processes is in the hands of whoever built it.

This risk has two faces:

1. Inbound: Your employees install an unofficial server impersonating a tool you use — exposing your environment and your data.
2. Outbound (brand risk): Unofficial servers impersonating your brand are installed by your customers or partners — exposing their data through what they believe is your product, and creating reputational and potentially legal liability for your organization.

Both require the same initial response: continuous monitoring of public registries for your brand names, product names, and associated keywords. A one-time search is a point-in-time snapshot. New servers are published daily, and monitoring must be ongoing to gain true visibility.

Dimension 2: Shadow servers in your internal environment

This is the internal threat. Developers deploy MCP servers within your organization — on local machines, development servers, or cloud instances — without registration or security review. These servers may:

• Process sensitive internal data (customer records, source code, financial information).
• Connect to production databases or APIs with broader-than-necessary permissions.
• Expose functionality to the internal network on non-standard ports.
• Communicate with external services — including attacker-controlled infrastructure — without detection.

Standard asset inventory processes do not capture these. Network monitoring tools are not configured to identify MCP traffic specifically. The servers exist in a detection gap between what IT manages and what security can see.

Dimension 3: Externally reachable MCP endpoints

The third dimension sits between the first two: MCP servers that were deployed for internal use but have become externally reachable — either by design, misconfiguration, or infrastructure drift.

Organizations integrating MCP into their AI applications frequently create new internet-facing endpoints as a consequence: a subdomain for the MCP service, an OAuth redirect URL added to a reverse proxy, an API gateway route configured "temporarily" during testing that was never removed. These changes happen faster than management processes can track.

Attack Surface Management platforms, including CyCognito and Escape, have each added native MCP endpoint discovery in response to documented demand. Both note the same observation: an externally reachable MCP endpoint — regardless of whether it was intentionally exposed — is a callable attack surface whose risk is defined by the tools it exposes, the systems those tools can reach, and what access controls govern its use.

For a mid-market security team that already manages external attack surface as part of its program, MCP endpoints need to join the asset inventory. 

What good visibility looks like

The OWASP Shadow MCP Servers guidance defines a detection and governance baseline. For a lean team, it is most useful to think of visibility across three layers:

1. External registry layer: What MCP servers are being published in public registries that involve your brand, your tools, or your customers' brands? This layer requires continuous automated monitoring. Manual searches are inadequate as new servers appear daily.
2. External attack surface layer: Which MCP endpoints are reachable from the public internet in your organization's footprint? This requires integrating MCP-specific discovery into your existing EASM scanning. This involves looking for paths characteristic of MCP services, certificates on unexpected subdomains, and API routes that exhibit MCP protocol behavior.
3. Internal environment layer: What MCP servers are installed or running across developer workstations, development servers, and cloud instances within your environment? This layer is currently the hardest to instrument. A direct inventory — asking development team leads, reviewing IDE configuration files, auditing cloud deployments for MCP-characteristic traffic — is the starting point.

The five questions that establish your current baseline

These questions are designed to be answerable in a short conversation with development team leads and a basic review of your existing asset inventory and network monitoring tools. You do not need specialized AI security tooling to answer them.

1. Are there any MCP endpoints discoverable on your external attack surface?

• A basic external scan looking for routes like /mcp, /agent/tools, and /context on your known domains and IP ranges will reveal any inadvertently exposed endpoints. This takes less than an hour with existing scanning tools.

2. Do you have visibility into MCP servers installed on developer workstations?

• Ask, do not assume. Ask development team leads in the next week: what MCP servers are configured in your IDE tools? Document the responses. That is your current inventory baseline.

3. Are unofficial MCP servers using your brand or product names published in any major registries?

• Search your organization name, product names, and the names of any developer APIs or integrations you offer in Smithery.ai and MCP.so. This search takes fifteen minutes and may reveal an impersonation you were not aware of.

4. Is MCP server installation covered by your existing software procurement or open-source dependency policy?

• If not, it should be. A simple addition — requiring that MCP servers be reviewed and documented before installation — creates a governance touchpoint where none currently exists.

5. Do you receive alerts when new endpoints appear in your external footprint?

• If your EASM program already provides this, check whether the alert criteria include MCP-characteristic routes and patterns. If not, adding those patterns to existing alert rules is a low-effort, high-value change.

If the answer to most of these is "no" or "I don't know," you have identified your current exposure baseline.

The window of exposure

The gap between when a shadow MCP server is deployed and when your security team discovers it is not a gap you can afford to leave unmanaged indefinitely. The incidents documented in this series — the SmartLoader supply chain attack, the GitHub prompt injection, the Supabase SQL exfiltration — each exploited a window of time during which an organization had exposure they were not aware of.

For Shadow IT, that window was measured in months before governance caught up. For MCP, the threat actor response has been significantly faster. MCP launched in November 2024; the first documented supply chain attack appeared less than 15 months later.

The organizations that close the visibility gap first will have the strongest position when — not if — MCP-related incidents become more frequent. 

The external registry dimension of shadow MCP is exactly what UpGuard Breach Risk's Threat Monitoring addresses: continuous discovery of MCP servers published across major registries, brand impersonation detection, and alerts for newly published servers — so your team closes the visibility gap without adding headcount. 

See what Threat Monitoring discovers about your organization →

Final post in this series: Post 6 — The MCP Security Playbook: A Practical Guide for Mid-Market Teams