AI agent and MCP security need runtime data controls, not legacy DLP

At a glance

What this is: This is an independent analysis of Nightfall’s 2026 view of AI agent and MCP security, which says runtime data protection and purpose-built MCP governance are needed because legacy DLP was not designed for agentic workflows.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern data movement and tool use across AI agents, copilots, and MCP servers, where static controls and delayed review are often too slow.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Nightfall's full analysis of AI agent and MCP security platforms

Context

AI agent and MCP security now sits at the point where data governance, identity control, and runtime enforcement meet. As agents move information across SaaS, endpoints, browsers, and tool connections, the old assumption that inspection at the perimeter is enough no longer holds for AI agent and MCP security.

The practical gap is that many organisations still manage sensitive data with controls built for human users, not delegated software behaviour. That leaves exposure in prompts, tool calls, clipboard actions, downloads, and browser sessions, especially where MCP servers expand what an agent can reach without corresponding permission scoping.

Nightfall’s framing is typical of the market’s current direction: detection is only useful when it is paired with immediate enforcement, and agentic workflows make that distinction visible.

Key questions

Q: How should security teams govern agentic AI as it moves into production?

A: Security teams should govern agentic AI as a class of non-human identity, not as a generic application feature. That means assigning ownership, scoping permissions tightly, logging every tool action, and revoking access on a defined lifecycle. Production rollout should require clear approval points for high-risk actions and continuous monitoring for drift.

Q: Why do public MCP servers create risk for enterprise identity programmes?

A: Because they extend trust into third-party tool endpoints that may be poorly maintained, over-permissioned, or carrying embedded secrets. That creates an NHI and agentic control problem at the point where machines decide what to do next, which is exactly where traditional approval models are weakest.

Q: What do security teams get wrong about agent red teaming?

A: The biggest mistake is assuming a one-time prompt test gives meaningful coverage. Agent risk is stateful, and new tools or memory changes can reopen old weaknesses. Teams also underweight business impact, even though the real question is whether an attacker can trigger an unauthorized transaction, data exposure, or production change.

Q: How can organisations prove their AI controls are actually working?

A: Look for evidence that policy decisions are logged, sensitive prompts are being redacted or blocked when required, and approved AI interactions are traceable by identity and business context. Effective programmes produce audit-ready records, not just policy text. If the control cannot explain what happened in a session, it is not operational enough.

Technical breakdown

Why MCP security changes the data inspection model

Model Context Protocol gives agents a structured way to call tools and retrieve context from external systems. That means the security question is no longer only whether data is stored safely, but whether tool invocation, context propagation, and downstream actions are governed at the moment they occur. Traditional DLP and SaaS controls often inspect content after it has entered a channel, while MCP workflows can move sensitive data through local stdio or remote HTTP paths that are invisible to those controls unless endpoint, proxy, hook, or agent telemetry is added.

Practical implication: inspect MCP traffic at the tool and agent layer, not only at the network or SaaS layer.

Runtime data protection versus alert-only controls

Runtime protection changes the enforcement posture from observe-and-escalate to block-and-contain. In AI agent workflows, that matters because a sensitive prompt, attachment, or response can be copied, transformed, and relayed before a human reviews the alert. Controls that can redact, revoke, quarantine, delete, or encrypt data in the same session close the gap between detection and impact. Alert-only workflows are still useful for investigation, but they do not stop the first bad transfer from happening.

Practical implication: prioritise controls that can intervene in-session, especially for prompt, file, and clipboard exfiltration.

Why AI-native detection matters for agentic workflows

AI-native detection uses machine learning and language models to classify sensitive data in context rather than depending only on static patterns. That is important because agentic workflows often mix code, natural language, screenshots, copied snippets, and transformed content in the same path. If detection cannot separate legitimate business activity from risky movement, teams either miss exposure or generate so many false positives that policy becomes unenforceable. The technical challenge is contextual classification at speed, across heterogeneous interfaces and data types.

Practical implication: test whether your detection stack can classify sensitive data in mixed AI workflows before relying on it for policy enforcement.

NHI Mgmt Group analysis

Runtime enforcement is now the decisive control plane for AI agent data security. The article correctly places the emphasis on what happens during the transaction, not after the fact. Agentic workflows compress decision, retrieval, and transfer into one execution path, so a delayed response is often a failed response. For IAM and NHI programmes, that means policy has to follow the session, the tool call, and the data movement together.

