> For the complete documentation index, see [llms.txt](https://help.nightfall.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.nightfall.ai/data-exfiltration-prevention/ai-agent-security/ai-governance/mcp-server-visibility.md). # MCP Server Visibility AI Governance is the Nightfall console for MCP (Model Context Protocol) servers on developer machines. It covers local `stdio` servers and remote HTTP/SSE servers used by clients such as Claude Code, Cursor, VS Code, Windsurf, Codex, Copilot, and others. Go to **AI Governance**. With the current inventory experience you get: * **Inventory**, with sub-tabs for **MCP servers**, **Hooks**, and **Plugins** * **Collections** * **Users & Devices** * **Settings** (notification triggers and alert channels) Some tenants still see the older **Server Inventory** tab (servers only, no Hooks, Plugins, or Settings). If that is what you have, ask your Nightfall account team to enable the current AI Governance experience. This page is about what is actually running on endpoints. Sanctioned remote servers that you want clients to call through Nightfall are documented on [MCP Gateway](/data-exfiltration-prevention/ai-agent-security/ai-governance/mcp-gateway.md). ## Use cases Filter **High** or **Critical** risk, or look for the **Shadow** badge, when you want unsanctioned servers first. Use risk plus the tool list when you need to know whether a server only reads data or can write and delete. Use the **Managed** filter when you want the list of servers that came from an org-managed config file. Treat project-level configs as extra review when they name servers that are not on your approved list. When a DLP alert involves an agent tool call, open the server here. You can see the device, the user, the tools, and the config file that was in place. Put approved servers in a collection, then scope an endpoint exfiltration policy to all MCP servers, only those collections, or everything except those collections. Binding by fingerprint keeps the policy on the same server if someone renames it in `mcp.json`. ## Prerequisites MCP data shows up only when the endpoint agent can collect it: * **macOS:** Nightfall Agent **v1.2.12.11 or later**, plus **MDM Profile v3**. The agent can auto-update. The profile does not. IT or SecOps has to deploy v3. The profile ships in the macOS agent bundle from v1.2.12.9 onward. * **Windows:** Nightfall inventories MCP on Windows endpoints the same way. Confirm the minimum Windows agent build with your Nightfall account team. {% hint style="warning" %} If the Mac MDM profile is still below v3, AI Governance stays empty for those devices even when the agent is current and the feature is on for your tenant. {% endhint %} Hooks and Plugins need the current inventory experience and the extra telemetry those views use. If servers appear but Hooks and Plugins do not, check the tenant experience first, then the agent version with Nightfall. ## MCP servers **Inventory > MCP servers** is the org-wide table. Each row is one server. The name cell can also show **Managed** and **Shadow**. | Column | What it means | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Server Name** | Name reported by the device (from `mcp.json`, `claude.json`, or similar). Remote container images often show as an image name. Version appears under the name when Nightfall has it. | | **Type** | Transport. **stdio** is a local subprocess (no outbound network). **http** / **sse** are remote and send data off the device. | | **Risk** | **Known**, **Low**, **Medium**, **High**, or **Critical**. A small dot on the badge means an admin overrode the computed level. | | **Provenance** | **First-party**, **Official**, **Community**, or **Unknown**. See [Provenance, Managed, and Shadow](#provenance-managed-and-shadow). | | **Users** | How many users have this server. | | **Clients** | Recognized AI clients plus any unrecognized process names. A **+N** chip means more clients than the row can show. | | **Volume** | For stdio: how many times the process started. For remote: data sent and received. | | **Last Activity** | Last time any device used the server. | Recognized clients include Claude Code, Cursor, VS Code, Claude Cowork, Claude (including Claude Desktop), Windsurf, Codex, Copilot, and Antigravity. Anything else stays in the unrecognized list. ### Volume **stdio:** count of local process starts. The detail header labels this **Process Starts**. One typical agent session that uses the server is one start. **http / sse:** bytes sent and bytes received (shown with up/down markers). High outbound volume is the number to look at if you are worried about data leaving the device. ## Server details Open a row for the server page. Tabs are **Overview** and **Devices**. ### Overview * **About:** description from the public MCP registry. If the server is not listed, the card says so and points you at Identity. * **Identity:** Endpoint (remote URL, HTTP servers only), Package, Version, Source (repository link), Transport, Fingerprint (the server id), and **Configured As** (each configured name plus how many tools that name has). * **Risk score:** composite level and the signal groups behind it. * **Tools:** classified tool list. * **Clients:** recognized clients and a count of unrecognized ones. * **Collections:** collections this server is bound to. The header actions are **Add to collection**, **Override risk**, and **Override provenance**. ### Devices Who is using the server, on which endpoint, through which host app. Rows can also show provenance, risk, clients, and a logo when Nightfall can resolve one from the remote URL. Each observation is tagged **Config file**, **Process start**, and/or **Network**, depending on how it was seen. ### Configuration file versions Nightfall keeps versions of the config files that mention the server, for example `~/.claude.json`, `.cursor/mcp.json`, or the VS Code user-level `mcp.json`. Files group by client and by scope: **Global** (all projects for that user) or **Project** (one repo or workspace). You get the path, the scope badge, last modified, and the file body at each version (v1, v2, and so on). ## Risk The **Risk score** card uses **Known**, **Low**, **Medium**, **High**, or **Critical**. Signals are grouped as: | Group | Question | | ---------- | ----------------- | | Capability | What can it do? | | Provenance | Who made it? | | Governance | Is it sanctioned? | | Behavioral | What is it doing? | Each group has a contribution. Thin evidence gets a **low confidence** badge. Groups that do not apply are greyed out. The written explanation is generated after the score. While that runs, the card shows **Analyzing risk** and the group breakdown is still the source of truth. If explanation generation fails, the breakdown stays and Nightfall retries on the next recompute. To override: **Override risk**, pick **Critical**, **High**, **Medium**, or **Low** (not Known), and enter a reason. The card then shows the computed level, the level you set, who did it, when, and the reason. **Revert to auto-detected** clears the override. ## Tools Every discovered tool gets a category and a severity. * Category: **Read-only**, **Read-write**, or **Destructive** * Severity: **Low**, **Medium**, **High**, or **Critical** Filter pills on the Tools card jump to a category or severity. You can override both values on a tool and clear the override later. ## Provenance, Managed, and Shadow **Provenance** is where the server came from: * **First-party:** an admin added it as your organization's own * **Official:** matches a verified registry entry * **Community:** published in a community marketplace * **Unknown:** source could not be determined Admins can override provenance and revert it. **Managed** means the install came from an org-managed config file (admin or MDM). You can filter servers, hooks, and plugins to Managed. **Shadow** means the server is not tied to a recognized MCP client, so it is running outside governed tooling. That raises its risk score. A developer-added server inside Claude Code or Cursor is usually neither Managed nor Shadow. ## Hooks **Inventory > Hooks** lists event-triggered commands that clients run during an agent session (for example a shell command before a tool call). Columns: * **Event:** lifecycle event. Org-deployed hooks can show **Managed** * **Handler:** how the hook is invoked * **Command:** what it runs * **Client:** which AI application owns it * **Devices:** how many endpoints have it Filter by event or Managed. Open a hook for the full definition and the device list. {% hint style="info" %} A hook can run arbitrary commands inside an agent session. Use this list to confirm you only have the hooks you expect, including Nightfall's own protection hooks. How to install those is under Auditability and Control. {% endhint %} ## Plugins **Inventory > Plugins** lists extensions installed into AI clients. A plugin can ship its own MCP servers and hooks. Columns include name and marketplace, **Status**, **Trust**, **Provenance**, client, and device count. Status values are **Available**, **Installed**, and **Enabled**. The list hides **Available** (seen in a marketplace, not on a device) until you add it in the Status filter. Trust is **Allowed** or **Blocked**, from the client's own trust state. Open a plugin for the servers it bundles (transport, risk, provenance), the hooks it bundles (event and handler), and the devices that have it. ## Users and devices **Users & Devices** is the fleet view. Open a device for **MCP servers**, **Hooks**, and **Plugins**, each with a count. Config files on that device are scanned. Scan status is shown, including when a scan produced a violation. ## Collections and policies Collections are named sets of servers. You use them in reports and in endpoint exfiltration policies. From a server page, **Add to collection** has two steps: **Group selection**, then **Tool selection**. On group selection you either bind the **entire server by fingerprint** (default; every configured name stays in the collection) or pick specific configured names. Fingerprint-bound entries show **Bound by fingerprint** in collection management. Manage collections under **AI Governance > Collections**. In an endpoint exfiltration policy, MCP scope is: * **All MCP servers** * **Specific MCP servers** (the collections you pick) * **All except these MCP servers** You can create a collection from the policy wizard (**Create new collection**). You can also add tool-name patterns. Those patterns are exclusions when the scope is **All except these MCP servers**. Details: [Creating an AI Agent Security Policy](/data-exfiltration-prevention/ai-agent-security/ai-governance/auditability-and-control/creating-an-ai-agent-security-policy.md). ## Notifications **AI Governance > Settings** has two parts. **Notification triggers** (nothing is sent until you save a preference; a company with no saved preferences is opted out): | Area | Events | | ----------- | ----------------------------------------------------------------------------------------------- | | MCP Servers | Config file changes: Added, Removed, Updated. Runtime detections: stdio servers, Remote servers | | Hooks | Hook changes: Added, Removed, Updated | | Plugins | Plugin changes: Installed, Enabled, Disabled, Uninstalled | **Alert channels** use Nightfall's standard integrations. You need at least one channel or nothing is delivered. Typical channels are email, Slack, and webhook. A practical first save is config file **Added**, hook **Added**, and plugin **Installed**. **Opt out of all notifications** clears every trigger. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.nightfall.ai/data-exfiltration-prevention/ai-agent-security/ai-governance/mcp-server-visibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.