The MCP adoption curve nobody planned for
The Model Context Protocol landed quietly. Anthropic published the spec in late 2024. By early 2025, Claude Code shipped with native MCP support. Within months, developers at large organizations were connecting AI coding assistants to internal databases, CI/CD pipelines, and cloud consoles through locally hosted MCP servers. None of this required a procurement cycle. No software was purchased. A developer with a JSON config file and a few minutes could give their AI assistant direct tool access to production systems, and in most environments, no existing control would surface that it had happened. This is the shadow MCP problem, and it is not theoretical.
In Outerlimit’s customer conversations this year, security leaders at large enterprises have described exactly this scenario: developers spinning up local MCP servers on their devices that are invisible to existing network monitoring. One security architect told us plainly that even with proxy infrastructure and endpoint monitoring in place, there was no confidence that all MCP-related traffic was being captured. The concern isn't that developers are acting maliciously. It's that they're acting rationally, connecting powerful tools to useful data, in a way that creates ungoverned access paths your security team cannot see.
What a shadow MCPserver actually looks like
An MCP server is a lightweight process that exposes tools over a standardized protocol. In Claude Code, a developer adds a server definition to their local configuration. The server starts when the AI session starts. It might expose tools that query a database, call an internal API, read from a file system, or execute shell commands.
Here's what makes the local variety different from traditional shadow IT:
• No installable binary. The server is often a script, a few dozen lines of Python or TypeScript. It doesn't appear in software inventories or endpoint management consoles.
• No persistent network connection. A local MCP server runs over stdio or localhost HTTP. There's no long-lived outbound connection for a firewall to flag.
• No distinct process signature. The server runs as a child process of the AI tool. In a default endpoint configuration, it looks like normal developer activity: node or python running inside a terminal session.
• No central registry. Unlike a SaaS application with a login page, there's no OAuth flow, no DNS lookup to a known domain, no certificate to inspect.
The result: a developer can grant an AI assistant tool-level access to internal systems through a local server that no layer of a typical security stack will flag on its own.
Why nothing alerts, even though the signals are there
Security teams have spent years building visibility through layered controls: endpoint detection, network proxies, CASB, cloud access logs. These tools are effective for the threats they were designed to detect, which are installed software, network-level data flows, and SaaS authentication events.
Local shadow MCP servers don't match those patterns:
• Endpoint detection (EDR/XDR): in a default configuration, a python or node process spawning under an AI tool carries no malicious signature and no known-bad hash. Tuned rules can flag anomalous child-process trees, but nothing ships that way out of the box.
• Network proxies: MCP over stdio never touches the network, and localhost HTTP doesn't traverse the proxy. Remote MCP servers are different: an external HTTPS or SSE endpoint does leave egress traces your proxy and DNS logs can see. What those traces don't tell you is which agent connected, which tools the server exposed, or which developer wired it up.
• CASB/DLP: no SaaS authentication event to intercept, no file upload to a known cloud service. The data moves between local processes, or to internal endpoints the developer already has access to.
• Cloud access logs: if the MCP server calls an internal API using the developer's existing credentials, the log shows a normal authenticated request. Nothing distinguishes it from the developer making the same call by hand.
Here is the part most miss: this is an alerting gap, not a data gap. On covered endpoints, your EDR already records the process activity that describes a local MCP server: the AI tool spawning a child process, the command line that launched it, the user who ran it. That context is what separates an MCP server from ordinary developer noise, and it is context your EDR records but was never built to interpret. Nothing in a conventional stack reads a node child of an AI tool as "an MCP server exposing shell access to an agent." The signals exist. The interpretation is missing. Shadow MCP is an AI orchestration problem, and it needs a layer that reads orchestration signals as what they are, not another sensor.
Layered discovery: read the EDR you have, enrol where it pays
Outerlimit approaches shadow MCP discovery in two layers, and the first one requires deploying no new software to workstations.
Layer one: read the EDR you already run. Outerlimit's discovery connectors ingest MCP invocation data from EDR telemetry, with read-only connectors for Microsoft Defender and CrowdStrike Falcon NG-SIEM shipping today. The connectors read telemetry your EDR platform already collects, subject to its licensing tier, and the portal diffs what they find against your approved inventory, so unapproved servers surface. The result is a map of where MCP activity is happening on covered endpoints: which machines, and which users are launching MCP servers locally. Coverage is as broad as your EDR coverage, including the gaps you already track.
Layer two: enroll where it matters. The EDR layer gives you breadth. Session-level telemetry gives you depth: Outerlimit's Claude Code connector and generic OpenTelemetry connectors ingest session metadata over OpenTelemetry from workstations you enroll. Enrollment is a configuration push through the device management you already run, not an agent install. Unenrolled machines are covered by the EDR layer's map, not by session telemetry, and enrolment coverage itself becomes a metric you track.
For each session on an enrolled workstation, the Claude Code connector surfaces:
• Who: the authenticated user identity tied to the session.
• Which machine: the device where the session ran.
• Which session: a unique identifier linking all activity within one interaction.
• Which tools: the MCP servers connected and the specific tools they exposed, including servers that appear in no approved inventory.
This per-user, per-session attribution is the critical piece. It's not enough to know that shadow MCP servers exist somewhere in your estate. You need to know which developer, on which machine, connected which unapproved server, in which session, so you can have a conversation rather than just raise an alert. That conversation is an employment-relevant use of monitoring data, so access to attributed records is something you restrict by role, with retention you configure, in the regional deployment (UK, EU, or US) your obligations require.
Both layers are metadata-only by default: structural facts about what connected and what was exposed. It never collects prompt content, generated code or agent output. Capturing sensitive content is a separate, customer-controlled setting, and it ships off. Attributed usage is still personal data; you control the lawful basis, who sees it, and how long it is kept. Governance-first, not surveillance-first, and designed so your DPO or works council can verify the boundary rather than take it on trust.
From blind spot to governed: the discovery-to-enforcement pipeline
Discovery is the starting point, not the destination. Knowing that shadow MCP servers exist tells you the shape of the problem. Governing them is a pipeline:
Stage 1: Inventory. Continuous discovery surfaces MCP activity from both layers: EDR-sourced invocation data across covered endpoints, and session telemetry from enrolled workstations, approved and unapproved alike, with attribution. You now know what exists, where it concentrates, and how much of the estate each layer covers.
Stage 2: Classification. Security teams review discovered servers against policy. Some are sanctioned and should be governed. Some are experimental and should be monitored. Some are unacceptable and should go.
Stage 3: Enforcement. Approved MCP traffic routes through governed paths: MCP gateways, proxies, or sidecar integration patterns that evaluate every call against policy before execution. Anything not flowing through the governed path is identifiable as unapproved by definition; the Discovery layers and your own network controls surface the bypass, and your EDR, XDR, and SOAR processes can act on what Outerlimit detects.
Stage 4: Continuous monitoring. New servers appear as developers adopt new tools. The EDR layer picks up new MCP activity on covered endpoints wherever it starts; the session layer catches detail on enrolled machines at the next collection run; the cycle repeats.
This pipeline doesn't require modifying the MCP servers themselves, and routing an approved tool through the governed path is one endpoint URL in each client's MCP configuration: no plugins, no forks. It also doesn't require capturing the content of what developers are building. Structural metadata about how AI tools connect to your systems is enough.
The window is now
MCP adoption is accelerating. Every major AI tool vendor is adopting or evaluating the protocol, the catalog of open-source and custom servers grows weekly, and every developer with an AI coding tool can create a new one in minutes. Our coverage today is two layers deep: EDR-sourced MCP invocation data gives breadth on covered endpoints, and process-level signals aren't tied to any one coding tool – anything that emits OpenTelemetry can be integrated.
The gap between MCP adoption and MCP governance is widening. The organizations that close it first will be the ones that treated discovery as a prerequisite for enforcement rather than an afterthought.
If your security team can't answer the question "which MCP servers are connected to AI tools in our environment, and who connected them," you have a blind spot, and the first layer of the answer is already sitting in your EDR telemetry. It's not a future risk. It's a current one.
Book a discovery demo: we'll start from the EDR you already run and show you where your MCP activity actually is.
Microsoft and Microsoft Defender are trademarks of Microsoft Corporation. CrowdStrike and Falcon are trademarks of CrowdStrike Inc. Use does not imply affiliation or endorsement.
