MCP security risks in 2026 expose a DLP visibility gap

At a glance

What this is: This is Nightfall's analysis of five MCP security risks, with the key finding that traditional DLP has limited or no visibility into MCP activity and the protocol is exposing secrets, IP, and excess access.

Why it matters: It matters because IAM and security teams now have to govern non-human access through a protocol layer that can bypass older inspection, approval, and scoping assumptions.

By the numbers:

• 81% of organisations saw a year-over-year surge in, AI-service credential leaks.
• 18% of MCP server deployments implement any form, form of access scoping for tool permissions.

👉 Read Nightfall's analysis of MCP security risks in agentic data environments

Context

MCP, or Model Context Protocol, is the layer AI agents use to reach code repositories, SaaS applications, and other data sources through tool calls rather than file transfers or browser sessions. That matters for identity governance because the access request is no longer the only thing to control; the protocol itself can carry secrets, data, and actions past conventional inspection points.

The governance gap is that most security stacks were built to inspect files, email, and web traffic, not agent-originated JSON-RPC tool calls. In practice, that means MCP can turn a legitimate non-human identity into a data movement path that bypasses the controls teams already believe they have.

For IAM and NHI practitioners, the article is a useful reminder that visibility, scope, and approval have to be enforced at the protocol edge as much as at the identity layer.

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-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What breaks when organisations rely on legacy DLP for MCP traffic?

A: Legacy DLP misses the protocol because MCP traffic is assembled by the agent and sent as tool calls rather than files or browser uploads. As a result, sensitive context can leave the endpoint without a matching DLP event, leaving security teams blind to the highest-value data movement.

Q: What should teams do when an MCP server gains new tools after review?

A: Reassess the approval state immediately and treat the added capability as a new entitlement, not a routine update. A tool addition can change the effective blast radius of the connected identity, so the server should be quarantined until the new surface is reviewed and re-authorised.

Technical breakdown

Silent MCP updates and tool poisoning

MCP servers can change their tool surface without a formal security review, which means a trusted connector can gain new capabilities after deployment. That is a version-drift problem, but it is also an identity problem because every new tool expands what the associated non-human identity can reach or modify. The risk includes benign maintainer changes, compromised packages, and hidden functionality added through dependency updates. In governance terms, the server may look stable while the accessible action set quietly grows.

Practical implication: continuously scan for new MCP tool capabilities and quarantine unreviewed updates before they reach production.

Why MCP traffic escapes legacy DLP

Traditional DLP inspects files in email, browser uploads, and endpoint sync paths. MCP traffic often moves as JSON-RPC over local pipes or remote HTTP transport, so the payload is assembled at runtime by the agent and then sent as a tool call. That means secrets, source code, and business documents can leave the endpoint without ever matching the controls built for static documents. The issue is not just that data moves, but that the transport itself is not one older DLP stacks were designed to understand.

Practical implication: add protocol-level inspection and redaction for MCP traffic rather than relying on file-centric DLP alone.

Over-scoped tokens and excessive tool permissions

Most MCP risk emerges when the underlying token or tool permission is broader than the task really needs. A read-only task can inherit write access, cross-repo access, or the ability to post, branch, or delete because the integrator exposed the full API surface. In identity terms, this is non-human privilege inflation: the agent is not breaking policy, it is operating inside the overbroad permissions it was given. Least privilege becomes operationally meaningful only when it is enforced per tool and per action, not merely per connector.

Practical implication: scope MCP tools separately and block high-impact actions even when the broader connector remains approved.

Threat narrative

Attacker objective: The objective is to move sensitive data or perform high-impact actions through a trusted agent pathway without triggering the controls built for conventional web or file traffic.

1. Entry occurs when a legitimate AI agent connects to an MCP server and inherits the permissions of the configured token or connector.
2. Escalation follows when the server exposes more tools than the original workflow intended, allowing broader access to repositories, SaaS data, or privileged actions.
3. Impact is the exfiltration of secrets, corporate IP, or unauthorized changes through a trusted protocol path that older DLP and review controls never inspect.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is now an identity governance problem, not only a data loss problem. The critical risk is that a non-human identity can move from authorised access to unauthorised data movement inside the same protocol session. That collapses the distinction between identity control and exfiltration control, because the tool call itself becomes the transport. Practitioners should treat MCP as an identity-bearing control plane, not a peripheral integration detail.

