Data Leakage Prevention Policy for AI Agents

Traditional data loss prevention tools were built to watch files and emails move between known endpoints, scanning content in transit for patterns that match a sensitive field: a social security number, a credit card string, a document tagged confidential. That design assumes data moves in packages you can inspect one by one. An AI agent doesn't work that way. Its leakage path runs through natural language prompts, model outputs, calls to tools over the Model Context Protocol, and retrieval responses pulled from internal systems, none of which a conventional DLP engine reads or parses.

The mismatch is architectural. The NSA's May 2026 advisory on MCP security names the core shift directly: MCP reverses the client-server pattern security teams have spent two decades building controls around. Servers now query and execute on behalf of clients, and that reversal opens attack paths that are new and, in most environments, untraced. A firewall built to watch for a known endpoint sending a known data type to another known endpoint has nothing to say about an agent deciding, mid-task, to call a tool nobody provisioned it to call.

Most enterprises today have DLP coverage, but it handles yesterday's data flows well and misses today's. Kiteworks found that half of all organizations still have no enforceable data protection policy for AI applications. The count of employees using generative AI tools has tripled, data policy violations have doubled in the same stretch, and the average enterprise now logs 223 AI-related data security incidents every month. Closing that gap means building a DLP policy around the agent's actual threat surface, not around the files-and-email model it replaces. That's the rest of this piece.

The four MCP-specific vectors a DLP policy must account for

Agents connected through MCP leak data through four distinct paths. Each one leaves a different signature. A policy that treats them as a single problem will catch none of them well.

Tool poisoning is the hardest of the four to catch because it never breaks a visible rule. Every MCP tool ships with a plain-text description that the agent reads to decide what to do next. Microsoft's research showed how attackers exploit exactly that: they bury instructions inside the description itself, and the agent follows them as if they were part of its legitimate task. The MCPTox benchmark tested this against real MCP servers and real models, and success rates were high because models almost never said no to the embedded instruction. This isn't a lab curiosity. The Agentjacking case tied to the Sentry MCP integration, disclosed in June 2026, found 2,388 organizations running injectable DSNs, and testing by Tenet achieved a high rate of successful agent execution against them. Sentry declined to remediate the underlying issue and shipped only a filter on payload strings, a patch narrow enough that the core exposure remains open.

Prompt injection works on a related mechanism but through a different door: untrusted content sitting in the agent's context window redirects what the agent does next. The risk compounds in multi-agent setups, where one agent's output becomes the next agent's input. An injected instruction planted early in that chain can travel through several agents without any single one of them positioned to catch it.

Supply chain compromise hides malicious behavior inside packages that look like ordinary MCP servers. Antiy CERT later confirmed a large volume of malicious skills circulating across ClawHub, and at its peak about one in five packages on the OpenClaw marketplace was malicious. This vector differs from a standard software supply chain attack in a specific way: a compromised MCP server has direct access to enterprise systems by design, so a bad package doesn't just break a build. It reaches production data directly.

Intent drift and context leakage require no attack. The NSA advisory flags context sharing as a systemic risk on its own: context windows that live too long or overlap across tasks can leak data, blend unrelated tasks together, or misalign what the agent believes it's authorized to do. Security researchers describe the underlying condition as a "lethal trifecta," meaning an agent that has access to private data, exposure to untrusted content, and the ability to act on external systems all at once. Most MCP infrastructure today enforces no permission boundary that would keep that combination from turning into a leak. Drift is hard to catch because each step the agent takes can be fully authorized on its own.

Why the authentication gap is where most agent leakage starts

Most MCP servers running in production today have no meaningful authentication behind them, and that single fact undermines every behavioral policy layered on top. A policy that tries to decide whether a given action is appropriate can't do that job reliably if it doesn't first know, with certainty, who or what is making the call.

The numbers describe a near-universal default. NimbleBrain's analysis of the MCP server registry found that only a small minority of servers use OAuth. The rest run on static API keys or no authentication whatsoever. These weren't misconfigured edge cases. They were the standard deployment pattern, running exactly as built.

The CVE record backs this up. The Azure MCP Server Authentication Bypass, tracked as CVE-2026-32211 with a CVSS score of 9.1, let an attacker reach configuration details, API keys, and authentication tokens with no valid credentials required. Dozens of CVEs have now been filed against MCP implementations, including a CVSS 9.6 remote code execution bug in the mcp-remote npm package. OAuth 2.1 is the authentication standard the protocol was built around, and it's well specified. Adoption is the problem: the gap between what the spec allows and what teams actually deploy is where most of these attacks succeed.

