Shadow MCP Servers

What Is Shadow MCP Servers?

An MCP server spun up for a quick experiment tends to keep running long after anyone remembers it, often on default credentials and bound wider than intended. Your client's configuration will not tell you it exists, because that list only shows what someone deliberately added. You'll chase unexplained traffic, run a discovery scan, and find three servers nobody registered. You'll compare the scan against the list in both directions, then triage each server and enforce an allowlist at the gateway so an unapproved one is blocked for every team.

What You'll Learn in Shadow MCP Servers

• Recognize a shadow MCP server: one that is running and reachable but was never registered through the organization's own approval process
• Explain why a client's own registered-server list (e.g. claude mcp list) only shows what was deliberately added, and why continuous discovery is needed to find what else is actually listening
• Read a discovery scan's findings for concrete risk signals: default credentials still active, no owner on record, or a network bind wider than localhost
• Recognize that a discovery tool's own blind spots (such as a localhost scan missing a legitimate remote server) are a reason to combine discovery with an enforced allowlist, not to distrust the scan
• Enforce an allowlist at a central gateway rather than relying on a single client's local block, so an unapproved server is contained for every team it could otherwise reach

Shadow MCP Servers — Training Steps

1. A Question from the Platform Channel

   Alice owns MCP governance at Sarnholt Systems. Keeping the approved server inventory honest, catching anything that started running without going through it, is part of her regular week, not a special assignment. A message lands in the platform channel from Marcus Webb, one of the engineers on her team.

2. Opening WorkStream

   Alice opens WorkStream to read Marcus's message properly.

3. Marcus's Question

   The message is exactly what the toast summarized. Marcus found traffic he cannot explain, and the tool he checked with came back empty.

4. Checking the Registered List

   Before assuming Marcus's CLI is broken, Alice runs the same command herself.

5. Three Registered, All Connected

   The CLI's own view of the world comes back.

6. Scanning for What's Actually Listening

   A registered-server list only shows intent. To find out what is actually reachable, Alice needs a real discovery scan, not another read of the same CLI config.

7. What the Scan Found

   The scan results come back in two parts: what lines up with the CLI's own list, and what claude mcp list could never have shown Marcus.

8. Check: Two Different Lists

   A quick check before Alice moves on.

9. Time to Enforce It

   A terminal scan is a snapshot of what is running today. Without an enforced allowlist, tomorrow's forgotten test server will not show up in it either. Sarnholt's MCP Gateway is where that allowlist actually lives.

10. Opening the Gateway

    Server approvals and the enforced allowlist live at the gateway, not in any one engineer's terminal.