What is agent DLP?

By Nolan Sullivan, Founding Growth Engineer

·Published August 20, 2026

Agent DLP exists because the data-loss prevention an organization already runs cannot see the path AI agents take. The endpoint DLP on a developer’s laptop records that Cursor is an approved application. It does not see that the GitHub Model Context Protocol (MCP) server wired into it just returned a .env file full of production keys from a get_file call, and it does not see that file leaving in the next tools/call to a model hosted outside the tenancy. The same holds for the refund tool that returns a full card number into a support agent’s context window. Every control the security team currently operates watches a channel these payloads never cross.

The Cloud Security Alliance made visibility the starting point of its April 2026 research note, The AI Agent Governance Gap: What CISOs Need Now: organizations cannot govern what they cannot see, and in the survey the note cites, 92% of 235 large-enterprise CISOs and CIOs said they lack full visibility into their AI agent identities. An agent inventory and shadow AI discovery are the controls that get an organization to seeing. Agent DLP is the control that applies once the payload is visible: it decides, call by call, what is allowed to leave.

Why does classic DLP never see the tool call?

Classic DLP, CASB, and SSE products classify content on the channels they proxy. Email DLP reads outbound mail. Web DLP inspects uploads through the forward proxy. Endpoint DLP watches file copies, clipboard events, and removable media. Each of those is a real control on the channel it covers, and none of those channels is the one an agent uses.

Agent traffic has a different shape. The harness exchanges JSON-RPC messages with MCP servers, some over STDIO on the laptop itself, some over HTTPS to internal or third-party hosts. The model call is an HTTPS POST to an API domain the organization has approved. From the vantage point of a CASB, that is a sanctioned application talking to a sanctioned domain over TLS, which is exactly the traffic it is configured to allow. The payload of a tools/call, meaning the tool name, the arguments, and the result, is never inspected by any of these products, because none of them terminates the call.

The gap is structural rather than a missing signature. Data that leaves through an agent never has to touch a file, an email, or a browser upload. It moves from a tool result into model context in a single call, inside a session the endpoint sees only as an approved process making approved connections.

What can an AI agent leak?

Payload inspection matters because agents concentrate sensitive data in places no other system does. These are the surfaces to inspect:

• Prompt context. Whatever the user pasted in, plus whatever the harness added: system prompt content, project rules, and prior turns. A pasted customer email thread carries every address and account number in it.
• Tool results. A get_file call against a repository returns a .env with live credentials, or a source file with a personal access token committed in it. A refund-lookup tool returns the full primary account number because the API behind it was built for a settlement system, not for a chat window.
• MCP resource reads. An internal HR server returns an employee record, salary included, because the agent asked a reasonable question and the server had no policy telling it to refuse.
• Conversation memory. A record read in one session persists and resurfaces in a later session with a different task and a different audience.
• Files the harness attached. Coding agents attach repository files to the context automatically, and other harnesses attach the spreadsheets and documents a user dropped in. Attachment is implicit, so nobody made a decision to share.

Each of these enters the context window, and everything in the context window leaves in the next model call. The leak path is two hops long, tool to context and context to model, and both hops are invisible to channel-based inspection.

Where does agent DLP have to run?

Enforcement has to sit on the path between the agent and every model, tool, and MCP server it talks to, because that is the only place where the full payload and the caller’s identity exist at the same time. In practice that point is an MCP gateway. The gateway terminates each tool call, which gives it three things a scanner reading logs after the fact never has: the arguments before they are forwarded, the result before it enters the agent’s context, and the ability to block or redact rather than report.

Inspection has to run in both directions. Outbound, the arguments of a tools/call are what the agent is sending to a server, and they can carry anything currently in context. Inbound, the result is what will sit in context and leave in the next model call, so redacting a card number at the result is what keeps it out of every subsequent payload.

Traffic that never crosses the gateway needs a second sensor. Agents on developer laptops can reach STDIO servers directly, which is why hook-based discovery on the endpoint, covered in what is shadow AI, complements the gateway: it finds the paths that bypass the enforcement point so they can be brought onto it.

