Most organizations have a reasonable handle on their sanctioned SaaS apps. Model Context Protocol - hit 10,000 public servers within a year of launch, with 97 million monthly SDK downloads. None of those numbers capture the servers your developers configured locally. Those don't appear in any registry. They were added at the IDE level, one developer at a time, with no approval step and nothing that touches a central system. That's the inventory problem. It comes before any question of enforcement.
How Existing Approaches Handle This - And Where They Stop
A few approaches have emerged here, each with real capabilities and real limits.
- Proxy-based MCP monitoring works by inserting an inspection layer between MCP clients and servers. It can see everything routed through it - tool calls, responses, data moving in both directions. The constraint is structural: it sees what's pointed at it. A developer who configured an MCP server directly in their IDE config file, without routing through the proxy, stays invisible. Coverage is bounded by what's been instrumented.
- Network and SASE-layer tools cover traffic that crosses the network perimeter. They're well-suited to HTTP-based MCP connections that traverse their inspection points. Local MCP servers that communicate over stdio - spawned by a build script, running on the developer's machine - don't produce network traffic to inspect. The connection between the IDE and the local process happens before any packet leaves the device.
Neither approach answers the foundational question: which MCP servers are actually configured across your environment, on which machines, by which users?
What Device-Level Visibility Gets You
Nightfall's endpoint agent reads MCP server configurations directly from the source - every IDE config file, on every managed device. That means you get a complete picture of what's been set up, not just what's been routed through a proxy or observed on the network.
Specifically, you can see: every MCP server configured across Cursor, VS Code, Claude Code, and other IDE config files; which device each configuration lives on and which user owns it; how many times each local server has been called; and for remote HTTP servers, the volume of data transferred. This is device-level inventory, not a log of traffic that happened to pass through a managed path.
The distinction matters because the unmanaged server - the one a developer added on a Friday without filing a ticket - is exactly the one you'd otherwise miss.
What This Sets Up
An inventory that reflects what's actually deployed is the prerequisite for everything that follows. You can't write a meaningful policy against a server you don't know exists. You can't scope an investigation without knowing which users had which connections at which point in time.
But inventory is only the beginning of the question. Once you know which MCP servers are running, the next question is what's moving through them - the prompts users are sending, the tool calls being made, the responses coming back, and the shell commands being executed. And as AI tools like Claude Cowork extend into business workflows, the same visibility question applies to the connector layer: what is the agent reading, what is it writing, and where is that data going?
A few questions worth sitting with: Do you know every MCP server configured across your developers' machines right now? If a business user's AI connector accessed something it shouldn't have last Tuesday, would you have a record of it? If you needed to scope the blast radius of a misconfigured server, where would you start?
Those are inventory questions before they're enforcement questions. That's where we start.
Get a demo to see Nightfall in action.
.svg)
.svg)
