Shadow MCP servers only appear at runtime. Learn how continuous MCP server discovery surfaces unauthorized agent connections before they become a security incident.
Security teams managing AI agent deployments face a specific, compounding problem. The agents themselves are probabilistic. They make decisions at runtime based on context, instructions, and available tools. The MCP servers they connect to are not always the ones listed in a configuration file. Some connections are declared. Many are not.
One enterprise security team discovered that the number of active MCP connections in their developer environment was doubling on a quarterly basis. No central registry tracked those connections. No approval process gated them. The servers were simply there, serving tool calls, moving data, operating with whatever permissions the connecting agent had inherited.
This is the core challenge of MCP server discovery: the servers that matter most for security are the ones that were never formally registered. They are shadow MCP servers. And they only surface when an agent calls them.
Waiting for a registry lookup means waiting for a shadow server to already be in your approved list. That is not discovery. That is confirmation of what you already knew.
You cannot govern what you cannot see. And with MCP, you cannot see what you have not observed at runtime.
Shadow MCP servers do not require a sophisticated attacker to enter an enterprise environment. They enter through ordinary developer and business user behavior.
Common entry paths include:
The OWASP Low-Code/No-Code and MCP security guidance has begun formally recognizing shadow MCP servers as a top-tier risk category, alongside authentication gaps and data exposure. That recognition reflects what security teams are already experiencing: unauthorized MCP connectivity is not an edge case. It is a structural feature of how agents get built and deployed at speed.
The AI security risks introduced by shadow connections compound quickly. An agent with over-permissioned credentials connecting to an unvetted MCP server creates a blast radius that extends across every SaaS application that agent can reach. The machine insider risk is real: the agent holds tokens, makes decisions, and moves data at speeds no human reviewer can match.
These two terms appear together frequently in AI security discussions. They describe different functions, and conflating them creates a dangerous blind spot.
ConceptDefinitionWhen It HappensMCP Server DiscoveryThe act of finding MCP servers, especially shadow/unsanctioned ones, at the moment of connectionContinuously, at runtimeMCP Server InventoryThe maintained catalog of known, reviewed, and classified MCP serversOngoing, updated by discovery events
Discovery is the upstream function. Inventory is the downstream result. You cannot build an accurate MCP server inventory without continuous runtime discovery feeding it.
A static inventory built from configuration files and approved registries will always be incomplete. Shadow servers, by definition, are not in the approved registry. They appear in the inventory only after discovery surfaces them at runtime.
This distinction matters for security program design. Teams that treat inventory as the starting point are already behind. Teams that instrument discovery as a continuous runtime function build inventories that reflect what agents actually connect to, not what someone approved six months ago.
For a deeper look at building and maintaining the catalog that results from discovery, see the companion approach to AI agent governance.
Understanding why runtime discovery is the only viable approach requires understanding how MCP connections work at a technical level.
When an AI agent executes a task, it resolves its tool connections dynamically. The agent references its configuration to identify available MCP servers, then establishes connections at the moment of execution. Several things happen in that window that no pre-execution configuration review can capture:
1. The agent may call a server not listed in its static configuration. Agents operating in maker mode inherit the creator's credentials and may reach servers the creator connected to during development but never formally documented.
2. The tools available inside an MCP server are only visible at runtime. A server may advertise one set of capabilities in its manifest and expose additional tools when queried live. Static review of the server's configuration file cannot enumerate what the server actually serves.
3. Agent-to-agent communication creates secondary MCP connections. When Agent A calls Agent B, Agent B may connect to MCP servers that Agent A's configuration never referenced. The blast radius expands with each hop.
4. Shadow servers have no manifest to review. An MCP server installed from an unverified repository or auto-suggested by an IDE may have no formal documentation at all. The only way to know it exists is to observe the connection when it happens.
This is why runtime AI security is not a feature upgrade over configuration-based tools. It is a fundamentally different observation layer. Configuration shows theoretical access. Runtime shows effective authority.
Security teams relying on posture-only tools are ghost chasing: reviewing static signals about what could happen, with no evidence of what did happen, which server was called, what tools were invoked, or what data moved.
Effective MCP server discovery in 2026 requires three capabilities working together. Each one addresses a specific failure mode in traditional approaches.
Discovery cannot be a scheduled scan or a one-time assessment. Agents connect to MCP servers continuously, and new shadow servers appear every time a developer adds a dependency or a business user connects a new workflow tool.
A single pane of glass across platforms like Microsoft Copilot Studio, Salesforce Agentforce, Amazon Bedrock, Google Vertex AI, and n8n is the prerequisite. Per-platform log reviews are not sufficient. They require manual correlation, miss cross-platform agent-to-agent paths, and cannot surface connections that the platform's own logging does not capture.
Every newly discovered MCP server needs an immediate classification: is this connection sanctioned by the security team, or is it a shadow connection? That classification drives the alert priority and the remediation workflow.
Key classification signals include:
The toxic combination of a shadow MCP connection combined with an over-permissioned agent operating in maker mode represents a critical-severity finding. Individual risk factors may score medium. Together, they create the conditions for a machine insider incident.
Discovery without identity context is incomplete. Knowing that an agent connected to a shadow MCP server is useful. Knowing which user invoked that agent, which credentials the agent used, and whether those credentials exceeded the invoking user's own permissions is what transforms a log entry into an actionable security finding.
This is the effective authority problem. A user without Salesforce access invokes an agent built in maker mode by a Salesforce administrator. The agent connects to an MCP server that has Salesforce read access. The user now has effective authority over Salesforce data they were never provisioned to see. No IAM policy flagged the event. No access review caught it. The connection resolved at runtime, and without runtime observation, it is invisible.
For a structured way to surface this kind of exposure, an AI agent risk assessment walks through the mechanism platform by platform.
Discovery is the starting point, not the endpoint. Finding shadow MCP servers at runtime creates the evidence base for governance decisions. Those decisions require a structured response workflow.
The four steps from discovery to governance:
1. Surface the connection. Runtime observation identifies the MCP server at the moment of the agent's first call. The server is flagged as previously unknown.
2. Classify the risk. The discovered server is evaluated against the approved inventory, the connecting agent's permission profile, and the invoking user's identity. Toxic combinations trigger elevated priority.
3. Assign ownership. Every discovered shadow MCP server needs an owner: the team or individual responsible for reviewing, approving, or revoking the connection. The visibility gap in most enterprises is not just technical. It is organizational. Security, IT, and business unit owners often disagree on who is responsible for an agent's tool connections.
4. Update the inventory. The discovered server, now classified and owned, enters the MCP server inventory. Approved servers are cataloged with their tool capabilities, permission requirements, and review date. Shadow servers pending review are flagged for remediation.
This cycle is continuous. Probabilistic agents operating across enterprise SaaS environments will always generate new MCP connections faster than any static review process can track. Deterministic guardrails require a live, continuously updated picture of what agents are actually connecting to. That picture starts with runtime discovery.
For teams that need to understand the scope of their current shadow exposure before building a formal discovery program, shadow AI security is a practical place to begin.
MCP server discovery is the continuous, runtime process of finding MCP servers that AI agents connect to, including shadow servers that appear in no approved registry. MCP server inventory is the maintained catalog that results from discovery. Discovery is the upstream function; inventory is the downstream output. You cannot have an accurate inventory without continuous discovery.
Configuration files only capture servers that were formally declared when the agent was built. Shadow MCP servers, servers added through package dependencies, and servers connected during maker mode development often appear in no configuration file. They only become visible when an agent calls them at runtime.
A shadow MCP server is an MCP server connected to an AI agent without formal approval, inventory tracking, or security review. Industry security frameworks increasingly recognize shadow MCP servers as a top-tier risk category. These servers introduce governance gaps, unauthorized data access risks, and audit challenges.
When an agent is built in maker mode, it uses the creator's credentials for all connections, including MCP server connections. If the creator connected to an MCP server during development but never formally registered it, that server remains invisible to the approved inventory. Any user who invokes the agent gains effective authority over that server's tools, even if they have no direct access to the underlying systems.
The blast radius depends on the permissions of the connecting agent. An agent operating in maker mode with administrative credentials connecting to a shadow MCP server that has access to CRM, HR, or financial data creates a critical-severity exposure. Every SaaS application the agent can reach through that MCP connection is within the blast radius.
It must be ongoing. AI agents generate new MCP connections continuously as developers add dependencies, business users build new workflows, and agent configurations evolve. A one-time discovery assessment captures a snapshot. Only continuous runtime observation keeps the picture current.