MCP observability exposes the limits of legacy DLP and IAM

At a glance

What this is: This is Nightfall’s checklist for monitoring MCP usage, and its key finding is that MCP traffic can evade legacy DLP, IAM, and SIEM controls because it looks like authorized API activity.

Why it matters: It matters because IAM and security teams now have to govern AI agent-to-tool access as a real identity and data path, not just a networking or DLP problem.

By the numbers:

• In July 2025, researchers found 1,862 exposed Model Context Protocol servers on the public internet.
• By late 2025, 43% of public MCP servers were vulnerable to command injection.
• By April 2026, a by-design RCE flaw in Anthropic's official SDK affected more than 7,000 publicly accessible servers.

👉 Read Nightfall's 10-step checklist for monitoring MCP usage in 2026

Context

MCP security is an identity and data-governance problem because Model Context Protocol connects AI agents to tools and data sources through what often looks like ordinary API traffic. When that traffic is unauthenticated, over-scoped, or invisible to existing controls, security teams lose the ability to see which agent did what, against which system, and with what data.

The security gap is not theoretical. The article argues that legacy DLP, IAM, and SIEM were built for human-driven workflows and file-centric controls, while MCP moves sensitive data through live tool invocations and semantically transformed responses. That creates a monitoring blind spot across AI agents, workloads, and the identities that authorize them.

For IAM and NHI teams, the practical question is whether MCP connectors are being governed as persistent non-human identities with clear ownership, scope, logging, and review. In most environments, the answer is still no, which makes this a typical enterprise exposure rather than an edge case.

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 tools create a governance problem for IAM teams?

A: MCP turns each tool into a potential permission boundary, which means IAM teams must govern many small access decisions instead of one broad application login. If those boundaries are not scoped carefully, autonomous agents can accumulate effective privilege faster than traditional reviews can catch.

Q: What breaks when DLP is only tuned for file-based exfiltration?

A: File-based DLP misses the most important MCP risk, which is sensitive information moving inside tool calls and synthesized responses rather than attachments or downloads. When the data never looks like a traditional file, pattern matching alone cannot tell whether the agent is exposing regulated or strategic information.

Q: How do organisations know whether MCP enforcement is actually working?

A: The clearest sign is that every meaningful agent action produces a consistent attestation trail and can be blocked when the session lacks provenance. If requests still succeed through direct APIs, side connectors, or browser clicks without governance metadata, enforcement is incomplete and the control plane is not authoritative.

Technical breakdown

Why MCP traffic bypasses legacy DLP and SIEM

MCP changes the inspection point. Instead of a file attachment or email body, the sensitive content can move inside a tool invocation, a returned model response, or a chain of calls that looks like normal API activity. Traditional DLP was tuned for signatures, file movement, and obvious exfiltration channels, while SIEM often sees only fragmented logs unless agent activity is normalized into the same telemetry plane. That is why protocol context matters: the security decision has to happen where the MCP call is made, not after the data has already moved.

Practical implication: instrument MCP traffic at the protocol layer and correlate it with identity and data telemetry before relying on downstream DLP or SIEM rules.

Identity and least privilege at the tool level

The article’s core governance point is that an MCP-connected agent is a non-human identity with tool-specific permissions, not a generic application integration. Broad scopes create identity dark matter, where access exists but is not meaningfully governed at the tool level. Least privilege must therefore be defined per tool, per connector, and per configuration change, especially when OAuth flows were approved outside IT review. The control failure is not just excess access, but excess access that no one can confidently enumerate or revoke.

Practical implication: treat each MCP connector like a governed NHI and review scopes whenever the connector, tool set, or owning team changes.

What AI-native DLP changes about MCP monitoring

AI-native DLP is different because it inspects context, not just patterns. In MCP environments, the most valuable data may be unreleased plans, customer records, or internal strategy that never matches a classic PII regex. Semantic inspection lets teams classify what the agent is about to move based on meaning, destination, and invocation context. That is what makes inline enforcement possible when the payload is a synthesized answer rather than a file transfer. Without that capability, the control plane only reacts after the exposure has already happened.

Practical implication: prioritize semantic, inline inspection for MCP flows that touch high-value or context-rich data sources.

Threat narrative

Attacker objective: The attacker wants to use agent-connected tools to reach sensitive data or systems while avoiding the controls that normally detect direct exfiltration.

1. Entry occurs when an exposed or unauthenticated MCP server accepts anonymous requests or a malicious package is installed into the agent tool chain.
2. Credential or scope abuse follows when the agent inherits broad OAuth grants, static keys, or over-permissive tool access that was never constrained per connector.
3. Impact occurs when sensitive data is retrieved through tool invocations and leaves the environment as synthesized output or downstream action rather than a traditional file transfer.

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 has become an identity plane, not just an integration layer: Once an AI agent can invoke tools, every connector becomes a governed access path with its own authentication, authorization, logging, and revocation requirements. Security teams that treat MCP as a developer convenience will miss the fact that it behaves like a distributed NHI estate. The practitioner conclusion is straightforward: govern MCP the way you would any other production identity surface.

