ShadowMCP
SHADOW MCP / DISCOVERY & INVENTORY

Find the MCP you didn’t approve.

An approved MCP catalog only tells you what somebody recorded. Discovery asks a harder question: what MCP evidence is actually present across repositories, projects, supported client configurations and — where separate telemetry exists — runtime platforms?

Reviewed · 14 Sep 2026MCP spec · 2026-07-28Bounded evidence · no absence proof

1. What “shadow MCP” means here

Shadow MCP is security-industry shorthand for MCP server usage, connection evidence or configuration that exists outside the organization’s expected inventory, review or approval process. It is not a formal MCP protocol verdict, and it does not mean a server is malicious.

The governance problem is visibility: a server can be legitimate software and still be unmanaged because nobody responsible for security or platform governance knows it is configured or being used.

Evidence boundary

“Not observed” means only that a bounded discovery method did not see evidence in the surfaces it inspected. It does not prove that MCP is absent elsewhere.

2. Why the approved list is not the inventory

An allowlist, CMDB entry or internal catalog is a record of intent. Discovery is a measurement of evidence. Those two sets can diverge when developers add project-level configuration, users connect a client locally, repositories introduce new MCP setup, or agent platforms establish connections outside the review path.

KNOWN

Approved inventory

What the organization expects to exist and has reviewed structurally.

OBSERVED

Discovered evidence

What bounded repository, project or client inspection actually finds.

DELTA

Review gap

New, changed or unapproved evidence that needs attribution and human review.

UNKNOWN

Unobserved surfaces

Runtime, platform, network or unsupported-client activity outside the current evidence boundary.

3. Use layered discovery — no single surface is complete

Useful MCP discovery separates evidence layers instead of pretending one scan can see everything.

  1. Repository and supply-chain evidence: public code can reveal MCP files, setup instructions, install behavior, automation and dependency context before execution.
  2. Project configuration: project-root MCP files can show connections intended for a specific workspace or codebase.
  3. Supported client configuration: bounded client-specific configuration locations can reveal locally configured servers when discovery is explicitly enabled.
  4. Runtime / platform / network observation: separate telemetry can reveal active connections or tools that static files do not expose. This is a distinct capability layer, not something a config scan should imply.

The practical goal is not “scan once.” It is to know which evidence layer produced each observation and which layers remain outside scope.

4. MCP `server/discover` is not enterprise discovery

The 2026-07-28 MCP specification introduced an optional server/discover RPC so a client can learn a server’s capabilities up front. That is protocol-level capability discovery for a server the client is already addressing.

Security discovery asks a different question: which MCP servers, configurations or connections exist across the environment in the first place? Do not confuse the protocol RPC with inventory discovery across repositories, devices, projects or agent platforms.

5. What ShadowMCP can discover today

ShadowMCP currently uses bounded, structural evidence rather than executing target MCP servers. The useful outcome is provenance and review context without turning discovery itself into code execution.

  • Public repository evidence: selected files and bounded repository metadata can surface MCP/configuration signals, command/install markers, automation and dependency context without cloning or running target code.
  • Project MCP configuration: the CLI can inspect supported project-root MCP configuration files and report structural evidence.
  • Verified client configuration: opt-in client discovery checks documented, bounded locations for supported clients rather than recursively searching the machine.
  • Privacy-safe structure: reports minimize sensitive values, credentials and full local paths.
  • Approval lifecycle: structural baselines, review states, drift and CI gating help compare what is observed now with what was previously reviewed.
Check a public repository ↗

6. What a bounded static/config scan does not prove

Discovery quality depends on the surfaces observed. ShadowMCP should not convert a blind spot into a reassuring conclusion.

  • A server may be configured in an unsupported client or location outside the bounded paths.
  • A runtime platform may create or broker MCP connections without leaving evidence in the inspected local files.
  • A repository can change after inspection.
  • A server’s runtime behavior and exposed tools can differ from what static source/config evidence suggests.
  • An approved structural match is not a safety verdict and does not eliminate the need for runtime controls.
Do not collapse the layers

Static/config discovery, runtime observation, authorization, behavioral monitoring and enforcement are complementary controls. One should not be marketed as a substitute for the others.

7. Turn discovery into a governance workflow

Discovery only becomes operationally useful when every observation has provenance and a next step.

  1. Discover: collect bounded structural evidence from supported surfaces.
  2. Attribute: record source type, client/project context and safe structural identity.
  3. Inventory: normalize duplicate observations into a reviewable set.
  4. Review: inspect provenance, permissions, transport, command/package identity and tool behavior.
  5. Approve: accept the reviewed structural state — not “safe forever.”
  6. Detect drift: surface new, removed or materially changed structure.
  7. Gate where needed: use CI/policy stops when an unapproved or review-required current server should block a workflow.

For the wider control model, read the approval and drift section of the MCP security guide.

8. Common discovery blind spots

BLIND SPOT 01

Catalog-only thinking

Assuming the approved list is complete without measuring actual configuration evidence.

BLIND SPOT 02

Recursive machine search

Trading privacy and signal quality for a broad crawl instead of using verified, bounded discovery paths.

BLIND SPOT 03

Static = runtime

Assuming a config file proves an active connection — or that no config file proves no runtime connection.

BLIND SPOT 04

Approval inheritance

Letting later structural changes inherit an old approval without re-review.

9. Shadow MCP discovery checklist

  • Scope: Which repositories, projects, clients and platforms are actually being observed?
  • Provenance: Can every observation be traced to a specific evidence source?
  • Boundary: Does the report clearly state which surfaces were not inspected?
  • Inventory: Are duplicate observations normalized without losing provenance?
  • Approval: Is “approved” defined as a reviewed structural match rather than a safety guarantee?
  • Drift: Will new or materially changed MCP structure trigger review?
  • Privacy: Are token values, secrets and unnecessary local path details excluded?
  • Execution: Can evidence be collected without running untrusted MCP server code?
  • Runtime gap: If active-connection visibility matters, is separate runtime/platform/network telemetry available?

After discovery, use the MCP Server Security Checklist to review a server before deployment or approval.

Sources and terminology

This page is an independent ShadowMCP synthesis. Protocol claims come from the official MCP project. “Shadow MCP” terminology and runtime-discovery framing are also used in vendor security research; those sources are listed separately and are not treated as protocol authority.

Authoritative MCP sources

Industry terminology / operational framing