MCP Server Inventory: Finding Every Agent Connection

Security teams already struggle with shadow AI apps and orphaned AI agents. MCP servers add a third dimension to that problem, and it is the most operationally dangerous one.

The Model Context Protocol (MCP) is an open standard that lets AI agents connect to external tools, data sources, and services through a standardized interface. An agent running inside Microsoft Copilot Studio, n8n, or Amazon Bedrock does not need a custom integration for every downstream tool. It connects to an MCP server, and that server exposes a menu of callable tools. Those tools can read files, query databases, send emails, update CRM records, or trigger infrastructure changes.

The security implication: the agent's blast radius is not defined by its configuration. It is defined by the tools the MCP server exposes at the moment the agent calls it. Configuration is not reality. The MCP server is reality.

This is what makes MCP servers categorically different from traditional API integrations. The tools inside an MCP server are only fully visible at runtime, when the agent actually connects and enumerates them. A theoretical configuration review tells you that an agent has an MCP connection. It does not tell you what that connection can actually do.

For security teams, this creates a machine insider risk that existing IAM and access review programs are not designed to catch. AI agents hold credentials. They act autonomously. They connect to MCP servers that may expose far more authority than the agent's stated purpose requires. And none of that shows up in a quarterly access review.

Agent inventories get built first because agents are visible in a platform console. The connections underneath them are the harder layer, for four structural reasons.

Local servers have no network presence. The most common deployment is a subprocess on a developer's machine communicating over standard input and output. There is no port to scan, no hostname to resolve, and no traffic to a new domain. Every network-based discovery method returns nothing.

They are added without provisioning. A developer edits a JSON config file and a new credentialed integration starts running. There is no ticket, no approval, and no record outside that file on that machine.

They are ephemeral. A server added for one task may be removed a week later, or may persist for a year. Either way the state on the day of the audit tells you little about the state today.

Their reach is inherited. The server holds whatever credential was closest to hand when someone set it up, which is usually a developer's existing personal access rather than a scoped credential created for the purpose.

The result is a layer that carries real access to production systems and that no conventional inventory method can see.

Not all MCP servers in your environment were approved by your security team. That is the starting assumption every security-conscious organization should operate from in 2026.

Sanctioned MCP servers are registered, reviewed, and approved. Security teams know what tools they expose, what authentication mechanisms they use, and which agents are authorized to connect to them. They appear in your AI agent governance framework with documented owners and review dates.

Shadow MCP servers are everything else. They include:

• MCP servers connected by developers or business users without security review
• Community-published MCP servers pulled into agent workflows from public registries
• MCP servers connected through low-code platforms where users have broad self-service capability
• Legacy MCP connections left active after a project ended (the agent equivalent of an orphaned service account)

The blast radius of a shadow MCP server is identical to a sanctioned one. An unauthenticated MCP server connection, a server exposing write access to production systems, or a server pulling data from a knowledge base containing sensitive records carries the same risk whether or not security approved it. The difference is that shadow MCP servers carry that risk with zero oversight.

One enterprise security team discovered that MCP server counts in their AI coding assistant environment were doubling on a quarterly basis. No single person had visibility into what tools those servers exposed or whether any of them were accessing sensitive repositories. That is not a theoretical configuration risk. That is an active, expanding attack surface.

The governance divide between sanctioned and shadow MCP servers cannot be managed without a complete inventory. Sanctioned and unsanctioned classification is a labeling exercise that only becomes meaningful once discovery is comprehensive. Knowing what is actually running is the starting point for AI agent security.

For each MCP server:

• Identity and type, including whether it runs locally or remotely, since the two carry different discovery and revocation properties
• Owner, the person who added it and who is accountable for whether it should still exist
• Sanctioning status, reviewed and approved, or neither
• Credential and effective access, what the connection can actually reach inside the target system today, not what its configuration declares
• Consuming agents, which agents can invoke it
• First and last observed, so a server that stopped being used can be retired and one that appeared last week can be reviewed

The last field on that list is the one that turns an inventory into an operational tool rather than a document. Without observation dates there is no way to distinguish a live connection from an abandoned config entry.

The mechanism behind continuous MCP server discovery requires observing agent behavior at runtime, not reading configuration files. This is the technical distinction that separates runtime truth from theoretical configuration.

When an agent connects to an MCP server, it enumerates the server's available tools through the protocol's standard discovery mechanism. Runtime monitoring captures that enumeration. It records which tools were presented, which tools the agent actually called, and what data moved as a result. This happens at connection time, every time, regardless of whether the security team was notified that a new MCP server was added.

This approach surfaces three categories of MCP connections that point-in-time audits consistently miss:

1. New connections added after initial deployment. Business users and developers add MCP connections to existing agents without triggering a new agent registration event. Runtime discovery captures the new connection the first time it is used.

2. Connections through agent-to-agent pathways. An agent with limited permissions can connect to a second agent that has broader permissions, and that second agent may connect to MCP servers the first agent has no direct relationship with. Tracing these pathways requires following the connection chain at runtime, not reading the first agent's configuration in isolation.

3. Connections with authentication gaps. An MCP server that was configured to require authentication may be reachable without credentials due to a misconfiguration. Runtime observation catches the actual authentication state of each connection, not the intended state. For platforms like n8n, MCP connections without authentication represent a documented high-severity risk that configuration review alone will not reliably surface.

This is also where discovery and inventory diverge as concepts. Discovery is the continuous act of finding MCP servers, especially shadow ones, at the moment an agent connects. Inventory is the maintained catalog that discovery feeds.

Collect from runtime, not configuration. An MCP server that is actually in use has to connect and act to be useful, and that activity is observable in a way a local config file is not. Runtime collection also covers machines you cannot reach to scan.

Make it continuous. Servers are added in seconds. Any process that runs quarterly reports a state that was true once. Continuous collection is the difference between an inventory and a historical document.

Resolve effective access per connection. For each server, establish what its credential reaches inside the connected system today, and compare that to what the workflow needs. This is where over-scoped connections become visible.

Score the combination, not the server. The risk unit is the agent, not the individual connection. Evaluate what one agent can reach across every server available to it in a session, and flag the pairings that create a path from sensitive data to an external destination. A read-only warehouse connection and an outbound messaging connection are each unremarkable; together they are a data movement path nobody approved.

Attach an owner to everything. A connection with no owner cannot be scoped correctly, because nobody can say what it needs, and cannot be removed safely, because nobody can say what breaks.

Obsidian builds this inventory from runtime activity across connected AI platforms, separating sanctioned from unsanctioned servers, surfacing who added each one, resolving the effective access each credential holds inside your SaaS applications rather than what its configuration claims, and scoring the combinations that widen blast radius. Runtime enforcement is available today for Claude and Microsoft Copilot; other platforms are covered for discovery and governance.