Shadow IT used to require a purchase order. Adding an MCP server requires editing a JSON file and restarting a client. No approval, no procurement, no security review, and no record anywhere that a security team would look.
The result is predictable: in any organization where developers use agentic tooling, MCP servers are running that nobody has assessed. Some are official servers from reputable vendors. Some are community packages with two contributors and no release signing. Some are internal experiments that a developer wrote and forgot. All of them hold credentials and mediate access to real systems.
Why This Matters More Than Ordinary Shadow IT
Credential access. An MCP server holds credentials for whatever it fronts — a database, a SaaS API, a cloud account. Adding a server usually means minting a credential and pasting it into a configuration file, so shadow MCP servers come with shadow credentials that no inventory records. See NHI credential lifecycle management.
Supply chain exposure. Servers are installed as packages, often executed via a package runner directly from a registry, at whatever version resolves at that moment. The install runs arbitrary code on a developer machine with access to their credentials. Typosquatting and dependency confusion apply directly. See MCP server vetting and registry risk and securing the agent supply chain.
Data egress. A remote MCP server receives whatever the agent sends it — file contents, database rows, prompt context. That is a data flow to a third party with no data processing agreement and no residency guarantee. For regulated data it is a compliance finding before it is a security one. See data residency for AI agents.
Unaudited tool surface. The agent's action inventory now includes tools nobody enumerated. Whatever your governance says about what agents can do, it is inaccurate.
Prompt injection reach. A server's tool descriptions enter the model's context, and tool responses come back into it. A malicious or compromised server can inject instructions directly into the agent's reasoning — a path that requires no user interaction at all. See threat model: indirect prompt injection.
Four Detection Angles
No single method finds everything. Run several.
1. Client configuration files. MCP clients store server definitions in known locations — per-user config files for desktop clients, project-level files in repositories, IDE settings. On managed endpoints, an inventory agent can collect and report these. In repositories, a scheduled scan for MCP configuration files finds project-scoped servers, and because the config names the command and arguments, it also tells you the package and often the credential environment variables. This is the highest-yield method and the cheapest to implement.
2. Process and container inventory. Locally-run servers appear as child processes of the client, typically launched through a package runner or an interpreter. Endpoint tooling that already inventories processes can pattern-match these. In container environments, look for sidecars and images that were not deployed through your pipeline.
3. Network egress. Remote MCP servers are HTTP endpoints. Egress logs from developer networks and agent runtimes show connections to them, and destinations that are not in your known-services list are candidates. This is the only method that catches servers configured on unmanaged devices, and it is also the method that finds data leaving. Where you have a forward proxy, this becomes straightforward. See SSRF risks in agent tool calls for the egress control side.
4. Telemetry from agent runtimes. If your agents emit traces, tool calls appear as spans with the server and tool name attached. Ingesting that telemetry gives you the tool surface as actually exercised, which is better than configuration alone because it shows what is used rather than what is available. This is also how you find agents you did not know about at all. See OTLP telemetry ingest for agent discovery.
Combine the four and reconcile: a server in a config file that never appears in telemetry is probably unused and can be removed; a server appearing in egress logs but in no config file is on an unmanaged device and needs a conversation.
Assessing What You Find
Triage on impact rather than treating every finding equally.
- What credentials does it hold, and what can they reach? A server fronting a read-only public API is a different problem from one holding a production database credential.
- Local or remote? Remote means data leaves. Local means code runs on an endpoint with a developer's full access.
- Where does the code come from? Vendor-published with signed releases, a well-maintained community project, or an unmaintained package with one contributor. Check whether the installed version is pinned.
- What tools does it expose, and are any state-changing? Read-only servers are a data-egress question. Servers with write, delete, or send capability are an action-authority question.
- Who added it and is it still needed? Half of what you find will be abandoned experiments, and removal is easier than governance.
The output should be a decision per server: adopt into governance, replace with a vetted equivalent, or remove.
Making the Governed Path the Easy Path
Blocking alone fails. Developers added these servers because they made work possible, and a prohibition without an alternative produces workarounds on unmanaged devices where you have no visibility at all.
What works is reducing friction on the governed path below the friction of the ungoverned one:
An internal registry of vetted servers. Pre-assessed, version-pinned, with credentials provisioned through your normal mechanism rather than pasted by hand. A developer picks from a catalog instead of searching a public registry. Fast, and the security review has already happened. See registering and governing MCP servers and MCP server registry: publishing and ratings.
A fast vetting path for new requests. Days, not weeks. A slow review process is functionally the same as a prohibition. Automate what can be automated: package provenance, signature verification, dependency scan, tool inventory extraction, and a diff against the previously approved version.
Credentials that come from the platform. If getting a credential through the governed path is easier than minting one manually, developers will use it — and you get the inventory as a byproduct.
A proxy the servers sit behind. Route MCP traffic through a gateway that enumerates tools, applies per-tool authorization, evaluates guardrails, and records every call. Then governance is a property of the path rather than of developer discipline. See MCP gateway: what to look for and scoping MCP tool permissions.
Egress control as the backstop. Allow-list MCP destinations at the network layer. This is what keeps the ungoverned path from being available on managed networks, and it should come after the governed path exists — not before.
Common questions
Should we block MCP entirely until we have governance in place?
Rarely the right call. MCP is how agentic tooling integrates with real systems, and blocking it pushes work to personal devices and personal accounts, where you have neither visibility nor control. Do detection first so you know the current state, stand up a small vetted catalog covering the common cases, then restrict — in that order.
How do we handle developers running servers on personal machines?
You largely cannot detect these directly, which makes it a policy and access question rather than a detection one. What you can control is what those servers can reach: if production credentials are only obtainable through the governed path and are short-lived and source-restricted, a server on an unmanaged laptop has nothing valuable to hold. Constrain the credential, not the laptop.
Is a locally-run MCP server safer than a remote one?
Different, not safer. Local means no data egress to a third party, which is a real advantage for sensitive data. It also means arbitrary code from a package registry executing on a machine that holds a developer's credentials, SSH keys, and cloud sessions — a larger compromise surface than an API call to a remote endpoint. Remote servers concentrate the data risk; local servers concentrate the code-execution risk. Assess both accordingly.
What about MCP servers our vendors run as part of their product?
Treat them as third-party integrations subject to your normal vendor process: data processing terms, residency, subprocessor disclosure, incident notification. The MCP framing does not change the assessment; it just means the integration was added by a developer rather than by procurement. Bringing these into the same review as any other data-sharing integration is usually the fastest way to get organizational alignment on why this matters.
How Praesidia approaches MCP visibility and control
Praesidia maintains a registry of MCP servers with per-server registration and per-tool authorization, so an agent's grant enumerates individual tools rather than inheriting a server's whole catalog. Traffic passes through a governed connection where guardrails evaluate both directions and every tool call is recorded with attribution, latency, and cost.
Discovery ingests telemetry from agent runtimes and surfaces observed agents and servers that were never formally registered, and discovered entities can be adopted into governance rather than only reported. Credentials for registered servers are held at the proxy and attached after policy evaluation, which is what makes the governed path lower-friction than pasting a key into a config file. See MCP server security checklist and the Praesidia documentation.