# AI agent data loss prevention: keeping data where it belongs

> AI agent data loss prevention (DLP) means inspecting the data an agent reads, sends and stores, and deciding by data type and destination whether each value passes, is masked, becomes a placeholder, is held for review, or is blocked. It covers four flows: tool results coming in, prompts to model providers, messages to people and systems, and writes to memory.

Source: https://agentfort.net/agent-security/data-protection · Updated 2026-10-28 · AgentFort

## What AI agent data loss prevention covers

AI agent data loss prevention (DLP) is a set of inline controls that inspect the data moving through an agent and decide, per data type and destination, what may pass. An AI agent moves data along four flows, and each needs its own rules.

| Flow | Example | What goes wrong |
|---|---|---|
| Into the agent from tools | A customer relationship management (CRM) record, a support ticket, a partner's PDF | The agent sees data its job does not need; a document carries hidden instructions |
| Out to model providers | Every prompt, with tickets and records pasted in | Secrets and personal data reach a third party |
| Out to people and systems | An email, a chat message, a webhook, another agent | Customer data goes to a personal address or the wrong recipient |
| Into memory | Conversation history, vector stores, scratch files | Data outlives its purpose; poisoned content returns in a later session |

Simon Willison's "lethal trifecta" explains why the flows matter together. An agent with access to private data, exposure to untrusted content, and a way to communicate externally can be steered into leaking ([Willison](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)). Most useful agents have all three. DLP works on the data inside each flow; [authorization](/agent-security/authorization) and [MCP security](/agent-security/mcp-security) decide which flows exist at all. The [AI agent security guide](/agent-security/) covers the full set of controls.

## Why classic DLP misses agent data flows

Classic DLP watches endpoints, email gateways, web proxies and sanctioned SaaS apps. It was built for people moving files. Agent traffic breaks its assumptions in four ways.

- **The channel is an API call.** An agent's request to a model provider is an encrypted HTTPS call from a server, carrying JSON. It looks like any other integration. Endpoint agents never see it, and a web proxy may not decrypt it.
- **The data is transformed.** Models summarize, translate and reformat. A card number can come back split across lines; a customer list can come back as prose.
- **The decision depends on context.** A customer's email address is fine going to the CRM and wrong going to a personal mailbox. The rule needs to know who the agent acts for and where the call goes.
- **The inbound side matters.** Classic DLP mostly looks outward. Agents also need inbound inspection, because a tool result can carry instructions, or data the agent should never see.

Classic DLP still protects mail and endpoints. To stop AI agents leaking data, AI agent DLP has to sit where agent calls pass: a gateway, proxy or broker in front of tools and model providers.

## Inspect both directions, and decode first

### Inspect inbound and outbound

Inspect every crossing, not just the last hop out:

- **Inbound:** tool results, retrieved documents, files and web pages, before they enter the model's context.
- **Outbound to models:** the full prompt, including system text and pasted records.
- **Outbound to the world:** tool-call arguments such as email bodies, ticket comments and URLs.
- **Into memory:** anything written to history, vector stores or files that will be read later.