Silent capability drift is the named concept that best explains MCP exposure. When a trusted server adds tools after review, the organisation's approval state and the real action surface diverge. That gap is why change management and identity governance must be linked for MCP, with each tool capability treated as a governed entitlement rather than a software feature. The practical conclusion is that tool inventory has to be versioned, reviewed, and enforced continuously.

Overbroad MCP permissions are creating a new form of non-human privilege creep. The problem is not just that credentials exist, but that the same token can reach multiple repositories, channels, or SaaS actions far beyond the original intent. That pattern aligns with OWASP-NHI risk thinking and with zero trust control separation. Practitioners should re-evaluate whether connector-level approval is enough when the real risk sits at the individual tool-action boundary.

Shadow MCP servers will become the default discovery problem for AI estates. If teams do not know which servers exist, they cannot govern authentication, logging, or revocation consistently. That makes endpoint discovery and proxy enforcement the minimum viable control set, because unmanaged servers are the starting point for every other MCP failure mode. The field should expect MCP governance to merge with broader NHI lifecycle management.

Legacy DLP is being displaced at the protocol edge. The data is still the same corporate IP, but the transport has changed from document flow to agent workflow. That means security programmes built around content signatures alone will continue to miss the highest-value exposure paths. The practitioner takeaway is simple: if the protocol is not visible, the programme is not governing the actual risk.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• From our research: 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Teams building protocol-level governance should pair this with OWASP Agentic Applications Top 10 and the OWASP Agentic AI Top 10 to align tool risk with identity controls.

What this signals

Silent capability drift: MCP governance will increasingly depend on detecting when a server's action surface changes, not just when a token is issued. That means change control, entitlement review, and endpoint discovery have to work together, especially where agent traffic bypasses traditional inspection.

With 80% of organisations already reporting AI agents acting beyond intended scope in SailPoint's research, the governance gap is no longer theoretical for connected agent stacks. Teams that cannot see protocol-level tool calls will struggle to prove least privilege, auditability, or accountable access.

The reader-level implication is that MCP oversight will have to sit alongside NHI lifecycle management, not inside a legacy DLP programme. Security teams should expect discovery, scoping, and revocation to become the practical control trio for any agent-facing integration.

For practitioners

• Inventory every MCP server and connector Build an authoritative list of all approved MCP servers, the tools they expose, and the identities they inherit. Flag shadow servers running on developer endpoints or connected to corporate SaaS accounts without central registration.
• Enforce per-tool allow and deny rules Allow a connector broadly only when you can still block high-risk actions such as branch creation, record deletion, or message posting. Treat each tool as a separate entitlement and review it against the task that justified access.
• Inspect and redact protocol payloads Move content inspection to the MCP transport layer so secrets, source code, and business documents are screened before the request leaves the endpoint. Redact sensitive context automatically when the agent assembles a tool call.
• Quarantine unreviewed tool updates Require automatic hold and review for new tool capabilities, dependency changes, or server version drift that expands the action surface. Do not let an update inherit trust just because the connector name has not changed.
• Bind MCP access to lifecycle controls Apply joiner, mover, and leaver discipline to non-human identities behind MCP integrations. Revoke stale tokens, retire unused connectors, and require re-approval when ownership or business purpose changes.

Key takeaways

• MCP creates a protocol-level identity and data-governance gap that older DLP stacks cannot reliably inspect.
• The strongest warning sign is scope drift, where trusted servers and tokens gain new tools or broader access without equivalent review.
• Teams need per-tool governance, protocol inspection, and lifecycle controls before MCP becomes a default enterprise integration layer.

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.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
• 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.

What's in the full article

Nightfall's full report covers the operational detail this post intentionally leaves for the source:

• Detailed breakdowns of each MCP risk category and how the vendor maps them to OWASP MCP guidance
• Examples of protocol-level observability and content inspection controls for agent traffic
• Operational commentary on how Nightfall positions MCP security within its broader data protection platform
• The report's framing of the five risks as they apply to enterprise data security teams

👉 Nightfall's full post covers the five MCP risks, control gaps, and visibility limitations in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.