Implementation Guide

How to Detect Shadow Model Context Protocol Servers in Enterprise Environments

A practitioner guide to finding unauthorized MCP servers with network, host, and identity-layer signals, then connecting those findings to asset inventory and governance.

Explore MCP Security Talk to an Expert
Detect shadow MCP servers by combining network-level scanning for HTTP services exhibiting JSON-RPC 2.0 patterns with host-level process and configuration file enumeration for stdio-based servers. Verify agent identity and OAuth 2.1 authorization where implemented, then feed findings into existing CMDB and asset inventory systems with MCP-specific metadata, reconciling discovered servers against an approved-server registry to separate sanctioned deployments from unauthorized ones.

MCP Detection at a Glance

Discovery surfaces

Network scanning, host and process enumeration, and configuration file audits.

Key signal

Presence of OAuth 2.1 authorization and validation against an approved identity provider.

Governance outcome

Reconciled inventory feeding ongoing policy enforcement and remediation.

Local vs. Remote MCP Servers: Two Detection Surfaces

MCP servers appear in two primary forms. Each form creates a different visibility gap, so detection must cover both surfaces rather than relying on network scanning alone.

  1. Local (stdio) servers

    Run as child processes spawned by a host application. Visible primarily through process enumeration and configuration file review, since there is no listening network service to scan.

  2. Remote (HTTP) servers

    Exposed over Streamable HTTP transport and reachable as network services. Identifiable through port and service scanning combined with traffic analysis for JSON-RPC 2.0 message patterns, since MCP does not mandate a fixed port.

  3. Authorization posture

    HTTP-based servers may implement MCP's OAuth 2.1-based authorization framework. Its presence, and whether tokens trace to an approved identity provider, is a candidate signal for separating policy-governed connections from ad hoc ones.

  4. Capability exposure

    Once a server is found, the resources, tools, and prompts it negotiates with clients describe what data or systems it can reach, which is necessary context for risk classification.

What Is a Shadow MCP Server

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic, that defines how AI models and agents connect to external tools and data through a client-host-server architecture. A host application, such as an agent runtime or IDE plugin, manages one or more clients, each connecting to a separate MCP server. Servers expose functionality to clients through three core primitives: resources, tools, and prompts. Communication between clients and servers uses JSON-RPC 2.0.

A shadow MCP server is any server instance running in the enterprise that has not been registered with security or platform teams, is not accounted for in asset inventory, and has not been evaluated against organizational policy for authorization, data access, or tool exposure. It may be a stdio-based process a developer launched from a local configuration file, or a remote HTTP endpoint a team stood up to expose internal APIs to an AI agent. The defining characteristic is not how it was built, but that it operates outside governance visibility.

Why Shadow MCP Servers Proliferate

MCP servers are easy to create. Local servers can be configured and launched through client configuration files that reference an executable command or script, requiring no central provisioning step. A developer testing an integration between an LLM and an internal database or ticketing system can have a working MCP server running in minutes, entirely on a workstation.

This ease of deployment, combined with decentralized AI experimentation across product, engineering, and data teams, produces the same dynamics that drove earlier shadow IT and shadow SaaS problems. Unlike a new SaaS subscription, however, an MCP server can grant an AI agent direct, programmatic access to internal tools and data through the resources, tools, and prompts it exposes. Because a single host application can connect to multiple servers simultaneously, each new integration multiplies the number of discrete endpoints and processes a security team must eventually account for.

Detection Techniques Across Network, Host, and Identity Layers

Effective detection layers complementary signals instead of treating MCP as a single scan target:

  • Network layer: Scan for HTTP services and inspect traffic for JSON-RPC 2.0 patterns consistent with MCP's Streamable HTTP transport. Because MCP does not require a fixed port, signature and behavior matter more than port alone.
  • Host layer: Enumerate processes and review host-application configuration files to find stdio-based servers that never open a listening port.
  • Identity layer: Where OAuth 2.1 is implemented, verify whether authorization tokens trace to an approved identity provider and whether the connecting agent identity is known and expected.

Practical note

Treat each discovered host application as a discovery entry point. Its configuration often reveals every server it connects to, including short-lived local integrations that network scans will miss.

Extending Asset Inventory to Track MCP Servers

Discovery only creates lasting value when findings land in systems operators already use. Extend existing inventory rather than standing up a parallel MCP catalog.

  • Add MCP-specific fields (host application, transport type, exposed capabilities, authorization method) to existing CMDB schemas rather than building a siloed MCP inventory.
  • Treat each discovered host application as a discovery entry point, since its configuration reveals every server it connects to.
  • Record whether a server proxies or wraps access to internal APIs, since its own network footprint may not reflect the full scope of systems it can reach.
  • Reconcile newly discovered servers against an approved-server registry to classify findings as managed or shadow.
  • Repeat discovery on a recurring basis rather than as a one-time audit, since MCP servers can be started and torn down quickly through local configuration.

From Detection to Governance

Once servers are visible, move findings through a defined governance path:

  • Define what constitutes a sanctioned MCP server (approved host application, registered endpoint, validated authorization method) before classifying detection findings as managed or shadow.
  • Route confirmed shadow servers through a remediation workflow that includes registration, decommissioning, or a documented policy exception, not just an alert.
  • Apply least-privilege principles to newly registered servers, limiting exposed tools and resources to what the connecting agent identity actually requires.
  • Maintain audit logging of agent-to-server tool calls for servers brought under management, to support ongoing policy enforcement.
  • Where runtime governance controls are in place, use them to enforce agent identity verification and tool approval workflows on discovered MCP connections as part of a broader detection-to-remediation cycle.

Bring Discovered MCP Servers Under Runtime Governance

Detection is the first step. Once shadow MCP servers are found, ongoing governance requires agent identity verification, tool approval workflows, and audit logging applied consistently across managed and newly discovered servers.

Explore MCP Security