Inbound inspection catches injected instructions and strips data the agent does not need. Outbound inspection stops secrets and bulk data. Memory needs both: what an agent writes today, it reads back tomorrow as trusted context, which is why OWASP lists Memory and Context Poisoning as ASI06 in its [agentic Top 10](/agent-security/owasp-agentic-top-10). The MCP specification asks for both: servers MUST "sanitize tool outputs," and clients SHOULD "validate tool results before passing to LLM" ([MCP tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). A detector that runs in only one direction misses half the problem.

### Decode before you inspect

Attackers and ordinary systems both encode text. A detector that scans raw text misses the same email address written three ways:

```text
jane@example.com          HTML entity
jane%40example.com            percent-encoding
amFuZUBleGFtcGxlLmNvbQ==      base64
```

Normalize first, then inspect. Decode HTML entities and percent-encoding, try base64 and hex on candidate strings, and repeat for nested layers up to a fixed depth. Flag invisible characters: OWASP notes that Unicode tag characters (U+E0000 to U+E007F) "can carry hidden instructions that models read and act on" ([OWASP cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)). Limit input length before decoding, so a crafted payload cannot exhaust the inspector. Decode for inspection only, and forward the original or the masked version. OWASP's [input validation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) states the principle: decode according to the protocol before checking field rules.

## Deterministic detectors and ML classifiers

Use two kinds of detector, for different jobs.

**Deterministic detectors** are patterns plus validation. They fit data with structure:

- Payment card numbers, confirmed with the Luhn check digit to cut false positives.
- International Bank Account Numbers (IBANs), confirmed with their check digits.
- Secrets with fixed formats: private key headers, cloud access keys, signed tokens.
- One-time sign-in codes: short numbers near words like "verification code".

They are fast, cheap, explainable and easy to test with fixtures. They do not understand meaning.

**Machine learning (ML) classifiers** answer questions about meaning. Is this a person's name or a product name? Is this paragraph trying to instruct the agent? Does a message about a failed login contain a live code, or only describe the problem? They catch what patterns cannot, but they are probabilistic, slower, and open to attack.

The open-source Presidio project combines named entity recognition, regular expressions, rule-based logic and checksums, and still states that "there is no guarantee that Presidio will find all sensitive information" ([Presidio](https://presidio.dataprivacystack.org/)). Willison makes the same point about injection filters: "in web application security 95% is very much a failing grade."

A practical split: let deterministic rules decide on structured data, and use classifiers to flag, hold or route rather than as the only gate. Replace detected values with placeholders before text goes to a classifier, so the classifier never sees them.

## Masking, placeholders, blocking or holding for review

Choose the action by what the agent needs and where the data is going.

| Action | What the agent or recipient gets | Use it when | Trade-off |
|---|---|---|---|
| Mask | `**** **** **** 1111` | The agent needs to know a value exists, or its last digits | The full value is unusable |
| Remove | Nothing; the value is deleted | A customer pasted an API key into a ticket | Some context is lost |
| Placeholder (tokenization) | `[EMAIL_1]`, restored after the answer returns | A model provider needs structure, not values | The mapping store becomes sensitive; the model cannot reason about the value |
| Block | A refusal with a reason | Secrets going to a model provider; bulk export | The task fails; the agent needs a clear error |
| Hold for review | A pause while a named person decides | A suspect document; an external email with many records | Adds delay; the person the agent acts for should not approve |
| Allow and log | The original data | Low-risk data to an approved destination | Relies on a complete record |

Placeholders suit model providers well. The model writes "Reply to [EMAIL_1] about order [ORDER_2]", and the real values are put back after the answer returns. OWASP's guidance on sensitive information disclosure recommends tokenization "to preprocess and sanitize sensitive information" ([OWASP LLM02](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)).

### Field-level hiding at the API

Text scanning is the fallback. When data is structured, hide fields at the API boundary instead. A support agent looking up a customer needs the email and phone number. It does not need the social security number (SSN) or birth date. Return the first two and mask the rest, based on the agent's grant for that operation.

Field rules are exact where text detection guesses. They work on JSON paths, so they apply to REST responses and to MCP `structuredContent` alike; that is the most reliable way to mask PII in MCP tool responses. Put them in the enforcement point, not in the prompt: an instruction to "ignore the SSN" still leaves the SSN in the context. See [AI agent authorization](/agent-security/authorization) for grants per agent and per operation.

## Prompt injection in documents: detect and quarantine

Indirect prompt injection happens when an agent reads external content, such as a file or web page, that contains instructions. OWASP notes these inputs "can affect the model even if they are imperceptible to humans" ([OWASP LLM01](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)). In documents, instructions hide in HTML comments, white or tiny text, alt text, speaker notes, metadata, invisible Unicode and base64 blocks.

Quarantine documents before the agent reads them:

1. Land new files in a holding area, not in the agent's context.
2. Extract every text layer, including comments and metadata, and decode it.
3. Ask a classifier whether the text addresses the agent or tries to direct it.
4. If flagged, hold the document for a reviewer who sees exactly what was flagged and where.
5. Release it, release it with the passage removed, or reject it.

Classify intent, not keywords. A security training note that quotes an injection example should pass. A partner's onboarding guide that hides one in an HTML comment should not.

Detection will miss some attacks. Design so a missed injection still cannot do much: narrow permissions, [human approval](/agent-security/human-approval) for consequential actions, and a [sandbox](/agent-security/sandboxing) for any code the agent runs.

## Bulk exfiltration and safe logging

### Stopping bulk exfiltration

The most damaging leaks are large, and they often use a channel the agent may legitimately use. In one of AgentFort's recorded lab runs at Northwind, a simulated company, an assistant acting for a support lead tried to email the whole customer list to a personal address. Authorization said "may send email"; only data inspection could see what the email contained.

Watch for these patterns:

- Many distinct records or identifiers in one outbound message or attachment.
- Customer data sent to personal or unknown domains.
- Slow drips: small sends that add up over a day.
- Data packed into URLs, such as query strings in links or images a client will load.
- Encoded or compressed content leaving with no business reason.

Count identifiers per call and per period, and make the threshold depend on destination. An internal analytics service may receive thousands of rows; a personal mailbox may receive none. Hold anything above the threshold for review, and block secrets outright.

### Logging decisions without logging the data

DLP logs can become the largest store of sensitive data in the company. Record the decision, not the content:

- Agent identity, the person it acts for, the tool and the destination.
- Which detector fired, the data type, the count, and the location as a field path or offset.
- The action taken, the policy version and the time it took.

If investigators need to correlate values across events, store a keyed hash (HMAC) instead of the value; a plain hash of a phone number can be reversed by trying every number. Keep any samples in a restricted store with a short expiry, and log denials and holds as carefully as allowed calls. [AI agent audit trails](/agent-security/audit) covers evidence in more depth.

## AI agent DLP checklist

- Map each agent's four flows: tools in, model providers out, people and systems out, memory.
- Inspect inbound tool results as well as outbound prompts and arguments.
- Decode HTML entities, percent-encoding, base64 and invisible characters before any detector runs.
- Validate card numbers and IBANs with their check digits.
- Send personal values to model providers as placeholders, and restore them afterward.
- Hide sensitive fields at the API, per agent and per operation.
- Quarantine new documents and hold any that try to instruct the agent.
- Count records per message and per period, by destination.
- Block secrets and sign-in codes from leaving the company.
- Log detections and decisions, never the values.

## How AgentFort handles this

AgentFort Data Protection inspects every call through the AgentFort gateway in both directions: prompts, files and tool results. It first decodes text hidden behind HTML entities, percent escapes or base64. Deterministic rules find secrets, sign-in codes and personal data, and check card and bank numbers with their checksums. For meaning, a low-latency language classifier answers typed questions, such as whether a document is trying to instruct the agent, and only sees text with every value replaced. One policy decides what each kind of data may do depending on where it is going. Personal values sent to a model provider travel as placeholders and are restored in the answer. Bulk exfiltration is stopped even when Access allows sending email. Every decision has a receipt: what was found, where, what was done and how long it took, never the values. See [AgentFort Data Protection](/platform/data-protection).

## Frequently asked questions

### How do I mask PII in MCP tool responses?

Mask before the model reads the response. If you run the MCP server, return only the fields the caller's grant allows. If you do not, place an MCP-aware gateway or proxy between the server and the agent, apply field rules to structuredContent and text detectors to content blocks, and decode before scanning. A prompt asking the model to ignore certain fields does not remove them from its context.

### Is it safe to send customer data to an LLM provider?

It depends on the data, your contract, and the provider's retention and training terms. Many teams allow general business text but keep secrets, sign-in codes and regulated identifiers out entirely. A safer pattern replaces personal values with placeholders before the call and restores them in the answer, so the provider sees the structure of the task but not the values.

### Can a classifier reliably detect prompt injection?

Not reliably enough to be the only control. Classifiers catch many hidden instructions, including encoded ones, but they are probabilistic and attackers adapt. Use a classifier to hold suspicious content for review, and limit what a fooled agent can do: narrow permissions, per-call authorization, human approval for consequential actions, and sandboxed code execution.

### What data should never be sent to an AI model?

Secrets and sign-in material: passwords, API keys, private keys, session tokens and one-time codes. They grant access on their own, and no model answer needs them. Beyond that, decide per data type and per provider. Many teams also keep government ID numbers, full card numbers and health data out, and send other personal values as placeholders.

### Do AI agents need DLP if they only use internal tools?

Usually, yes. Unless the model runs inside your own environment, every prompt carries internal tool results to a model provider. Agents may also write those results to memory that later sessions read. Internal tools can return data the agent's job does not need, or documents with injected instructions. Inspect those flows even when nothing goes to an outside recipient.

## Sources

- [Simon Willison: The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)
- [OWASP LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)
- [OWASP LLM02:2025 Sensitive Information Disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)
- [OWASP LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)
- [OWASP Input Validation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)
- [Presidio: data protection and de-identification SDK](https://presidio.dataprivacystack.org/)
- [MCP specification: Tools (2026-07-28)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)