Data Exfiltration Risks in AI Agents: How to Block Data Leaks

Data Exfiltration Risks in AI Agents: How to Block Data Leaks

An AI agent leaks data when it can read sensitive information and also has a path to send it to someone who should not receive it. To block data exfiltration, you have to cut that path: limit what the agent reads, restrict where it can communicate, and validate everything that leaves, whether it is a reply, a link or a tool call. A well-written prompt helps, but it does not replace network and permission controls.

Key takeaways

• The risk appears when three things coexist: access to private data, contact with untrusted content, and an outbound channel.
• The most common routes are tools with internet access, links and images assembled by the agent, replies sent to the wrong user, and poorly protected logs or memory.
• Network controls (an allowlist of destinations) and least-privilege permissions work even when the model is tricked.
• Validating output and requiring human approval for actions that send data outside reduces the damage when something fails.
• Start by mapping which data the agent touches and where it can send information, then close whatever is not needed.

What is data exfiltration in an AI agent?

Exfiltration is the unauthorized movement of company information out of a controlled environment. In traditional software, that usually takes an attacker or a configuration mistake. With AI agents there is a third source: the model itself can be induced, through text, to do the sending.

This happens because the agent reads instructions and data in the same language channel. An email, a web page, a PDF or a WhatsApp message can contain text that looks like an order. If the agent has tools, it may obey. This pattern is known as prompt injection, and it appears among the risks listed in the OWASP Top 10 for LLM applications.

For the person making the decision, the practical point is this: the question is not only whether the model is trustworthy, but what it can do if it is fooled. The system design should assume the failure will happen and limit the damage.

How data leaves: the most common routes

It helps to separate the routes, because each one calls for a different control.

• Tools with external access: a search, browsing, email, webhook or generic HTTP tool lets the agent send content to any destination. This is the most direct route.
• Links and images: if the interface renders images or links built by the model, a URL can carry data in its query string. The image only has to load for the data to reach the server of whoever wrote the malicious instruction.
• Replies to the wrong person: the agent answers with information about another customer, another department or an internal document the requester should not see. There is no attacker, but there is a leak.
• Integrations and third-party servers: connectors, plugins and MCP servers may log or forward what they receive. That is why it is worth knowing how to audit an MCP server before installing it.
• Logs, memory and shared context: conversations stored without masking, memory that mixes customers, and transcripts sent to outside tools all widen the exposure surface.
• Secrets in context: API keys and tokens placed in the prompt or in files the agent reads can be repeated in its output. Storing and rotating API keys deserves its own attention.

None of these routes depends on the model being malicious. All of them depend on the system having given the agent an open path.

How does a hidden instruction turn into a leak?

A useful mental model is to check for a combination of three conditions. When all three are present in the same session, the risk is high.

• The agent accesses private data: CRM, spreadsheets, conversations, internal documents, personal data.
• The agent processes content that does not come from you: incoming emails, web pages, attachments, customer messages, tickets.
• The agent can communicate outward: send a message, open a URL, call an API, generate a link or an image.

If you remove any one of the three, the main route closes. An agent that reads internal data but only talks to your team and never opens links carries less risk than one that reads everything, browses the web and sends email. OWASP's prompt injection prevention guidance details input and output defenses, but the logic of separating capabilities is what reduces risk the most in practice.

A common example of poor design: the same agent that answers customers on WhatsApp also queries the full order database and can call a free-form webhook tool. A single well-crafted message can try to make it send other customers' order data to an external address.

Network controls: close the exit door

Network control is the layer that still holds when the model fails. It does not depend on the agent understanding the threat.

• Allowlist of destinations: the agent's environment can only talk to approved domains and services. Everything else is blocked by default.
• A single exit point: the agent's traffic goes through a proxy or gateway that logs and filters calls, instead of each tool going out on its own.
• Isolated browsing tools: if the agent needs to read external pages, it does so in a separate environment with no access to internal data and no credentials.
• No network where it is not needed: tasks that read and analyze documents can run with no external access at all.
• Controlled resolution and redirects: validate the final domain of a URL, not just the first one, so redirects cannot be used to slip past the filter.

The same principle applies to AI-assisted development environments. If your team uses coding agents, read about permissions, sandbox and secrets in Claude Code, which apply the same logic of isolating what the agent can reach.

Permission and output controls

The network limits where data can go. Permissions limit what the agent can read and do. The two layers complement each other.

On permissions:

