TL;DR: AI data now moves through copilots, agents, and MCP servers at machine speed, and Nightfall argues that discovery, monitoring, and inline control must converge before sensitive information leaves the organization. The practical shift is from legacy DLP built for human workflows to governance that can see local and remote MCP activity across endpoints, SaaS, and agentic tools.
At a glance
What this is: Nightfall frames AI agent and MCP server discovery as a control-plane issue, arguing that security teams need visibility and enforcement across local and remote MCP activity, not just legacy DLP coverage.
Why it matters: This matters because MCP traffic can bypass network-only controls, so IAM, security, and AI governance teams need to govern discovery, policy enforcement, and sensitive-data movement at the point of use.
Context
AI agent security is no longer only about prompt filtering or model guardrails. The governance gap is that agents, copilots, and MCP servers now move sensitive data through endpoint and protocol paths that many legacy controls do not see, especially when local stdio servers sit on the host rather than the network.
MCP discovery has become a control-plane issue because discovery, inventory, policy, and enforcement are now inseparable. For IAM and NHI practitioners, this is the same pattern seen elsewhere in machine identity governance: if you cannot discover the thing, you cannot reliably control its access, scope, or data movement.
The article's examples are typical of the current market, not exceptional. Multiple vendors are now claiming some combination of MCP discovery, runtime enforcement, and inventory, which suggests the category is converging around governance rather than standalone monitoring.
Key questions
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.
Q: Why do MCP-connected AI workflows create new governance risk?
A: MCP-connected workflows expand the identity perimeter because a model can act through tools and data sources rather than only through a human user session. That creates delegated access paths that must be governed like other non-human identities. The risk increases when credentials, tool permissions, and downstream actions are not mapped together.
Q: What breaks when discovery only covers remote MCP traffic?
A: The biggest failure is blind spots on the endpoint, where local stdio servers can run outside network inspection and still move sensitive data. A partial inventory can create false confidence because it sees registered or proxied servers while missing the local tools developers actually use. That is a control failure, not just a visibility gap.
Q: How do AI governance teams decide whether discovery coverage is sufficient?
A: They should compare the discovery method with the actual data path and ask whether it sees local servers, remote servers, runtime actions, and the sensitive content moving through them. If the method cannot observe the decisive surface, coverage is incomplete. Sufficient discovery is the one that matches how the workflow really operates.
Technical breakdown
Why local stdio MCP servers create a visibility gap
Model Context Protocol servers can run locally as client-launched subprocesses and exchange data over stdin and stdout. That means a network gateway often cannot inspect the traffic directly, because the conversation never leaves the endpoint in a form the gateway can see. Discovery therefore shifts to host-level telemetry, MDM inventory, repository parsing, or client instrumentation. In practice, local discovery is not just a logging problem. It is an architectural boundary that determines whether a security team can inventory the server, understand which client invoked it, and apply policy before data leaves the workstation.
Practical implication: Treat local stdio MCP servers as an endpoint control problem, not a network-only inspection problem.
How discovery method changes what security teams actually see
The article shows that 'MCP discovery' is not one capability but several. Some products find servers through endpoint or MDM configuration parsing, some through repository scanning, some through gateway registration, and others through SIEM-derived signals or runtime hooks. Each method has a different blind spot. Configuration parsing can prove a server exists, but not that data was exchanged. Runtime inspection can show what happened, but only on the surfaces it covers. For AI governance teams, that means discovery claims need to be read as coverage claims, not as a binary yes or no.
Practical implication: Map each discovery method to its blind spots before assuming an MCP inventory is complete.
Why inline control matters more than visibility alone
Visibility tells you where MCP servers exist and which tools are in use. Control determines whether prompts, tool calls, shell commands, or data transfers are blocked, redacted, or allowed. That distinction matters because agentic workflows operate at machine speed and can move sensitive content before a human reviewer can intervene. If control happens after the fact, the organization is left with a dashboard, not enforcement. The article's control-plane framing is therefore accurate: governance depends on intervention at the moment of data movement, not just on post-event inspection.
Practical implication: Prioritise inline enforcement for sensitive MCP and agent workflows instead of relying on retrospective alerts.
Threat narrative
Attacker objective: The attacker objective is to capture sensitive data or credentials flowing through agentic and MCP-based workflows before existing controls can stop the transfer.
- Entry occurs when an employee, developer, or agent creates or invokes a local or remote MCP server as part of an AI workflow.
- Credential or data exposure follows when the server or tool call handles sensitive information, including secrets, files, or copied content that the control plane does not fully see.
- Impact occurs when that data leaves the organisation through an ungoverned agentic path that legacy human-workflow controls were never designed to intercept.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP discovery is now a governance prerequisite, not a nice-to-have inventory feature. The article correctly treats discovery as the first control-plane problem because organisations cannot govern what they cannot find. This is especially true for local stdio servers, where the network never sees the full exchange and endpoint visibility becomes the only credible source of truth. Practitioners should treat incomplete discovery as incomplete governance.
The new control gap is not 'AI use' but unmanaged agentic data movement. Legacy DLP was built to observe humans moving data through email, files, and web apps. Agentic workflows compress that journey into a machine-speed sequence of tool calls, prompts, and shell actions, which means the enforcement point has to move upstream. This is where identity governance and NHI thinking converge: the workload or agent becomes the actor, and its scope must be controlled as tightly as any privileged service account.
Discovery labels are misleading unless teams ask what surface is actually covered. Configuration parsing, gateway registration, SIEM log mining, and runtime instrumentation are not interchangeable. Each one answers a different question about the system, and none alone is enough to establish safe operation across endpoints, SaaS, and AI tools. The operational conclusion is simple: map the discovery method to the control objective before accepting any platform claim.
Agentic data plane visibility is becoming the decisive concept for AI governance. The market is moving from point tools toward platforms that can see, classify, and control data across MCP, endpoint, browser, and SaaS surfaces. That direction validates the need for converged governance, but it also raises the bar for evidence: practitioners should demand proof that the control plane can inspect local and remote paths, not just remote gateways. The right question is whether the policy follows the data path in time to matter.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Agentic data plane visibility: AI governance is moving toward a model where the policy must follow the data path across endpoint, browser, SaaS, and MCP surfaces. That shift matters because partial discovery creates a false sense of control, especially when local stdio servers sit outside network inspection.
Security teams should expect discovery claims to become less about whether an MCP server exists and more about whether the platform can prove what it saw, where it saw it, and whether it could intervene in time. That is the difference between inventory and governance.
The practical programme risk is blind spot accumulation: one tool sees configuration, another sees runtime, and neither gives a complete picture unless the organisation deliberately correlates both.
For practitioners
- Define the MCP discovery boundary Catalogue which MCP surfaces you can actually see today, separating local stdio servers, remote HTTP/SSE servers, gateway-routed traffic, and repository-derived configuration artifacts.
- Map control to discovery method Require each product claim to state whether it discovers servers through endpoint telemetry, MDM parsing, gateway registration, SIEM logs, or runtime hooks, and record the blind spots of each path.
- Move sensitive workflows to inline enforcement Block or redact prompts, tool calls, and shell commands before execution wherever MCP traffic can move secrets, credentials, or regulated data.
- Unify AI and endpoint governance Align AI agent policy with endpoint, SaaS, browser, and email controls so one rule set governs data movement across all supported channels.
- Test inventory against real runtime behaviour Compare what appears in configuration inventory with what appears in session or tool-call telemetry, then close gaps where discovery does not match actual use.
Key takeaways
- AI agent and MCP server discovery is now a control-plane problem because local and remote activity can move sensitive data outside legacy human-workflow controls.
- Discovery method matters as much as discovery itself, because endpoint parsing, gateway registration, SIEM mining, and runtime hooks each see different parts of the workflow.
- Practitioners should prioritise inline enforcement and cross-surface policy correlation if they want MCP governance to work in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets and sensitive data moving through MCP and agent workflows. |
| NHI-06 — Insecure Cloud Deployment Configurations | Remote MCP and gateway-based architectures create configuration-driven exposure paths. | |
| Recommendation — Scan MCP-connected workflows for secret leakage and block transfer before sensitive data leaves the endpoint. Audit MCP deployment configurations for exposed routes and restrict server reachability to approved clients. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic workflows can exceed intended access scope when tool calls and commands are insufficiently controlled. |
| Recommendation — Constrain agent privileges and tool access so runtime actions stay within approved identity boundaries. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern involves sensitive data and secrets moving through MCP paths that can be abused for theft. |
| Recommendation — Map MCP abuse paths to credential access and exfiltration techniques to improve detection and response. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The governance issue is controlling who and what can invoke MCP servers and tool calls. |
| Recommendation — Review entitlements for MCP-connected agents and enforce least-privilege access at runtime. | ||
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.
- Local stdio MCP server: An MCP server that runs on the client device and communicates over standard input and output streams. It is harder to inspect than remote services because network-only controls usually cannot see the message flow, so endpoint-level telemetry becomes the main source of visibility.
- Agentic Data Control Plane: An Agentic Data Control Plane is the governance layer that manages how AI agents discover, request, use, and protect data while acting on behalf of a user or system. It coordinates policy enforcement, authorization, logging, and data boundaries across tools, APIs, and repositories, so agent actions remain traceable, constrained, and auditable.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in practical terms. It helps security and IAM practitioners turn identity control into operational discipline across modern machine-driven workflows.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org