MCP inventory gaps leave AI agents and local servers unseen

At a glance

What this is: Nightfall argues that MCP governance is failing at discovery, with local IDE-configured servers and some AI connector paths remaining outside central inventory.

Why it matters: IAM and NHI teams need visibility before control, because you cannot scope policy, investigation, or access decisions for MCP servers you do not know exist.

By the numbers:

• Model Context Protocol reached 97 million monthly SDK downloads.

Context

MCP inventory is the first governance problem, not the last. When servers are configured locally in IDE settings and never routed through a central control point, security teams lose the ability to answer a basic question: what is actually deployed across the environment?

That gap matters for non-human identity governance because MCP servers sit in the execution path for agent tooling, data access, and command execution. If discovery is incomplete, enforcement is blind, and the organisation is left managing policy around only the visible subset of its connector layer.

The article's central claim is that device-level visibility is the prerequisite for any credible MCP governance model. Without it, investigations, blast-radius analysis, and policy scoping all start from an incomplete asset map.

Key questions

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: Why do local MCP servers create more governance risk than routed ones?

A: Local servers can be added in developer tools without central approval and can communicate over paths that never cross a managed inspection point. That means the server may have active access and data movement even though security tools cannot see it. The governance risk is not the server type alone, but the absence of an authoritative inventory record.

Q: How should teams decide whether their MCP monitoring is actually sufficient?

A: Test monitoring against discovered endpoint configurations, not against proxy coverage alone. If a server appears in an IDE file or local process list but not in central telemetry, then the monitoring model is partial. Sufficiency means the inventory and the enforcement path describe the same environment, not two different ones.

Q: What is the difference between MCP traffic inspection and MCP inventory?

A: Traffic inspection tells you what moved through a monitored path, while MCP inventory tells you which servers are configured across devices and by whom. Those are not the same control. Inventory is the prerequisite because you cannot enforce policy or scope an incident around a server that never touched the monitored path.

Technical breakdown

Why proxy-based MCP monitoring misses local servers

Proxy inspection only sees traffic that is routed through the proxy. If a developer configures an MCP server directly in an IDE file, or the server runs locally over stdio, the inspection point never sees the exchange. This is not a tuning problem, it is an architectural boundary. Governance built on routed traffic will always undercount locally attached server configurations, especially where setup happens on the endpoint rather than through centrally managed onboarding.

Practical implication: Do not treat proxy coverage as MCP inventory; it is only path coverage.

Why network controls do not discover endpoint-resident MCP configurations

Network and SASE tools depend on packets crossing a perimeter or inspection point. Local MCP servers spawned by scripts on a developer machine can exchange data with the IDE before any network packet exists. That means the server may be active, used, and risky without producing evidence in the systems most teams rely on for detection. The technical gap is between process creation on the endpoint and traffic visibility on the wire.

Practical implication: Add endpoint-level discovery for MCP configuration files and local process activity.

Why configuration inventory is the real control plane for MCP governance

Inventory is not just a reporting layer. For MCP, configuration files define which servers exist, which users attached them, and which devices can invoke them. Once that map exists, teams can see local and remote servers, usage counts, and data movement volumes. That shifts governance from inference to fact. Without configuration inventory, every downstream control, from policy to investigation, is partially fictional.

Practical implication: Make MCP configuration inventory the source of truth for policy and investigation.

NHI Mgmt Group analysis

Inventory blind spots are now the dominant MCP governance failure. The article shows that the hardest problem is not whether a server can be monitored, but whether it can be found at all. A governance model that depends on proxies or perimeter traffic will always lag behind endpoint-configured MCP deployments. The practitioner conclusion is straightforward: discovery is the control plane, not a supporting control.

Local MCP configuration creates an unmanaged identity boundary. Each IDE-defined server represents a non-human access path that can exist without central registration, making ownership and accountability ambiguous. That is a classic NHI governance failure because the access path is real even when the inventory record is not. Teams need to treat locally configured MCP servers as governed identities, not informal developer conveniences.

Unseen connector layers create identity blast-radius debt. Once AI tools extend into business workflows, the question is no longer only which server exists, but what it can read, write, and execute. The longer that inventory remains incomplete, the larger the gap between assumed and actual access becomes. Practitioners should assume the blast radius is unknowable until the endpoint inventory is complete.

MCP visibility is becoming a prerequisite for agentic AI governance. The same discovery gap that affects server inventory also affects connector oversight, prompt tracing, and action scoping. That makes this an identity problem before it is a data problem. Organisations that do not solve discovery will keep building policy on an incomplete execution map.

Device-level discovery is the named control gap this topic exposes. Nightfall's core finding is not that MCP is inherently insecure, but that unmanaged server instances evade the systems many teams use to govern access. The implication is that inventory must move to the device and configuration layer before any meaningful policy can be enforced.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Device-level discovery is now the governance baseline for MCP. If a server is configured in an IDE and never routed through a proxy, then the organisation is governing only the subset that passes through its inspection layers. That creates a structural mismatch between deployed access paths and the controls meant to govern them.

Blast-radius analysis depends on configuration truth, not network inference. Teams cannot determine who could reach what, or which connector was active, if they start from partial telemetry. The practical shift is to make endpoint configuration inventory the authoritative source for MCP oversight.

For practitioners

• Implement endpoint-level MCP discovery Scan IDE configuration files on managed devices to enumerate every local and remote MCP server, rather than relying on proxy or perimeter logs.
• Separate visible traffic from actual deployment Treat proxy and SASE telemetry as partial evidence only, and compare it against endpoint inventory before writing policy or declaring coverage.
• Map server ownership to users and devices Record which user configured each MCP server and which device it resides on so investigations can start from an accountable source record.
• Scope blast radius from configuration, not assumption Use the set of discovered MCP servers as the baseline for incident scoping, especially where local stdio servers never produce network telemetry.
• Extend governance to connector-layer data movement Track what prompts, tool calls, responses, and shell commands flow through MCP and adjacent AI connectors so policy reflects actual data movement.

Key takeaways

• MCP governance fails first at discovery, because locally configured servers can sit outside the central inventory even when they are active on developer machines.
• Proxy and network inspection do not equal inventory, so teams that rely on routed traffic alone will miss local stdio-based MCP servers.
• The control that matters most here is endpoint-level discovery, because policy and incident scoping both depend on knowing which servers exist.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• MCP inventory: MCP inventory is the authoritative record of which servers are configured, where they run, who configured them, and what they can access. For governance, inventory is the control plane that makes policy, review, and incident scoping possible.
• Application-level discovery: A visibility capability that identifies individual applications inside a broader software suite rather than treating the suite as one opaque block. It gives governance teams the detail needed to understand which components are used, unused, or over-assigned.
• Connector-layer visibility: Connector-layer visibility is the ability to see what data, prompts, and actions pass through the AI connections that link users, agents, and external systems. It is a governance requirement because the connector often becomes the real path of access, not just a transport detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.