• Minimum necessary: each agent gets only the tools and data fields the workflow requires. OWASP's authorization guidance reinforces least privilege and checking on every request.
• Requester identity: the agent queries data with the permissions of the person being served, not with a service account that sees everything.
• Read before write: tools that only look things up are much less risky than those that send, delete or change.
• Credentials outside the context: the agent never sees the key; the execution layer injects the secret into the call.
• Human approval: sending data outside, exports and bulk messages go through a person before they leave.

On output:

• Do not render arbitrary links and images: allow only approved domains, or display the link as plain text.
• Sensitive data filters: detect national ID numbers, emails, phone numbers, document numbers and secrets before the reply is sent. This topic is covered in guardrails for AI agents.
• Reply scope: the agent only answers about the customer identified in the conversation and refuses to discuss third parties.
• Volume limits: an agent that tries to list many records at once should be stopped and trigger an alert.

Illustrative scenario and rollout plan

Illustrative scenario: a services company puts an agent on WhatsApp to check order status. The agent has access to the full customer base and a tool that can call any URL, used for integrations. A customer sends a message with text asking the agent to list other people's recent orders and send the result to an external address. Without controls, the agent may try to comply. With the controls below, the attempt fails at more than one layer: the query only returns data for the identified number, the tool only calls approved domains, and the reply passes through a filter before it goes out.

A step-by-step plan to reach that design:

• List the data the agent touches: which systems, which fields, and which involve personal data under privacy law.
• List the tools and what each one can send outside, including those that look harmless, such as browsing and link generation.
• For each workflow, mark whether the three conditions (private data, untrusted content, outbound channel) coexist.
• Remove or separate one of the three whenever possible, splitting the agent into functions with less power.
• Apply a network allowlist and a single exit point that logs calls.
• Reduce read permissions to the customer being served, and replace generic tools with narrow ones (for example, check the status of one order instead of running a free-form query).
• Put filters on output and require human approval for exports, bulk sends and any data outside the defined scope.
• Test with injection attempts in messages, documents and pages, and record what got through.
• Define alerts and who responds when a blocked call or an unusual pattern appears.

How to log and test so you know it works

A control nobody observes becomes an assumption. Log every tool call, its destination, the requester and the decision (allowed, blocked, sent for approval). These records help you investigate incidents and tune rules. At the same time, the logs themselves contain personal data, so set a retention period and masking, as discussed in AI conversation log retention and data masking.

Test on a recurring basis. Build a small set of adversarial cases: messages asking for third-party data, documents with hidden instructions, pages with suspicious links, export requests. Run that set before every relevant change of model, prompt or tool. The goal is not to prove the system is impenetrable, but to know which routes are closed and to notice when one reopens.

If personal data is involved, bring in whoever handles privacy at your company. In Brazil, the data protection authority (ANPD) is the official reference for guidance, and the decision about who is controller and who is processor in the contract with AI vendors affects who answers when something leaks. See data controller vs processor in an AI vendor contract for how to frame it.

How we apply the method: map, limit, pilot, hand over

In practice, the work follows four steps. First, map the current process and what the agent will touch: data, systems, tools and outbound channels. Then limit data and actions, with minimum permissions, a restricted network and human approval at the highest-risk points. Next, pilot one real workflow, with logs and an agreed success metric, including leak attempt tests. Finally, hand over the operation with documentation and decide whether to expand, adjust or stop.

This order avoids the most frequent mistake: connecting the agent to everything first and trying to protect it later. Closing doors is far cheaper before production than after an incident.

Frequently asked questions

Is a prompt that says never to reveal data enough to prevent a leak? No. Prompt instructions help, but the model can be induced by text to ignore them. Reliable protection comes from controls outside the model, such as permissions, a network destination allowlist and output filters.

What should I block first? Start with the outbound channel: tools with open internet access, email sending and generic webhooks. Then reduce what the agent can read to the minimum the workflow needs and turn off rendering of arbitrary links and images.

Are agents that only read internal data also at risk? The risk is lower if there is no outbound channel and all the content processed is trusted. Even so, the agent can answer the wrong person or expose data in logs. That is why scoping by requester and masking records are still necessary.

Do I need human approval for everything? No, and that would defeat the purpose of automation. Reserve approval for actions that send data outside, export volume or touch sensitive data, and let the agent work on its own for low-risk lookups within the limits you have defined.

Sources

• OWASP: Top 10 para aplicações com LLM
• OWASP: prevenção de injeção de prompt
• OWASP: orientação de autorização
• ANPD: Autoridade Nacional de Proteção de Dados