Topic starter
20/08/2026 5:52 pm
TL;DR: Most organisations can see sanctioned SaaS, but local and IDE-configured Model Context Protocol servers still sit outside central inventory, creating a blind spot for agentic and connector-layer data access, according to Nightfall. That is an inventory failure before it is an enforcement failure, because governance cannot begin until unmanaged servers are discovered.
Editorial analysis by NHI Mgmt Group, based on content published by Nightfall: “You Can't Secure AI Agents You Haven't Found”.
By the numbers:
- Model Context Protocol reached 97 million monthly SDK downloads.
Key questions
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
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.
Q: How should teams decide whether their MCP monitoring is actually sufficient?
A: Test monitoring against discovered endpoint configurations, not against proxy coverage alone.
Practitioner guidance
- 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.
Bottom line: MCP governance fails first at discovery, because locally configured servers can sit outside the central inventory even when they are active on developer machines.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:31 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP inventory gaps leave AI agents and local servers unseen