AI Agent DLP: How to Stop Data Leaking Through Agent Tool Calls and MCP

AI agent DLP is data loss prevention built for autonomous AI agents. It follows sensitive data from the tool that returns it to any tool that could send it outside your organization, and it allows, redacts, blocks, or holds that flow for approval before the outbound call runs. Prompt-based DLP cannot do this, because no employee types anything an agent leaks.

In September 2026, Zenity Labs disclosed SalesBleed, a set of flaws in Salesforce Agentforce that let an attacker steal CRM data without anyone clicking a link. The attacker hid instructions in a lead submitted through a public Web-to-Lead form. When a salesperson later asked Agentforce to review the lead, the agent read lead and account records with its own tools and leaked them through the DNS lookup triggered when its reply rendered an image. Salesforce had added a trusted-URL allowlist after a near-identical attack, ForcedLeak, the year before. SalesBleed got around it.

The cost of getting this wrong is already measurable. IBM's 2026 Cost of a Data Breach report found that 21% of breached organizations reported an AI-related security incident, up from 13% a year earlier, with those incidents averaging USD 5.33 million.

In this guide, we cover:

• Which agent tools can carry data out of your organization
• Why URL allowlists and AI guardrails keep failing against these attacks
• How sensitive data moves from one tool call to the next
• How to write enforceable rules that stop a leak before the outbound call runs

If your concern is employees pasting sensitive data into AI chat tools, our guide to AI DLP for prompts and uploads covers that separately.

Key Takeaways

- AI agent data leaks happen when one tool's output becomes another tool's input, with no employee typing or pasting anything.

- In 2026, researchers showed enterprise data could be exfiltrated through search features, image rendering, link previews, and DNS lookups.

- URL allowlists repeatedly failed because attackers routed stolen data through destinations the organization already trusted.

- Effective AI agent DLP enforces rules on data flows (what the data is, where it is going, and who the agent acts for) before a tool call executes.

- Every vendor fix in 2026 closed one exit rather than the whole attack class, so agent exit paths need continuous testing.

What Is AI Agent DLP?

AI agent DLP (data loss prevention for AI agents) is a set of controls that tracks sensitive data from the tool that returns it to any tool that could send it outside your organization. Before the outbound call executes, it decides whether that flow should be allowed, redacted, blocked, or held for human approval. It exists because autonomous agents move data between systems on their own, at machine speed, without an employee typing or pasting anything a traditional control could inspect.

Consider an agent working a single support ticket. It might query a CRM, summarize a contract from a document store, check a shipping status through an API, and post a reply to the customer. Each of those steps is a tool call.

Some of those tools are sources, because they return sensitive records into the agent's context. Others are sinks, because they can place data somewhere an outside party can read it. AI agent DLP governs the path between the two, whichever tools the agent happens to choose along the way.

Definition: Sink. A sink is any tool, feature, or channel that can place data where someone outside your organization can read it. Email, webhooks, and file uploads are obvious sinks. Search requests, rendered images, link previews, and DNS lookups are sinks too, and that is exactly why they are so often missed.

How Is AI Agent DLP Different From AI DLP and MCP Security?

The three controls answer different questions:

• AI DLP protects what employees type and upload into AI tools.
• MCP security governs which agents and servers are trusted to connect to your systems.
• AI agent DLP governs where data moves between tools once that access has been granted.

An organization that deploys only one of them leaves the other two questions unanswered.

Control	Question it answers	What it inspects	Gap if it is missing
AI DLP	What are people sending to AI tools?	Prompts, file uploads, model responses	Employees paste sensitive data into AI chat tools unchecked
MCP security	Which agents, servers, and tools are trusted?	Server identity, authentication, tool permissions	Unvetted or unauthenticated servers connect to enterprise systems
AI agent DLP	Where does sensitive data go after the agent reads it?	Tool results, tool arguments, rendered output, outbound destinations	An authorized agent reads data legitimately and sends it out through an approved tool
Traditional DLP	Is a known pattern leaving through email, web, or endpoints?	Files, email, network traffic	Agents rewrite, encode, and route data through channels it does not inspect

This guide focuses on the last row, because it is the failure behind every incident in the next section. In each one, the agent was allowed to read the data, and it was allowed to call the tool that leaked it.

