Notifications
Clear all
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.
NHIMG editorial — based on content published by Nightfall: You Can't Secure AI Agents You Haven't Found
By the numbers:
- While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility.
- 90% of organisations have experienced AI agent behaviour that exceeded intended scope or control, according to NHIMG research.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do proxy and SASE tools miss some AI connector risks?
A: Because those tools only see traffic that enters their inspection path.
Q: How do you know whether MCP visibility is actually complete?
A: You know it is complete only when the inventory includes every configured server, the device it lives on, the owner who added it, and the usage history tied to that configuration.
Practitioner guidance
- Inventory MCP servers from endpoint configuration files Use endpoint discovery to enumerate every IDE-level MCP server across managed devices, then reconcile that list against approved records and known owners.
- Separate routed traffic from deployed state Build reporting that distinguishes servers observed in proxies from servers configured locally on devices.
- Map each server to a named owner and device Require a user and device owner for every MCP server configuration, including local and remote entries.
What's in the full article
Nightfall's full analysis covers the operational detail this post intentionally leaves for the source:
- Endpoint agent workflow for reading MCP server configurations directly from IDE files
- Inventory fields available per server, including device, user ownership, call counts, and data transfer volume
- How local HTTP and stdio-based MCP connections differ in observability and risk
- The connector-layer questions Nightfall says teams should ask before enforcement
👉 Read Nightfall's analysis of MCP inventory blind spots in AI agent environments →
MCP server visibility gaps: are your controls keeping up?
Explore further
20/08/2026 6:31 pm
Inventory, not enforcement, is the missing control plane for MCP governance: the first failure is not policy drift but discovery drift. If local servers can be added in an IDE and never appear in a central registry, every downstream control starts from partial truth. The implication is that identity programmes must define MCP server existence as an inventory problem before they can define it as an access problem.
A few things that frame the scale:
- 90% of organisations have experienced AI agent behaviour that exceeded intended scope or control, according to Ultimate Guide to NHIs , 2025 Outlook and Predictions.
- 72% of organisations still lack full visibility into at least one major class of non-human identity, according to NHIMG research on the identity estate.
A question worth separating out:
Q: What should teams do first when AI connectors access sensitive business data?
A: They should scope the connector layer before they try to enforce policy. That means identifying which connectors can read, write, or execute against business systems, then mapping those permissions to the devices and users operating them. Without that step, incident scoping and blast-radius analysis will be unreliable.
👉 Read our full editorial: MCP inventory gaps leave AI agents and local servers unseen
