MCP security risks in 2026 expose a DLP visibility gap

At a glance

What this is: This is a Nightfall analysis of MCP security risks in 2026, arguing that legacy DLP cannot see the protocol layer where AI agents are moving sensitive data and tool actions.

Why it matters: It matters because IAM, NHI, and security teams now need to govern agent-to-tool access at the protocol boundary, not only at the file, browser, or email layer.

Context

MCP security risks are an identity governance problem as much as a data security problem. Model Context Protocol gives AI agents direct paths into repositories, databases, and SaaS systems, but those tool calls often sit outside the inspection models built for files, browsers, and email.

The result is a control gap between where sensitive data now moves and where legacy DLP still looks. When the protocol layer carries credentials, corporate IP, and high-impact actions, governance has to follow the agent’s tool surface rather than the old perimeter.

Nightfall’s analysis treats that mismatch as the core issue: security teams may think they are protecting endpoints and cloud apps, while the real exposure is happening in MCP traffic that their stack never classifies or inspects.

Key questions

Q: What breaks when MCP activity is not visible to security teams?

A: When MCP activity is invisible, traditional DLP and audit controls miss the protocol where AI agents are moving secrets, corporate IP, and privileged actions. The failure is not only loss of telemetry. It is the loss of the governance boundary, because the organisation cannot classify, restrict, or investigate tool calls it never sees.

Q: Why do MCP servers increase risk when tool permissions are too broad?

A: MCP servers can expand risk because they sit between an AI client and sensitive backends, often with enough reach to query data, trigger workflows, or modify records. If permissions are broad, a compromised or misbehaving agent can move from one tool to another with little friction. Least privilege and scoped discovery reduce that blast radius.

Q: How do security teams know whether MCP server governance is working?

A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.

Q: Should organisations treat MCP servers like ordinary plugins or like privileged identities?

A: Organisations should treat MCP servers like privileged identities, because they are not passive extensions. They execute inside trusted workflows, make file and API access possible for agents, and can widen the blast radius of a compromise if their permissions are not tightly scoped and continuously revalidated.

Technical breakdown

Why MCP traffic evades traditional DLP

Traditional DLP was designed to inspect a small set of well-defined egress paths: files, browser uploads, and sync traffic. MCP changes the shape of the problem because the payload is assembled at runtime by an AI agent and transported over local or remote protocol channels that look like legitimate application traffic. That makes the content variable, the destination dynamic, and the security boundary harder to pin down. The important technical point is not that DLP is weak in general, but that it was built for a different data path. Once tool calls become the carrier for sensitive context, the control plane has to shift from document inspection to protocol-aware governance.

Practical implication: treat MCP discovery and content inspection as a new enforcement layer, not a DLP tuning exercise.

How overbroad tool permissions expand agent blast radius

MCP servers frequently expose the full capability set of the underlying API unless the integrator narrows it. That creates a privilege mismatch: an agent asked to summarise data may also be able to create branches, post messages, or read unrelated repositories if the tool binding is too broad. In identity terms, the problem is not just authentication but authorization scope. The agent does exactly what the allowed interface permits, so the risk is encoded in the tool contract, not in a malicious exploit. This is why tool-level permissioning matters more than simple access to the server itself.

Practical implication: map each MCP tool to the minimum action set and block high-impact verbs by default.

What shadow MCP servers change about governance

Shadow MCP servers are especially difficult because they can appear outside central inventory, authenticate inconsistently, and start sending tool calls before security teams know they exist. The technical pattern is familiar from other unmanaged non-human identities: if discovery lags deployment, governance arrives too late to shape the risk. The difference here is that the exposure sits in an interaction layer between the agent and the data source, so traditional SaaS and endpoint controls do not see the full chain. That turns discovery into the first control, not a housekeeping task after the fact.

Practical implication: build continuous discovery for MCP endpoints and block unapproved servers at the proxy or endpoint layer.

Threat narrative

Attacker objective: The objective is to move sensitive data or trigger privileged actions through MCP in a way that bypasses the organisation’s existing inspection and governance layers.

1. Entry occurs when an AI agent connects to an MCP server that can reach internal repositories, SaaS applications, or databases through a trusted desktop or local transport path.
2. Credential access happens when the agent retrieves secrets, tokens, or configuration material as part of the tool response rather than through a conventional file download.
3. Escalation follows when overly broad tool permissions let the agent reach repositories, channels, or records beyond the original user’s intended scope.
4. Impact is the exposure or misuse of corporate IP, secrets, and high-risk actions through a channel that legacy DLP and audit tooling do not inspect.

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 security risks are fundamentally a protocol-governance problem, not just a DLP gap. Once AI agents can move sensitive context through tool calls, the inspection model has to shift from file-centric controls to protocol-aware enforcement. The old assumption was that data loss would show up in browsers, email, or cloud sync. That assumption no longer holds, and practitioners need to govern the transport layer where agent activity now lives.