How Do AI Agents Leak Data Through Tool Calls and MCP?

AI agents leak data by reading sensitive records with one tool and passing them out through another. The exit is often a tool nobody classified as outbound. In the incidents documented in 2026, the exits included enterprise search, image rendering, Slack link previews, DNS lookups, approved MCP servers, and even the MCP server software itself.

Most of these cases follow the same pattern. The agent first reads content an attacker can influence, such as a form submission, a log entry, a URL, or a tool description. This technique is known as indirect prompt injection. The hidden instructions tell the agent to gather data and send it somewhere. The agent complies using tools it is legitimately allowed to call, so the leak looks like ordinary work. For the full mechanics of this attack class, see our guide to prompt injection.

Security teams tend to miss these leaks because they only watch one type of exit. There are three:

Sink type	Examples	Why security teams miss it
Explicit	Email, webhooks, HTTP requests, file uploads	Needed for legitimate work, so broadly allowed
Disguised	Search queries, rendered images, link previews, DNS lookups	Not recognized as outbound channels at all
Trusted	Approved MCP servers, the vendor's own infrastructure	Already allowlisted, so the traffic is never questioned

Can a Search Tool Leak Company Data?

Yes, a search feature can be turned into an exfiltration channel. In June 2026, Varonis Threat Labs disclosed SearchLeak (CVE-2026-42824), a vulnerability chain in Microsoft 365 Copilot Enterprise Search. One click on a crafted Microsoft link was enough to exfiltrate a user's emails, MFA codes, calendar events, SharePoint documents, and OneDrive files.

The chain had three steps:

1. The attacker's instructions arrived through the search URL's q parameter, which Copilot treated as a prompt.
2. An HTML rendering race condition fired an attacker-controlled image tag before output sanitization finished.
3. A Bing server-side request forgery routed the stolen data through Microsoft's own infrastructure, which the page's Content Security Policy trusted.

The victim saw Copilot "thinking" for a moment and nothing else. Microsoft fixed the issue server-side in early June 2026, and Varonis reported no evidence of exploitation in the wild.

The lesson for DLP is that a search request is an outbound channel. If an agent can write arbitrary text into a query string, it can write your data there too.

Can Rendering an Image or Link Preview Leak Data?

Yes. Rendering an image is one of the most common exfiltration paths in agent attacks, because the image forces a network request to whatever address the agent wrote.

In April 2026, Noma Security disclosed GrafanaGhost. Hidden instructions were planted in stored content, such as log entries, that Grafana's AI assistant later processed. The assistant was tricked into rendering an external image whose URL carried sensitive data. Grafana did check image URLs, but the check accepted protocol-relative addresses that began with //, so an attacker's domain passed as safe. The exfiltration ran automatically with no user interaction, and to anyone watching it looked like routine dashboard visualization. Grafana has since fixed the issue.

SalesBleed applied the same principle with even less. The stolen data sat inside a hostname, so the DNS lookup for the image delivered it to the attacker's DNS server even if no web request ever completed. A Slack link preview of the same hostname did the same. Filtering outbound web traffic does not help when the data travels in the DNS lookup and never needs an HTTP request.

Can an Approved MCP Tool Leak Data?

Yes. In June 2026, Microsoft Incident Response and its Defender research team documented an attack on an MCP tool used in a finance workflow:

• An attacker silently modified the tool's description, leaving its name and user-facing summary unchanged.
• An analyst asked a routine question about a supplier.
• The agent followed the hidden instructions, collected financial records beyond the scope of the request, and forwarded them as part of the tool's normal enrichment call.

The query ran with the analyst's own permissions. The outbound call went to a server that had been allowlisted when it was added. Microsoft concluded that the vulnerability lived in the trust boundary between systems, not in any single one. Our MCP security enterprise guide covers this tool-poisoning pattern in depth.

The same risk applies when the server itself is malicious. In September 2025, a copycat npm package called postmark-mcp shipped 15 clean releases and then added a single line in version 1.0.16 that blind-copied every email sent through it to an attacker's address. The agent's arguments were exactly what the user intended. The server leaked them anyway. Unvetted and unauthenticated servers are covered in why 40% of MCP servers have no authentication.

