The Shadow MCP Iceberg: What You Don’t See Can Hurt You

Dom Delnano

AI agents are rapidly weaving themselves into everyday workflows. As state-of-the-art models grow more powerful and the contract between a model and the external world takes shape, developers are racing to feed them as much context as possible. What are MCP servers?

MCP servers expose a JSON-RPC interface that provides large language models access to tools. Tools allow AI agents to take action like querying a database or sending emails to customers. This bridges the gap between the model and the outside world, allowing agents to achieve more complex tasks on behalf of the user.

While LLM tool calling existed before MCP, the real power of MCP lies in its standardization. By acting as a lingua franca for agents and AI applications, MCP makes it possible to easily compose and reuse integrations, rather than relying on one-off or ad-hoc connectors. Shadow MCP and its Dangers

"Shadow MCP" refers to any MCP client or server running in your environment that bypasses normal security review or your company’s onboarding process. Like Shadow IT, it creates hidden risks that fall outside of organizational oversight and controls.

The danger stems from MCP’s power: it allows AI applications to plug directly into external systems. When those integrations are unvetted, they open the door to new attack vectors. Prompt injection is a clear example. The more integrations a model has, the greater the chance malicious instructions can slip in and abuse those connections.

We’ve already seen this risk play out in the open. The Invariant Labs team disclosed a GitHub MCP server vulnerability that showed that even well-designed, officially supported servers can enable prompt injection attacks. In that case, a model could be tricked into exfiltrating sensitive private repository data simply by processing a malicious GitHub issue.

If this is possible in a flagship integration built by GitHub itself, the risks multiply when it comes to "shadow" MCP servers that have never gone through security review.

Identify MCP usage in your organization

The first step in managing risk is simply knowing where MCP shows up. MCP servers speak JSON-RPC, and their requests have a few tell-tale method names like tools/call, tools/list, or resources/list. Watching for these traffic patterns is often enough to flag MCP usage and start building an inventory of which servers and clients are running in your environment. Gaining visibility into Shadow MCP servers

Spotting authorized MCP is one thing, but surfacing shadow deployments is the harder challenge. These servers and clients may never pass through a proxy or may hide behind encryption.

eBPF provides a powerful way forward: by tapping into syscalls and TLS libraries, it can reveal JSON-RPC traffic patterns directly on the host.

For local stdio servers, where traffic never touches the network, traditional security tools like EDR (Extended Detection and Response) or IDS (Intrusion Detection System) can help flag these servers. These tools can help monitor these servers through the following:

Monitor for common MCP processes

Use custom detection rules to more easily spot MCP processes Monitor MCP related config files to flag any potentially dangerous integration Closing the Gap

Identifying these risks is only the beginning. Since MCP’s release, multiple vulnerabilities have already been disclosed: a signal that the ecosystem is evolving faster than security practices. The GitHub case makes it clear that even “official” servers aren’t immune, which means unreviewed shadow MCP instances broaden the scope of AI-related vulnerabilities far beyond what most teams realize.

At Cosmic, we believe it’s critical for security to catch up. We’re building safeguards for agentic applications, with a focus on securing MCP, and we’d love to partner with teams who share this urgency. If you’re exploring or rolling out MCP, let’s connect.