AI agent and MCP security expose a governance blind spot that legacy DLP never had to solve. Traditional DLP was built around content and channel inspection, while MCP adds delegated tool use and richer context propagation. That creates a new control problem: the platform must understand not only what data is moving, but why the agent is moving it and what it is allowed to do next. Practitioners should treat this as a change in governance scope, not just a tooling upgrade.

Tool permission scoping is the named concept that should anchor MCP governance. If an MCP server can expose broad tool access without explicit scoping, the agent inherits reach it should never have had. That is a governance failure, not an optimisation issue. Organisations should map MCP tool permissions to least privilege, short-lived access, and auditable delegation boundaries so that agent behaviour remains bounded by policy.

Corporate versus personal session differentiation will become a core identity control in AI workflows. When users operate across personal and managed accounts in the same browser or agent session, data can cross trust boundaries without any obvious malicious act. This is where identity governance intersects with data loss prevention: the control must understand session context, account type, and destination risk. Security teams should expect this to move from niche capability to standard requirement as agent adoption grows.

Red teaming is useful only when it feeds control design and enforcement. Prompt injection tests, jailbreak simulations, and multi-turn agent exercises are valuable because they reveal where policy breaks under realistic pressure. But the real value comes when findings are translated into allowlists, blocking rules, redaction policies, and exception handling. Without that link, red teaming becomes reporting rather than risk reduction.

What this signals

Agentic workflows are turning data governance into a runtime discipline. Security teams should expect policy engines, browser controls, and identity boundaries to converge as agents become common in SaaS and developer workflows. The practical programme change is to treat prompt paths, tool calls, and browser sessions as first-class control surfaces rather than edge cases.

AI agent and MCP security will increasingly sit alongside NHI governance. As soon as agents can move data and call tools on their own, they behave like governed non-human actors, even when a human initiated the session. That makes identity context, least privilege, and session scoping essential to both NHI policy and broader access control design.

The next control gap will not be lack of visibility but lack of actionable containment. Teams that can only observe agent activity will still struggle to prevent exposure, while teams that can enforce policy in real time will be able to absorb agent adoption without widening the breach window.

For practitioners

• Implement runtime enforcement for agent data flows Prioritise controls that can block, redact, quarantine, or revoke data while the AI agent is still in-session, especially across prompts, file transfers, and browser actions.
• Scope MCP tool permissions to least privilege Review every MCP server connection for explicit tool scoping, and remove broad or inherited permissions that allow agents to reach systems beyond their intended task.
• Separate corporate and personal sessions Detect and enforce account-boundary rules so that uploads, downloads, and prompt activity in personal sessions cannot reach managed storage or approved enterprise workflows.
• Test mixed-mode detection before production rollout Validate whether your stack can classify sensitive data in prompts, screenshots, copied text, and transformed outputs, not just in files and emails.
• Translate red-team findings into policy changes Use prompt-injection and multi-turn agent tests to update allowlists, blocking rules, and exception workflows rather than treating testing as a standalone exercise.

Key takeaways

• AI agent and MCP security are reshaping data governance because runtime action now matters more than after-the-fact review.
• The evidence points to a real control gap: agents already exceed scope, and many organisations still cannot fully audit what they accessed.
• Practitioners should move from visibility-first thinking to session-level enforcement, least-privilege tool scoping, and policy-driven containment.

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.
• Runtime data protection: Runtime data protection is the practice of classifying, controlling, and, when necessary, stopping sensitive data while it is actively moving through a system. For AI workflows, that means enforcement must happen during prompts, tool calls, uploads, and downloads, not only in retrospective logs.
• Session differentiation: Session differentiation is the ability to distinguish one trust context from another, such as personal versus corporate accounts or managed versus unmanaged browsers. It matters because AI workflows can move sensitive data across boundaries that look harmless to users but are significant for governance and compliance.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

What's in the full article

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

• Product-specific deployment guidance for SaaS, endpoint, browser, and MCP coverage.
• Control examples for block, redact, revoke, quarantine, and encrypt actions in live workflows.
• Implementation notes on AI-native detection, session differentiation, and policy tuning.
• Customer-facing workflow coverage details for Copilot, Claude, Gemini, and other AI tools.

👉 Nightfall's full report covers platform capabilities, workflow coverage, and enforcement detail for AI agent security teams.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity governance to modern agentic workflows and operational risk.