Can an MCP Server Leak Data Without an Attacker?

Yes. On October 20, 2026, the maintainers of the official MCP TypeScript SDK published CVE-2026-111770 (CVSS 7.7). It describes MCP servers reached over HTTP delivering one client's responses and notifications to a different client.

The cause was ordinary. Messages were matched to connections by JSON-RPC request ID alone. SDK clients number their requests from zero, so IDs collide in normal use whenever several clients share one server or transport instance. An earlier advisory, CVE-2026-25536, described a similar cross-client leak in SDK versions 1.10.0 through 1.25.3.

This kind of leak needs no prompt injection and no attacker. A server created once at startup and shared across users can hand one customer's tool output to another. The fix is to create a new server and transport for each request or session.

Why Don't URL Allowlists Stop AI Agent Data Exfiltration?

URL allowlists check where data is going, but the attacks above routed stolen data through destinations the organization already trusted:

• ForcedLeak (2025) used a domain on Salesforce's allowlist that had expired and could be re-registered for about $5.
• SalesBleed (2026) got past Salesforce's newer Trusted URLs control using domain suffixes it did not recognize and characters that broke its URL parsing.
• SearchLeak (2026) sent data through Bing, which Copilot's Content Security Policy allowed by design.

In each case the allowlist did what it was built to do, and the data left anyway. An allowlist can only answer "is this destination approved?" It cannot answer "is this data allowed to go there?", and that is the question that matters. For why perimeter and pattern-based tools miss this class of attack more broadly, see why AI requires a new security layer beyond traditional controls.

Every incident in this section has since been patched. Each fix closed one channel, and the next disclosure found another. Controls that depend on knowing every exit in advance will keep losing to the exit nobody listed.

What Does an AI Agent Data Leak Mean for Compliance?

An agent leak is a data breach in the eyes of regulators, even when no person did anything wrong. The notification clocks start the same way:

• GDPR: a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it (Article 33).
• HIPAA: affected individuals must be notified without unreasonable delay and no later than 60 days after the breach is discovered.
• India's DPDP Act: breaches must be reported to the Data Protection Board and affected individuals. See our guide to DPDP compliance for AI prompts, agents, and logs.
• SOC 2: auditors expect evidence that controls operated, which means a record of every agent data flow your policy allowed or blocked.

The hard part is not the deadline. It is proving what left, when, and through which tool. If your logs show only that an agent made an "authorized" search call, you cannot scope the breach, and every one of these frameworks assumes you can.

How Do You Find Every Sink in Your Agent Stack?

Start with an inventory of every tool each agent can call, then mark each one as a source, a sink, or both. A tool counts as a sink if it can do any of the following:

• write text into a URL, query string, hostname, message, email, or file
• render content that the user's browser or chat app will fetch
• send data to a destination of its own choosing, as an MCP server can

Most teams find their sink count is several times larger than they expected, because search tools, summarizers that produce markdown, and chat integrations with link previews all qualify.

Record the result as a sink register: tool name, the agent that uses it, whether it is explicit, disguised, or trusted, and the data labels it is allowed to receive. Re-run the inventory whenever an agent gains a tool or an MCP server changes version. This register is what your DLP rules in the next sections are written against.

How Does Sensitive Data Move From One Tool Call to the Next?

Data returned by a tool stays in the agent's context and keeps its sensitivity, even after the agent summarizes, translates, or reformats it. A later tool call can then carry it out whole, split across several calls, or encoded so that pattern-based DLP no longer recognizes it. This is why inspecting each tool call in isolation is not enough. The risk comes from the combination of what the agent read earlier and where it is sending data now.

Traditional DLP looks at one payload at a time and asks whether it contains a credit card number or a known sensitive keyword. An agent breaks that model in three ways:

• Transformation. The agent rewrites what it read, so a customer record becomes a sentence that matches no pattern.
• Encoding. The agent can percent-encode, base64-encode, or pack data into a hostname, as SalesBleed did.
• Splitting. The agent can send a little data per call across many calls, so no single call looks alarming.

Can Encoding Hide Data From DLP?