Shadow MCP servers create an inventory problem that looks exactly like NHI sprawl. A server that appears outside central discovery, authenticates inconsistently, and starts handling tool calls before review behaves like an unmanaged non-human identity. The governance burden is therefore lifecycle-based: know what exists, who approved it, what it can call, and when it should be revoked. Teams that already struggle with service account visibility should recognise the same pattern here.

Overbroad MCP tool permissions turn every agent into a potential privilege amplifier. The critical failure is not that the agent is intelligent; it is that the tool contract often exposes the maximum underlying API capability. That creates an identity blast radius problem, where one approved integration can bridge into repositories, messaging platforms, and records the user was never meant to touch. The practical conclusion is that authorization must be defined at the tool verb, not at the server name.

Trust in agent traffic is collapsing faster than legacy controls can adapt. The article’s risk list shows that secrets leakage, scope creep, silent updates, and shadow deployments are all expressions of the same design tension: AI agents operate through dynamic context assembly, while enterprise security still expects stable, inspectable objects. That mismatch will keep widening until security programmes treat MCP as an identity and data governance surface in its own right.

Protocol-level observability is becoming the named concept that security teams need to operationalise. MCP observability is not just monitoring; it is discovery, inspection, and access control aligned to how agents actually move data. This is the control model that collapses the visibility gap between agent intent and enterprise governance. Practitioners should use it to reframe MCP from a developer convenience to an enforceable security boundary.

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.
• Read next: MCP Security Guide

What this signals

Protocol-level enforcement is now the missing control plane for AI agent data movement. MCP traffic does not behave like email, browser uploads, or sync activity, so security programmes that stay file-centric will keep missing the real egress path. The governance shift is toward visibility at the tool-call layer, where identity, content, and action converge.

Shadow MCP behaviour should be read as NHI sprawl with a faster lifecycle. If a server can be added, updated, and connected outside central review, then access reviews that focus only on user-facing applications will undercount the real exposure. Practitioners need discovery and offboarding for MCP endpoints the same way they already think about service accounts.

Overbroad tool binding creates an identity blast radius that security teams cannot wish away. When one agent can reach repositories, messaging systems, and records through the same integration path, the risk is not isolated misuse. It is a governance model that defines privilege too late in the delivery chain, after the capability has already been exposed.

For practitioners

• Deploy protocol-level MCP discovery Continuously inventory MCP servers, tool registrations, and new capabilities so unapproved servers do not remain invisible until after they have connected to internal systems.
• Scope every tool to the minimum verb set Restrict each MCP tool to the smallest action set that supports the use case, and block high-risk actions such as branch creation, message posting, or record deletion unless explicitly approved.
• Inspect sensitive context before it leaves the endpoint Add content inspection for secrets, customer data, and corporate IP at the protocol layer, because MCP payloads are assembled at runtime and will not match traditional DLP signatures.
• Quarantine unreviewed server updates Treat silent tool additions and version drift as a change-management event, and hold new MCP capabilities until security review confirms the updated surface is acceptable.
• Force authentication on every MCP call Use an SSO-gated proxy or equivalent control so that tool access is authenticated and attributable even when the underlying MCP server does not enforce it consistently.

Key takeaways

• MCP security exposure is growing because AI agents now move sensitive context through a protocol layer that traditional DLP does not inspect.
• The article’s strongest evidence is that 24,008 secrets were exposed in MCP configuration files in 2025 alone.
• Security teams need protocol-level discovery, tool-scoped authorization, and update review before MCP becomes a permanent blind spot.

Key terms

• MCP observability: MCP observability is the ability to see how Model Context Protocol connections behave across agents, tools, and data sources. It includes logging requests, responses, tool calls, errors, latency, and policy decisions so teams can detect misuse, troubleshoot failures, and verify that agent actions stay within approved identity and access boundaries.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Execution-layer DLP: Execution-layer DLP is data loss prevention enforced at the point where a user interacts with an application, typically in the browser or local runtime. It is designed to stop sensitive data from leaving the organisation through copy, paste, upload, or typed input before the transfer occurs.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.