4 minutes
How to detect shadow MCP servers
Linda Vu Nguyen
How to detect shadow MCP servers
Shadow MCP servers are MCP servers that agents connect to without formal security review or organizational approval: the agentic equivalent of shadow IT. The short answer for detection: combine a known-server risk inventory (the MCP Trust Registry) with runtime observability of what agents actually connect to in production (BlueRock Observability). Neither alone is sufficient; together, they close the gap.
Part of the MCP Security cluster. Related: how to secure MCP servers and MCP security best practices.
Why shadow MCP is a distinct problem
Traditional shadow IT typically means a developer spun up a SaaS tool without IT approval. Shadow MCP is faster-moving and harder to catch. When a developer connects an agent to an MCP server, whether from a public registry, a side project, or a third-party integration, that connection happens in code or config, not in a ticket. Security rarely sees it.
The stakes are higher than most teams expect. BlueRock's scan corpus of 12,000+ MCP servers (as of June 2026) shows 6% carry critical vulnerabilities, 33% have unbounded URI or SSRF vulnerabilities, and 42% have command injection flaws, evaluated against the OWASP MCP Top 10, MAESTRO, and MITRE CWE frameworks. More than 20,000 new servers are published monthly. An agent that connects to an unreviewed server inherits every vulnerability on it.
The broader problem is structural: you cannot apply guardrails to a server you don't know exists. You can't audit an action path when part of it runs through an invisible component. Governance without visibility isn't governance; it's guesswork.
What makes a server "shadow"
Shadow MCP falls into three categories in practice:
Unapproved public servers. Developers pull a public MCP server from a registry without checking it against any internal approval list. Common in fast-moving teams where the agent toolset evolves daily.
Internal servers without security review. Teams build their own MCP servers for internal use (customer data connectors, code execution wrappers, database bridges) and skip the security scan. The private repo scanning flow addresses this case directly.
Stale or outdated approvals. A server was reviewed once, months ago. It has since been updated by its maintainers, and the update introduced new vulnerabilities. The approval stayed; the risk changed.
All three share the same root failure: no persistent connection between the server in the config and any current security posture assessment.
Detection approaches
Detection works across four distinct signals. None is a silver bullet; layering them gives you coverage.
Signal | What it surfaces | Gaps |
|---|---|---|
Config and code inventory | MCP server names in agent configs, | Only catches what's declared; dynamic or late-bound connections are invisible |
Package and dependency scanning | MCP SDK imports, transport library versions, server package refs in | Misses servers loaded at runtime via network URLs rather than installed packages |
Network traffic analysis | Outbound connections from agent processes to MCP server endpoints (ports, hostnames, TLS handshakes) | Requires network instrumentation; encrypted traffic conceals payload; doesn't tell you which agent made the call |
Runtime observability of agent→MCP connections | Which agents connected to which MCP servers, which tools were invoked, what parameters were passed, traced through durable agent identifiers | Requires an observability layer instrumented at the agent execution layer, not just the network layer |
For most teams, config/code inventory is the starting point: it's cheap, covers the majority of declared servers, and produces an initial list to vet. The hard cases (dynamic server loading, runtime-discovered endpoints, third-party integrations that surface MCP connections implicitly) require runtime observability.
How BlueRock surfaces shadow MCP
BlueRock's approach combines two capabilities: known-server risk assessment via the MCP Trust Registry, and runtime visibility of actual agent-to-server connections via Observability and the Trust Context Engine.
MCP Trust Registry: known-server risk. The registry scans MCP servers against 22 security rules mapped to the OWASP MCP Top 10, MAESTRO, and MITRE CWE. It classifies MCP tools as read, write, destructive, admin, iam, and cost-impact, so security teams can apply classification-aware governance policies. For internal or enterprise MCP deployments, private repo scanning is available. The registry answers: "Of the servers we know about, which ones carry risk?" What it does not do: automatically discover servers your agents are connecting to at runtime. Discovery requires the runtime layer.
Observability + Trust Context Engine: runtime connection visibility. BlueRock's Observability product traces the full Agentic Action Path (model → agent → MCP → data → execution → outcome) powered by durable agent identifiers that persist across every hop. This means BlueRock sees, in real time, which agent connected to which MCP server, which tools were called with what parameters, and what happened next. A server that doesn't appear in your approved inventory but shows up in the Agentic Action Path is, by definition, a shadow MCP server.
The detection sequence in practice:
Instrument your agent environment with BlueRock Observability.
Let agents run. BlueRock traces every MCP connection through durable agent identifiers.
Cross-reference observed servers against your approved inventory. Gaps are candidates for shadow MCP.
Vet unknown servers against the MCP Trust Registry for known vulnerability signatures.
Apply guardrails to block, restrict, or alert on connections to unapproved servers before execution.
This is not a magic scanner. No tool automatically enumerates every possible MCP server a developer might add tomorrow. What BlueRock provides is continuous runtime visibility: when a new connection appears in the Agentic Action Path, you see it.
Building an ongoing inventory
Detection is not a one-time audit. Shadow MCP accumulates over time because the development pace of agentic systems outstrips the speed of security review. A practical ongoing program combines:
Weekly config sweeps: automated diff of agent config files in your repo against an approved server list.
Continuous runtime observation: BlueRock Observability running in production, surfacing new MCP connections as they appear in agent action paths.
Triggered re-scans: every pull request that modifies agent configuration or adds an MCP SDK dependency triggers a Trust Registry scan.
Periodic re-vetting: approved servers re-evaluated quarterly, or whenever the registry reports a new critical finding for a server you use.
The 20,000+ servers published monthly means your approved list ages quickly. A server that was clean in January may not be clean in June.
What to do when you find one
Not every shadow MCP server is malicious; some are just unapproved. A proportionate response:
Identify the owner. Who added the server, and why? Most shadow MCP is well-intentioned.
Run a registry scan. Check the server against the MCP Trust Registry. If it carries critical findings, treat it as a live risk.
Classify its tools. Does the server expose write, destructive, admin, or iam tools? Higher classification means higher urgency.
Apply a guardrail immediately if the server is actively connected in production and you can't immediately determine it's clean. BlueRock Guardrails can restrict or block specific MCP tool invocations pre-execution with under 5ms latency overhead.
Fast-track review or remove. Bring it into your approval process if it passes the scan. Remove it from agent config if it fails.
The goal is not zero shadow MCP; teams move too fast for that. The goal is that no shadow MCP server you don't know about runs unreviewed in production for longer than your detection cycle.
Shadow MCP is a symptom of the same structural shift that produces the Agentic Execution Gap: agent behavior is defined at the app runtime, not in code. The server an agent connects to today may not be the one you reviewed last month. Runtime visibility is the only reliable way to stay current.
FAQ
What is a shadow MCP server?
A shadow MCP server is an MCP server that an agent connects to without formal security review or organizational approval — the agentic equivalent of shadow IT. It can be a public server a developer added quickly, an internal server built and deployed without a scan, or a previously approved server whose security posture has since changed.
Why are shadow MCP servers a security risk?
BlueRock's scan of 12,000+ MCP servers (as of June 2026) shows 6% carry critical vulnerabilities, 33% have unbounded URI or SSRF vulnerabilities, and 42% have command injection flaws. An agent that connects to an unreviewed server inherits its vulnerabilities. Because agents can invoke tools that write data, execute code, and call external services, a compromised MCP connection can propagate damage across the full Agentic Action Path.
How do you detect shadow MCP servers?
Detection works across four signal layers: config and code inventory (declared servers in agent configs), package and dependency scanning (MCP SDK imports), network traffic analysis (outbound connections from agent processes), and runtime observability of actual agent-to-MCP connections. Runtime observability, powered by durable agent identifiers that trace the full Agentic Action Path, catches what the other layers miss: servers loaded dynamically or discovered at runtime rather than declared in config.
What should you do when you find a shadow MCP server?
First, identify who added it and why. Then run it through the MCP Trust Registry to check against 22 security rules. Classify its tools (read, write, destructive, admin, iam, cost-impact) to gauge risk level. If the server is actively connected in production and you can't quickly verify it's clean, apply a BlueRock guardrail to restrict or block its tool invocations pre-execution. Then either fast-track it through your approval process or remove it from agent configuration.
Does BlueRock automatically scan for all MCP servers in my environment?
BlueRock provides two complementary capabilities: the MCP Trust Registry assesses known servers against 22 security rules, and Observability traces actual agent-to-server connections in production through durable agent identifiers. When a new connection appears in the Agentic Action Path that isn't in your approved inventory, BlueRock surfaces it. This is runtime discovery through observability, not a network port scanner; servers that haven't yet been connected to by an agent won't appear until they are.