Yes. If a DLP control inspects the raw argument of a tool call without decoding it first, an encoded email address or account number passes straight through. Effective inspection normalizes the argument before checking it: it decodes URL and base64 encodings, reassembles hostnames, and strips invisible Unicode characters. Our comparison of keyword, pattern, and intent-based scanners explains why pattern matching alone misses rewritten or encoded data.

Can an Agent Leak Data Across Several Calls?

Yes. A leak split across many calls is designed to stay below the threshold any single inspection would flag. SalesBleed shows why attackers do this. Each prompt could only send out as much data as fit into one subdomain string, but a single poisoned lead could be triggered again every time an employee asked Agentforce to review it. Many small, repeated leaks add up to a large one.

The control for this is a per-session data budget. The policy tracks how much labelled data an agent has sent to a given destination over a whole session, and stops the session once that total crosses a limit, even when each individual call is small.

What Does Tracking Data Across Tool Calls Look Like?

The trace below shows the method. A label attached when sensitive data first enters the agent's context follows that data until it reaches a sink, where the policy decides what happens.

session=agt-7f3a  agent=sales-assist  acting_for=user:a.mehta  role=sales_rep

call 1  crm.query_leads(filter="created:last_7d")
        result → 12 records  label=CRM.PII  (name, email, phone, deal_size)

call 2  summarize(input=call_1.result)
        context → label=CRM.PII retained  (rewritten as prose)

call 3  web.search(q="lead%20review%20a.rao%40acme...%2Bdeal%3D480k")
        argument decoded → matches CRM.PII from call 1
        sink_class=disguised (search)

decision  BLOCK
reason    labelled data CRM.PII → disguised sink, no approved flow
alert     sent to SIEM  ·  session held for review

This is how LangProtect Vector evaluates the session. No single call here looks malicious on its own. The leak only becomes visible when the control remembers what call 1 returned and recognizes it, decoded, inside call 3.

