Shadow MCP: The Tool Servers Your Security Team Has Never Heard Of Are Already Running on Your Engineers' Laptops

Your security team has a complete inventory of every SaaS subscription on the corporate card, every OAuth app with admin consent, every device on the corporate Wi-Fi. They have zero visibility into the seven processes bound to 127.0.0.1 on your senior engineer's laptop right now — a "deploy assistant" with a long-lived staging API token, a "ticket triager" subscribed to a customer-data Slack channel, a "release notes generator" with read access to the production analytics warehouse. None of it is on a vendor list. None of it shows up in the SSO logs. All of it is running on credentials the engineer already had, doing things nobody approved them to do.

This is shadow MCP, and it is the fastest-growing unmanaged authorization surface in the enterprise. The Model Context Protocol made it trivially cheap to wire any tool into any LLM, and engineers — being engineers — wired the obvious things first. Saviynt's CISO AI Risk Report puts the number at 75% of CISOs who have already discovered unsanctioned AI tools running in their production environments. The GitHub MCP server crossed two million weekly installs in early 2026. The Postgres MCP server, which gives an LLM a SQL prompt against any database the developer can reach, is north of 800,000 weekly installs. None of those numbers represent enterprise IT decisions.

The mental model most security programs still apply was built for a different artifact. Shadow IT is a SaaS subscription that hits an expense report, a vendor that gets discovered when a finance audit reconciles credit-card statements against the asset inventory. Procurement, CASB, and SSO are the three sieves, and between them they catch most of what matters. Shadow MCP defeats all three by construction. The artifact is not a vendor — it is a Python process on a laptop. The traffic is not egress to a SaaS endpoint — it is a JSON-RPC call to localhost. The credential is not a new SSO grant — it is the engineer's existing prod-readonly token, the same one they use from a Jupyter notebook, now repurposed as the auth for a long-running agent loop. There is nothing for finance to discover, nothing for the CASB to inspect, nothing for the SSO logs to record beyond the original token issuance that was approved years ago for a different purpose entirely.

The Artifact Is a Loopback Socket, Not a Vendor

Shadow MCP servers do not look like applications in the asset-management sense. They are short scripts, often vibe-coded in an afternoon, started by a developer's IDE plugin or a pipx invocation, and bound to a high port on the loopback interface. They expose tools the LLM can call, and those tools fan out to whatever the developer's machine can reach — internal APIs, production databases, Slack workspaces, GitHub repos, the corporate VPN. EDR doesn't flag them because they're not malware. MDM doesn't catalog them because they're not installed software in the registry sense. The CASB doesn't see them because the egress is to internal CIDR ranges, not to a vendor's public IP.

The visibility surface that actually exists is narrow and underused. Endpoint telemetry can list every process bound to a TCP socket, including loopback, and that list is the closest thing to ground truth for what MCP servers are running on a corporate fleet. Network egress monitoring on developer hosts — not on the corporate edge, where the traffic is normal-looking VPN traffic, but on the host itself — can detect the unusual cadence of an agent loop calling the same internal API every thirty seconds for hours on end. Neither of these is a heavy lift technically, and neither is happening at most companies because the threat model the security team is running was last updated for SaaS shadow IT, where the answer was "scan the credit-card statements."

Credential Reuse Is the Default, and It's the Problem

Every shadow MCP server runs on credentials someone already has. That's not an accident — it's the entire reason the developer chose MCP over building a service. The whole point is that they don't have to file a ticket for a new credential. They take the prod-readonly database token they were issued for ad-hoc analysis, paste it into a config file the LLM client reads on startup, and now the same token is being used by an agent loop that issues thirty queries a minute, every minute, for as long as the laptop is open. The audit trail that was perfectly readable when the token was used by a notebook session — one query every few minutes, with the engineer at the keyboard — is now noise. The forensic question "what queries did this user run on the day the customer-data leak was reported" goes from a few-row SQL filter to a million-row haystack with no signal.

This is not a hypothetical. The OWASP MCP Top 10 (MCP09:2025) lists shadow servers as a distinct category specifically because the credential-reuse failure mode is consistent across deployments. Two-thirds of open-source MCP servers ship with security practices the OWASP project rates as "poor" — flaws in OAuth flows in roughly 43% of them, command injection vulnerabilities in another 43%. Even the well-built ones inherit whatever permissions the credential has. The token doesn't know it's being used by an agent. The downstream API doesn't know it's being called in a loop. The only place the new usage pattern is legible is on the laptop where the MCP server is running, which is the one place nobody is looking.

Confused-Deputy Bridges Don't Look Like Exfiltration

The data-exfiltration risk in shadow MCP isn't the obvious one. Nobody is going to upload the customer table to Pastebin from a corporate laptop — that would trip every DLP rule in the building. The risk is the confused-deputy bridge: an LLM with one tool that reads from prod and another tool that writes to a personal Notion, a personal email, a personal GitHub gist. Neither tool is malicious. Neither call, in isolation, is anomalous. But the composition is a one-way pipe from production data to the engineer's personal cloud, and no DLP rule will catch it because the egress destination is whatever Notion's IP range happens to be that day, which is also where the engineer legitimately writes their meeting notes.

Loading…