Agent DLP vs classic DLP vs prompt injection vs MCP security: what’s the difference?

These four terms come up in the same vendor conversations and govern different things.

Prompt injection is how an attacker hijacks an agent. Agent DLP is what the agent is allowed to exfiltrate even when it is behaving exactly as instructed. The two controls compose: injection defense reduces the chance of a hijack, and DLP bounds what any hijack, or any honest mistake, can carry out.

MCP security is the wider checklist, six controls a security team requires before signing off on MCP in production. Agent DLP is the data-in-motion piece of the sixth control, inspection at the tool boundary. The other five, authentication, inventory, allowlists, audit logging, and the shadow-MCP kill path, are covered on that page.

What does a useful agent DLP policy look like?

A workable policy is organized around data classes rather than tools. Whether an agent may call a destructive tool is an authorization question, answered with RBAC and tool allowlists. DLP answers a different question: given that this call is authorized, does its payload contain a class of data that may not leave? The classes that recur are secrets, payment data, personal identifiers, government identifiers, healthcare records, and source code.

Each class gets an action:

• Redact when the rest of the payload is still useful. A support transcript with the card number masked still answers the question.
• Block when any disclosure is unacceptable, such as a private key or a government identifier bound for an external model.
• Log only while tuning, so the team sees what a rule would catch before it interrupts anyone.

Rollout order matters more than rule count. Policies that start in log-only mode surface the false positives, such as documentation samples, published test credentials, and internal identifier formats that pattern matchers mistake for the real thing, and those get excluded before enforcement turns on. A policy that blocks on day one trains engineers to route around the gateway, which removes the control entirely.

Gateway vendors split on where the detection engine lives. MintMCP runs customer-authored middleware on each call and integrates external engines such as AWS Bedrock Guardrails, Google Model Armor, and Teleskope. Runlayer ships its own PII and secret detection, compared feature by feature in Speakeasy vs Runlayer. The architecture question to ask any vendor is the same: does inspection run in-path on every tool call, with block and redact available as outcomes, or does it produce findings after the data has already left?

How does the Speakeasy AI Control Plane enforce agent DLP?

The Speakeasy AI Control Plane runs detection in-path. Agents reach tools through the platform’s MCP gateway, so every session and every tool call crosses a point that scans it in real time with the caller’s identity attached, and PII and credentials are blocked or redacted before they leave the environment.

• The detector catalog covers the data classes above. Built-in detectors cover secrets (API keys, tokens, private keys), financial data (card numbers, bank accounts, routing numbers, IBAN codes), personal identifiers (phone numbers, email addresses, IP and MAC addresses), government identifiers across US, UK, EU, and APAC formats, and healthcare records, plus custom patterns for organization-specific formats. The full catalog is in the detection rules docs.
• Scanning covers all four surfaces. Risk policies evaluate user prompts, assistant messages, tool calls, and tool responses. Detection scope is set per category with CEL expressions that match by server, by function, or by drilling into a call’s arguments, so a policy can watch shell tool calls for exfiltration while watching prompts for secrets.
• Actions follow the rollout order above. Policies audit by default. Enforcement is opt-in per policy: warn and require an acknowledgement, or deny the call outright. A blocked user can request a bypass through an RBAC-protected approval flow, so an exception is scoped to one policy or resource, attributable to an approver, and revocable.
• Contextual risk gets a judge instead of a regex. Prompt-based policies describe a behavior in plain language, such as external data transfer, and an LLM judge evaluates each in-scope message, with a replay-and-scorecard workflow that validates the guardrail against live traffic before it enforces anything.
• Findings stay useful without becoming a second leak. Every finding lands in the risk-event log with the matched content redacted by default, feeds the risk analytics dashboard, and ties back to the full session transcript and the audit log for investigation.

Detection ships with the platform and runs on every call the gateway carries, rather than as a third-party engine wired in per call. To see what these policies would have caught in your agent traffic last week, talk to us.