The July 2026 MCP spec update, dated 2026-07-28, hardens authorization considerably: OAuth 2.1, Resource Indicators under RFC 8707, issuer verification, and PKCE. None of that hardening helps a deployment that hasn't adopted it, and only a small minority of organizations currently route their agentic MCP infrastructure through their existing IAM or identity provider as an authorization server. Static API keys remain the default across most deployments, and they carry three problems at once: they don't expire, they can't be scoped to a specific task, and they keep working long after the developer who issued them has left the company. Palo Alto Networks' research puts the machine identity ratio at roughly 109 machine identities for every human employee, and most of them are AI agents. At that ratio, no security team can manage credentials by hand, regardless of headcount.

A DLP policy that can't first resolve who's calling has to treat every caller as a potential threat, and that's the technically correct posture but not a sustainable one without real identity infrastructure behind it. The problem compounds in multi-agent systems: when one agent invokes another, trust shouldn't automatically carry over from the first to the second. Agent B shouldn't inherit Agent A's permissions unless that inheritance was explicitly granted, but most current implementations enforce no such boundary, so privilege can escalate quietly across a chain of calls.

Fixing this starts with giving each agent its own identity rather than routing it through a shared service account. A shared account collapses every agent's queries into one combined set of privileges, erasing the real boundary of what any individual user or agent should be able to see. If you tie per-agent identity into the enterprise directory through SSO and SCIM, that boundary stays intact, and when an employee offboards, every agent credential tied to their identity gets revoked automatically instead of sitting active indefinitely.

Credentials should also be issued just in time rather than standing permanently. Tokens sitting in an agent's runtime memory during execution are a documented target for exfiltration, and issuing credentials only when a task needs them shrinks that window substantially. Most agents today get issued tokens with broad read or write access across an entire system, mainly because the developer who provisioned the agent didn't know in advance what narrower scope it would need. A just-in-time model forces that scoping decision at the moment of issuance, not after the fact.

For any remote MCP server that implements authorization, OAuth 2.1 with PKCE is the spec-compliant baseline: every endpoint over HTTPS, authorization server metadata discoverable, Protected Resource Metadata under RFC 9728 exposed, and Resource Indicators under RFC 8707 validated so a token issued for one resource can't be replayed against another. The July 2026 spec update adds issuer verification and revised extension handling on top of that baseline, so it closes confused-deputy risks that deployments running the older spec still carry.

The NSA advisory also recommends a filtering outgoing proxy, or an enterprise DLP tool configured to do the same job: restricting which external resource URLs and access methods an MCP connection can reach, so data can't exit the environment through a path nobody reviewed. And because most MCP servers request far broader permissions than their stated function needs (a calendar-read server asking for write access to Drive, Gmail, and the Admin Console is a routine pattern, not a rare misconfiguration), policy should require every server's declared permissions get checked against what it's actually supposed to do before it's approved for production.

Platforms built for this problem build OAuth, credential handling, and just-in-time issuance into the infrastructure itself instead of leaving it as something a security team bolts on server by server, so these identity requirements get a real operational home instead of a checklist nobody enforces.

Enforcing policy at tool-call depth rather than at the perimeter

Firewalls and perimeter tools stop traffic at the boundary of the agent's environment, but sensitive data isn't selected, assembled, or sent at the boundary. That happens inside the tool call itself. When an MCP server reads 10,000 customer records and sends them to an external endpoint, the outbound traffic looks like a normal HTTPS connection from a server that's supposed to be making requests. A perimeter firewall has no reason to flag it.

Tool poisoning attacks are built to exploit exactly that blind spot. Reading a file, calling an API, sending a result: each of those steps is individually authorized and looks unremarkable on its own. The violation only exists in the combination, and only a control point that can see the full sequence of tool calls, not just the connection at the edge, has any chance of catching it. The NSA advisory names a related problem directly: agents can call new tools at runtime that weren't part of the scope anyone approved when the session started. A policy written at the start of a session has no way to account for a tool the agent decides to invoke halfway through a task.

Enforcing policy at that depth means building controls that live inside the tool-call sequence rather than at the network edge. That starts with tool allow-listing, so an agent can only invoke tools explicitly approved for its task rather than whatever it discovers at runtime. You also need to inspect tool descriptions themselves before an agent acts on them, because that's where tool poisoning hides its instructions in plain text. It requires behavioral analysis across the sequence of calls an agent makes in a session, not just each call in isolation, since intent drift and multi-step tool poisoning appear only in the pattern across calls. And it requires the audit trail to tie every single tool call back to a specific, authenticated agent identity, giving a clear record of exactly which agent did what, with which credentials, at what moment, when the sequence does look wrong.

Permission scoping means nothing if every agent is calling through the same shared service account. Behavioral detection across a session means nothing if there's no reliable way to attribute each call to the agent that made it. That's the throughline across the whole policy: a DLP program for AI agents has to detect tool poisoning, prompt injection, supply chain compromise, and intent drift in real time, enforce policy at the depth of the individual tool call rather than at the network boundary, and tie every one of those calls to an identity that was authenticated before the call was ever made, which is what an MCP gateway like Runlayer enforces at the point of each tool invocation.