A label is the sensitivity tag a control attaches when data enters the agent's context, taken from the source system's classification (such as a CRM's customer records), your data classification policy, or a detector that recognizes personal data or secrets in the tool result.

How Do You Set DLP Rules for AI Agent Tool Calls?

Write rules on data flows, not on single payloads. Each rule combines three facts:

• what the data is
• where it is going
• who the agent is acting for

Then it chooses one of four outcomes: allow, redact, block, or hold for human approval. A rule written this way still holds when an attacker finds a new exit, because it governs where labelled data may go rather than listing destinations to block.

Data label	Sink	Acting for	Outcome
CRM.PII	Search or web lookup	Anyone	Block
CRM.PII	Email to the record's own contact	Account owner	Allow
CRM.PII	Email to a new external recipient	Anyone	Hold for approval
Financial records	Approved MCP enrichment server	Finance analyst	Redact to the fields the task needs
Secrets or credentials	Any external sink	Anyone	Block and alert
Any labelled data	Rendered image or link in agent output	Anyone	Block or proxy

The "acting for" column only works if every agent action is tied to a real person or service identity. Our non-human identity governance playbook covers how to set that up.

Should AI Agent DLP Redact or Block a Tool Argument?

Redact when the destination and recipient are approved but the call carries more data than the task needs. Block when the data is heading to a disguised sink. Hold for approval when a legitimate tool is sending labelled data to a recipient it has not sent to before.

Redaction keeps the workflow running. Blocking a disguised sink costs almost nothing, because a search query or image URL rarely has a business reason to carry customer data. See when to redact, warn, or block and sanitization vs. redaction vs. smart redaction for the trade-offs.

How Do You Stop Data Leaving Through Rendered Content?

Treat everything the agent renders as outbound. In practice, that means three things:

• Strip or proxy external images in agent output, so the user's browser never fetches an address the agent wrote.
• Disable automatic link previews for agent-generated messages in tools like Slack and Teams.
• Treat DNS as a channel your egress controls can see, since SalesBleed showed that a hostname alone can carry data out.

How Do You Control What an MCP Server Sends Out by Itself?

Give each MCP server its own outbound allowlist, so a server built to send email cannot reach any other destination. Pin server versions, and review changes before upgrading, because postmark-mcp turned malicious in one release after 15 clean ones. For servers you host yourself, create a new server instance per session, which closes the cross-client leak behind CVE-2026-111770.

Our guides to MCP server authentication and AI coding agent secrets and permissions cover server vetting and configuration in more detail.

Why Isn't AI Detection Alone Enough?

Because detection can fire while the data still leaves. In April 2026, Capsule Security disclosed ShareLeak (CVE-2026-21520, CVSS 7.5) in Microsoft Copilot Studio. Hidden instructions in SharePoint form submissions steered agents into sending data to attacker-controlled servers. The data was exfiltrated even when Microsoft's safety mechanisms flagged the suspicious behavior. Microsoft has since patched the issue.

A model-based classifier is useful for spotting injected instructions, but it is probabilistic. The decision about whether labelled data may reach a sink should be a deterministic rule enforced before the call runs. Every decision should also be written to an audit log, so an investigator can see what was blocked and why.

What Should You Ask an AI Agent DLP Vendor?

Ask whether the product inspects both what tools return and what agents send. Then check whether it decodes data before inspecting it, classifies disguised exits such as search and image rendering, and tracks sensitive data across a whole session. Finally, confirm it enforces the real user's permissions and makes its decision before the tool call executes rather than after. A vendor that can only scan prompts, or only alert after the fact, would not have stopped any incident in this guide.

Use these ten questions in your evaluation. The right-hand column tells you what a weak answer means.

#	Question to ask	Red flag if the answer is no
1	Do you inspect tool responses as well as tool arguments?	Injected instructions and over-retrieved data enter the agent unchecked
2	Do you decode URL, base64, hostname, and Unicode encodings before inspecting?	Encoded data passes straight through, as in SalesBleed
3	Do you treat search, image rendering, link previews, and DNS as outbound channels?	Disguised exits like SearchLeak and GrafanaGhost go unwatched
4	Can you follow a data label from one tool call to a later one in the same session?	Data read in one call leaks out of another and no single call looks wrong
5	Do you enforce per-session data limits for each destination?	Small, repeated leaks add up without triggering any rule
6	Is every decision made before the call executes?	You learn about the leak after the data has left
7	Are policy decisions deterministic, or do they rely only on a model's judgment?	A flagged attack can still exfiltrate, as ShareLeak showed
8	Do you tie each agent action to the real user or service identity?	Rules cannot tell an account owner from an attacker using the same agent
9	Can you detect changes to MCP tool descriptions and quarantine unknown servers?	A silently poisoned tool keeps running with full trust
10	Do you log every allow, redact, block, and approval decision with its reason?	Investigators cannot reconstruct what the agent did or why

Question 9 matters more than most teams expect. A 2026 census of public MCP servers found that 40.6% of servers with multiple versions changed their tool definitions while keeping the same identifier (arXiv preprint 2609.14119), so a tool you approved last month may not be the tool your agent calls today.

Ask vendors to show each answer working on your own agents during a proof of concept. A demo of blocked prompts in a chat window does not tell you how the product handles a tool call.

"When we red team AI agents, the leak almost never comes through the tool the security team was worried about. They've locked down email and webhooks, but the agent can still write customer data into a search query, a markdown image, or a link it posts to Slack. The question that finds the real exits isn't 'which tools are outbound?' It's 'which tools can put text somewhere we don't control?' Asked that way, most agent stacks have far more exits than anyone had listed."

Saurabh Upadhyay, AI Engineer, LangProtect

Every fix in 2026 closed one exit, and the next disclosure found another. The only way to know which exits remain in your own agents is to test them the way an attacker would. The OWASP GenAI Red Teaming Manual v1.0, published in October 2026, gives security teams a common method for doing that, and our guide to AI agent red teaming and runtime policy walks through the full testing process.

How Does LangProtect Stop Data Leaks in Agent Tool Calls?

LangProtect Vector sits inline between your AI agents and the MCP servers and tools they call. It inspects every tool call and every tool response for secrets, personal data, malicious URLs, and injected instructions. It then allows, redacts, or blocks the call before it executes. Vector governs the agent path. LangProtect Guardia governs the employee path, and the LangProtect AI Red Team tests both.

Each product maps to a different part of the problem described in this guide:

Problem from this guide	LangProtect control
Sensitive data or secrets placed in a tool argument	Vector scans tool calls for secrets, personal data, and malicious URLs before they run
Injected instructions or over-shared data in a tool response	Vector inspects MCP responses before they reach the agent's context
Agents calling tools beyond the task	Vector validates tool calls and enforces Discover, Read, Write, and Execute permissions per tool
Unvetted or changed MCP servers	Vector's MCP Resource Guard governs server access and quarantines unknown servers
Employees pasting data into AI chat tools	Guardia applies AI data loss prevention to prompts and uploads
Exits nobody has listed yet	The LangProtect AI Red Team tests agent tool chains for exfiltration paths

Three steps you can start this week:

1. Inventory: list every tool each agent can call and mark which ones can put text somewhere you don't control.
2. Label: decide which data classes, such as customer records, financial data, and secrets, must never reach a disguised sink.
3. Test: send each agent a planted instruction and check whether it can write labelled data into a search, an image, or a link.

Frequently Asked Questions About AI Agent DLP

What is AI agent DLP?

AI agent DLP is data loss prevention for autonomous AI agents. It tracks sensitive data from the tool that returns it to any tool that could send it outside your organization, then allows, redacts, blocks, or holds that flow for approval before the outbound call executes. It differs from prompt-based AI DLP, which only inspects what employees type into AI tools.

Does MCP have built-in data loss prevention?

No. The Model Context Protocol defines how agents discover and call tools, but it does not inspect what data flows through those calls. The MCP specification states that tool descriptions should be treated as untrusted, which leaves data protection to the organizations deploying it.

Can a URL allowlist stop AI agent data exfiltration?

Not on its own. In 2026, SalesBleed bypassed Salesforce's Trusted URLs control, and SearchLeak routed stolen data through Microsoft's own Bing infrastructure, which Copilot already trusted. An allowlist checks whether a destination is approved, but it cannot check whether specific data is allowed to go there.

Can an AI agent leak data through a search tool?

Yes. SearchLeak (CVE-2026-42824) showed that a crafted link could make Microsoft 365 Copilot Enterprise Search gather emails, documents, and MFA codes and send them out through a search request. Any tool that lets an agent write text into a query or URL is a potential exfiltration channel.

Can image rendering or link previews leak AI data?

Yes. When an agent writes sensitive data into an image URL or hostname, rendering the image or previewing the link sends that data to the address's owner. GrafanaGhost used image rendering in Grafana's AI assistant, and SalesBleed used image tags, Slack link previews, and the DNS lookups they trigger.

Is AI agent DLP the same as an MCP gateway?

No. An MCP gateway is the control point that agent traffic passes through, while AI agent DLP is the data policy enforced at that point. A gateway without data-aware rules can route and authenticate tool calls but cannot tell whether a call is carrying customer records to a disguised sink.

Should AI agent DLP redact or block tool arguments?

It depends on the destination. Redact when the destination is approved but the call carries more data than the task needs, block when sensitive data is heading to a disguised exit like a search query or image URL, and hold for human approval when a legitimate tool is sending labelled data to a new recipient.

Can an MCP server leak data without an attacker?

Yes. CVE-2026-111770, published in October 2026, showed that MCP servers built on the official TypeScript SDK could deliver one client's responses to another client when a single server instance was shared. Creating a new server and transport for each request or session closes the leak.

What should I ask an AI agent DLP vendor?

Ask whether the product inspects tool responses as well as arguments, and whether it decodes encoded data before inspecting it. Also ask whether it treats search, rendering, and DNS as outbound channels, tracks data across a session, and makes its decision before the tool call executes. A product that only scans prompts or alerts after the fact would not have stopped the 2026 incidents covered in this guide.

Why AI Agent DLP Has to Watch What Agents Call, Not What People Type

Every incident in this guide had the same shape. No employee pasted anything into a chat window. An agent read content an attacker could influence, gathered data it was allowed to read, and sent it out through a tool it was allowed to call. Vendors patched each exit, and attackers found the next one.

That is why AI agent DLP has to work on data flows rather than destinations. If your controls know what each piece of data is, where it is going, and who the agent is acting for, a new exit does not open a new leak. Start by inventorying every tool your agents can call, classifying which ones can send data out, and testing those exits before someone else does.