TL;DR
- Shadow MCP servers run outside an organisation's security governance, and OWASP now lists them in its MCP Top 10.
- They're a governance problem, separate from insecure configuration. Nobody can secure a server they don't know exists.
- They appear when the approved route is slower than the workaround.
- The lasting fix is making the governed path the fastest one.
Some of the biggest risks in an organisation are the ones nobody can see. For SaaS security and platform teams, one of those risks is now the MCP server that nobody approved, nobody monitors and nobody remembers spinning up.
MCP has become the standard way to connect AI agents to business systems. By December 2025, Anthropic reported more than 97 million monthly SDK downloads and over 10,000 active public MCP servers. Adoption at that pace brings back an old problem in a new form. It's shadow IT, where teams adopt tools faster than security can track them.
OWASP now lists shadow MCP servers as MCP09 in its MCP Top 10. This post looks at what they are, why they're a different problem from servers that are simply badly configured, and how teams can get ahead of them.
What is a shadow MCP server?
A shadow MCP server runs outside an organisation's security governance. Nobody approved it, nobody monitors it, and it doesn't appear in any inventory.
Most aren't created with bad intent. A developer installs a community MCP server to test an idea, points it at the CRM with a personal API key, and wires it into an agent. It works, so it stays. Like shadow IT before it, shadow MCP grows wherever the approved route is slower than the workaround.
Shadow servers and insecure servers are different problems
It's tempting to treat every MCP risk as a shadow MCP risk, but there are two separate problems here.
An insecure server has weak controls, such as no authentication, overly broad permissions or exposed secrets. That can happen to any server, approved or not. When Bloomberry scanned 1,412 public, company-operated MCP servers, 38.7% of those it could assess required no authentication at all. Researchers have also disclosed vulnerabilities in widely used MCP servers from Microsoft and Anthropic.
A shadow server is a governance problem. Its configuration might be fine or it might be dangerous, but nobody responsible for security knows it exists, so nobody can check. That's what makes it so risky. It removes the chance to catch problems before they cause harm.
The postmark-mcp incident shows what's at stake. In September 2025, a fake package on npm impersonated Postmark's MCP server and quietly blind-copied every email it sent to an attacker. It was downloaded 1,643 times before it was removed. An approved-source policy or dependency review is exactly the kind of check that catches a package like this, and exactly the check an unsanctioned install skips.
Matching controls to risks
Each MCP risk needs its own control, and no single control covers them all.
| Control | OWASP risk | How it helps | What it doesn't cover |
|---|---|---|---|
| Discovery scans and an MCP inventory | MCP09 Shadow MCP Servers | Brings unknown servers into scope for every other control | Finding a server doesn't fix its configuration |
| Approved sources, version pinning and dependency review | MCP04 Software Supply Chain Attacks & Dependency Tampering | Blocks impersonated or tampered packages before install | A later compromise of an approved source |
| OAuth tied to individual identities | MCP07 Insufficient Authentication & Authorization | Links every tool call to a known user or service | What an authenticated caller is allowed to do |
| Least-privilege tool scoping | MCP02 Privilege Escalation via Scope Creep | Limits the damage a misused agent can cause | Permissions drifting over time without review |
| Central secrets storage and short-lived tokens | MCP01 Token Mismanagement & Secret Exposure | Removes plaintext keys from laptops and shortens exposure windows | Misuse while a token is valid |
| Tool-call logging | MCP08 Lack of Audit and Telemetry | Supports detection and investigation | Incidents nobody reviews |
Some risks, such as prompt injection (MCP06), also need defences at the agent and model layer.
Why shadow servers keep appearing
Part of the pull is simple supply and demand. In our State of MCP 2025-2026 report, we found that 57% of the 816 SaaS products we tracked still had no verified official MCP server. Where no official server exists, developers who need one turn to community builds.
An open-source MCP server installs in minutes. A production-grade one needs authentication, credential storage, scoped permissions, hosting, logging and ongoing maintenance, multiplied across every system an agent needs to reach. When the sanctioned path takes weeks, people route around it.
Banning shadow servers rarely works, because it just pushes them further out of sight. The better answer is to make the approved path the fastest one.
Closing the speed gap with a managed platform
One way to close that gap is a managed platform that builds and hosts MCP servers with the controls above already in place. That's the approach we took with Cyclr's MCP PaaS, which allows SaaS teams to build MCP servers on top of existing APIs.
Mapped to the OWASP risks, that looks like this.
- Supply chain (MCP04). Servers are built from maintained connectors or custom connectors, not anonymous registry packages.
- Scope creep (MCP02). Teams choose which application functions each server exposes.
- Authentication (MCP07). OAuth and ring-fenced, per-tenant accounts keep access tied to the right identity.
- Inventory and telemetry (MCP08, MCP09). A central catalogue and monitoring cover every server on the platform. A platform is one part of the strategy, not the whole of it. Discovery tooling still needs to find servers running elsewhere, and approval policies still decide who can connect which systems. What a platform can do is make the governed route quick enough that teams choose it over the workaround.
Building a governance strategy
- Discover. Scan developer endpoints, CI pipelines, cloud accounts and agent configurations for MCP servers.
- Offer a fast approved path. Give teams a governed way to build servers that competes with the workaround on speed.
- Set sourcing and approval rules. Define which packages and connectors are permitted, and who signs off new integrations.
- Apply controls to every server. Approved status is not a substitute for authentication, scoping, secrets management and logging.
- Review and retire. Recheck permissions regularly and decommission idle servers and their credentials.
Make the governed path the fastest path
Shadow MCP servers appear when the approved route is slower than the workaround. Discovery and policy matter, but they only treat the symptoms. Giving teams a governed way to build secure MCP servers quickly removes the reason shadow servers exist in the first place.
This post is an adapted version of an article originally published on LinkedIn. Cyclr is an embedded iPaaS that helps SaaS teams build and manage API integrations and MCP Servers at scale.
Top comments (0)