Shadow MCP servers are the unsanctioned Model Context Protocol endpoints your AI agents connect to without security review or approval. To discover shadow MCP servers, you inspect egress logs for outbound connections to MCP transports (SSE, streamable HTTP, WebSocket) that do not appear on your approved allowlist, then gate or block them at the proxy. This is where Agent G lives: on the wire.
Why Shadow MCP Servers Are a Discovery Problem, Not Just a Policy Problem
MCP made it trivially easy to bolt new tools onto an agent. A developer adds a server URL to a config file, a framework auto-loads a registry, or a third party MCP server gets referenced in a prompt. None of that touches your change management process. The result is shadow MCP: servers your agents call that no one on the security team knows exist.
The problem compounds because MCP servers are action surfaces, not passive APIs. A single MCP tool call can read files, hit internal services, or push data to a remote host. If you cannot enumerate which servers your agents talk to, you cannot reason about blast radius, data flow, or compliance scope. Static config review misses runtime additions, dynamically resolved endpoints, and servers introduced through dependency chains you never audited.
How to Discover MCP Servers From Egress Logs
The reliable signal is the network. Every MCP session, regardless of framework, produces outbound connections with recognizable shapes. Rather than trust an inventory someone typed into a spreadsheet, you reconstruct the real inventory from what actually left the box.
Unsanctioned MCP Discovery: What to Look For on the Wire
- Transport fingerprints: MCP over SSE shows long-lived connections with
text/event-streamcontent types. Streamable HTTP shows POST requests carrying JSON-RPC 2.0 envelopes withmethodfields liketools/list,tools/call, andinitialize. - Handshake methods: The
initializerequest and thenotifications/initializedfollow-up are dead giveaways that a connection is an MCP session and not generic API traffic. - Destination anomalies: Any host receiving
tools/calltraffic that is not in your approved MCP registry is, by definition, shadow MCP. - Off-hours and looping behavior: Repeated
tools/listpolling to a novel domain often indicates an agent auto-discovering a newly configured server.
A Five Step Discovery Workflow
- Capture egress at a chokepoint. Route all agent outbound traffic through a single inspecting proxy so no session bypasses observation. Sidecar or namespace-level routing beats per-app instrumentation.
- Decrypt and parse. Terminate TLS at the proxy so you can read JSON-RPC bodies, not just SNI hostnames. Extract
method, target host, and tool names. - Classify MCP sessions. Tag any flow containing MCP handshake or
tools/*methods as an MCP session and record the destination. - Diff against the approved registry. Subtract known, sanctioned servers. Everything left is shadow MCP and needs owner attribution.
- Gate, then approve or block. Move to default deny so new servers cannot be reached until reviewed, converting discovery into ongoing enforcement.
Passive Discovery vs Inline Gating
Log analysis alone tells you what happened yesterday. Inline gating decides what happens next. The difference matters when a shadow MCP server is exfiltrating data right now.
| Capability | Passive log analysis | Inline proxy gating (Agent G) |
|---|---|---|
| Surfaces unknown MCP servers | Yes, after the fact | Yes, in real time |
| Reads tool arguments | Only if bodies were captured | Yes, on every call |
| Blocks a new server before first call | No | Yes, default deny |
| Requires human approval for new destinations | No | Yes, HITL gate |
| Produces audit evidence per action | Partial | Yes, signed action receipts |
Discover Shadow MCP Servers, Then Gate Them at the Proxy
Discovery is the first half of the job. The reason egress logs are the right lens is that Agent G already sits at that boundary as an inspecting proxy. When you discover shadow MCP servers through Agent G, the same component that surfaced them can enforce on them. A newly seen MCP host does not silently join your agent's tool surface. It hits a default deny policy, gets flagged for review, and can be escalated to a human before the agent completes a single tools/call.
Concretely, Agent G maps each MCP session to an agent identity, records the destination and tool name, and applies policy as code. Unknown server plus sensitive tool equals block or escalate. Known server plus expected argument shape equals allow with a receipt. Because inspection happens on the wire, servers introduced through dependency chains, prompt injection, or a rogue config edit all funnel through the same enforcement point. There is no code path an agent can take to a shadow MCP server that the proxy does not see.
Attributing and Retiring Shadow Servers
Once discovered, each shadow MCP server needs a decision. Assign an owner using the agent identity and workload metadata on the flow. Ask three questions: Is this server necessary? Is it trustworthy? Does it need the scope it is using? Servers that survive review get added to the allowlist with tight tool-level and argument-level policy. Servers that do not get blocked permanently, and the block itself becomes a detection signal if the agent keeps trying to reach them.
This is also where you catch the subtler failure modes: an approved server whose tool descriptions later change, or a server that quietly repoints to a new backend. Continuous egress inspection means the inventory stays live rather than decaying the moment you finish the audit.
Frequently Asked Questions
What exactly is a shadow MCP server?
A shadow MCP server is any Model Context Protocol endpoint your agents connect to that was never reviewed, approved, or inventoried by your security team. It typically enters through config edits, framework auto-loading, or third party references, and it expands your agent's action surface without oversight.
Can I find shadow MCP servers without decrypting traffic?
You can detect that MCP-shaped connections exist from SNI hostnames and connection patterns, but you cannot read tool names or arguments without terminating TLS at an inspecting proxy. Full attribution and enforcement require reading the JSON-RPC bodies, which means inline decryption at the egress boundary.
How is this different from an MCP gateway?
Many MCP gateways route and authenticate calls but do not inspect arguments or block traffic to servers outside their own registry. Agent G inspects every outbound MCP call on the wire, applies default deny to unknown destinations, and gates risky tools with human approval, closing the discovery-to-enforcement gap.
Does gating shadow MCP break legitimate agents?
No, if you roll out in observe mode first. Discover and inventory MCP sessions, approve the servers your agents genuinely need, then flip to default deny. Legitimate traffic stays allowlisted while new, unreviewed servers are held for approval instead of silently connecting.
For deeper implementation detail, see our guides on securing self-hosted MCP servers, deep tool-argument inspection, and preventing MCP tool poisoning. You can also compare approaches on our alternatives page or explore the MCP gateway capability directly.
Shadow MCP is a discovery problem that only stays solved with enforcement. If you want to discover shadow MCP servers from egress logs and gate them at the proxy in one pass, request access to the Agent G private beta and put every agent MCP call under inspection.