Legacy DLP assumptions break because the data no longer leaves in file form: The article shows why pattern matching is insufficient when sensitive information is synthesized inside tool responses. This creates an identity blast radius problem, where one over-permissive agent can reach many systems without tripping file-based controls. The practitioner conclusion is that monitoring has to move to the protocol and semantic layer.

Identity dark matter is the governance gap this article exposes: MCP connectors often exist through OAuth approvals, local installs, or team-owned integrations that never enter a central inventory. That means access can be real, active, and high-risk while remaining invisible to standard lifecycle and access review processes. The practitioner conclusion is to collapse discovery, ownership, and review into one control loop.

AI agent governance now depends on tool-level least privilege: The relevant question is no longer whether an agent has access, but whether each tool invocation is justified by scope and monitored as a discrete entitlement. That is why NHI governance and agentic AI governance are converging around the same operational model. The practitioner conclusion is that tool-level scope hygiene is now a baseline control, not an advanced one.

Continuous visibility must be designed before incident response can work: If MCP activity is not already flowing into identity, SIEM, and SOC workflows, investigators will not be able to reconstruct the chain of action after an agent-driven event. This is where governance becomes evidence quality. The practitioner conclusion is to make MCP telemetry a first-class log source before a breach proves why it matters.

From our research:

• While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility, according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, which leaves 48% without a complete compliance and investigation trail.
• That visibility gap is why teams should pair discovery with governance, as outlined in OWASP Agentic Applications Top 10 and Ultimate Guide to NHIs , 2025 Outlook and Predictions.

What this signals

Identity teams should expect MCP to move from a niche integration topic to a standard governance domain. As more AI agents gain tool access, the practical boundary between application security, IAM, and data security keeps shrinking. Programmes that do not assign ownership for MCP connectors will end up with shadow NHI estates that are hard to inventory and harder to revoke.

Tool-level governance will become the differentiator between visibility and control. Teams can discover connectors and still fail to manage them if they cannot map each invocation to a human owner, a business purpose, and a review cycle. That is where the governance model matures from observation to accountability.

With 92% of organisations in the SailPoint research agreeing that governing AI agents is critical but only 44% having implemented policies, the next failure mode is not awareness, it is operational drift. The control gap will widen fastest where agent activity is already embedded in day-to-day workflows and no one has made MCP telemetry part of the core security stack.

For practitioners

• Inventory every MCP server and connector Create a living register of every MCP server, endpoint, tool, owning team, and identity path. Include developer desktops, SaaS-native agent features, and any homegrown integration that was approved outside central IAM.
• Enforce authentication and scope hygiene for each connection Require SSO with MFA, validate session tokens against the identity provider, and eliminate anonymous sessions, shared credentials, and static keys that outlive their purpose.
• Define least privilege at the tool level Review every MCP tool as its own entitlement and re-evaluate permissions whenever the connector, integration, or owning business process changes.
• Centralize MCP traffic through a gateway Use a single enforcement point for authentication, authorization, rate limiting, and inspection so that MCP activity is not scattered across point integrations.
• Instrument MCP telemetry in the SIEM and SOC Make agent activity visible alongside endpoint, network, and identity logs so that incident response can reconstruct what happened across the full delegation chain.

Key takeaways

• MCP creates a governance blind spot because AI agent traffic can look like legitimate API activity while moving sensitive data through tool invocations.
• The exposure is already measurable, with public scans and protocol flaws showing that unauthenticated servers and over-permissive integrations are common.
• Security teams need protocol-level monitoring, per-tool least privilege, and identity-linked telemetry before MCP becomes an unrecoverable shadow access 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.
• AI-Native Endpoint DLP: AI-native endpoint DLP is data loss prevention that can inspect and control data at the point where users interact with AI tools, including browsers and desktop applications. It is designed to understand context, origin, and movement, not only static content patterns.
• Identity Dark Matter: Identity dark matter is the hidden mass of old grants, unused credentials, and inherited access that exists in an environment but is not actively understood. In NHI programmes it becomes dangerous because autonomous systems can discover and reuse it at machine speed.
• Tool-level least privilege: A permission model that grants access to individual tools rather than broad platform-wide capabilities. In MCP environments, this reduces blast radius by ensuring a server or agent can only invoke the specific actions needed for its task, not everything the platform can reach.

What's in the full article

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

• Step-by-step guidance for building a 10-step MCP monitoring programme across discovery, logging, and enforcement.
• Protocol-level inspection patterns for tool calls and responses that go beyond classic file-based DLP.
• Practical examples of gateway-based enforcement, SIEM integration, and AI-native DLP in MCP environments.
• The article's breakdown of common MCP deployment patterns across developer endpoints, SaaS tools, and custom integrations.

👉 Nightfall's full post covers the MCP monitoring blueprint, protocol-level inspection, and AI-native DLP details.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.