Data exfiltration is one of the most practical AI agent security risks because it turns an abstract model failure into a concrete business incident. An agent may be allowed to read customer records, support tickets, source code, internal documents, analytics exports, credentials, or incident notes. If that same agent can also send email, post to Slack, call arbitrary URLs, upload files, create tickets, write comments, or summarize content into a public place, the route from private data to external exposure can be short.
This checklist is for teams preparing an AI agent for real workflows. It focuses on the controls that reduce the chance of private data leaving the system through prompt injection, tool misuse, retrieval mistakes, excessive permissions, weak logging, or confusing approval screens.
1. Define what counts as sensitive data
Start with a data classification list that normal product and engineering teams can actually use. Sensitive data may include customer names, emails, support history, contract terms, internal notes, source code, API keys, secrets, credentials, logs, analytics exports, security findings, legal documents, and unreleased product plans.
The list should be written in operational language, not only compliance language. An agent builder needs to know whether a retrieved support ticket, a debug log, a CSV export, or a code snippet can be shown to the user, summarized, stored, or sent to another tool.
2. Map every read path
Data exfiltration begins with access. List every place the agent can read from: RAG indexes, databases, file systems, browser pages, internal APIs, SaaS tools, CRM records, knowledge bases, ticket systems, repositories, logs, and memory stores. For each source, record the data owner, sensitivity level, access method, and retention behavior.
This map often reveals accidental overreach. A support agent may only need public help articles and the current ticket, but it may have access to all tickets. A coding agent may only need a repository folder, but it may see the developer’s home directory. A research agent may only need public web pages, but it may also read private synced documents.
3. Map every write and send path
After read paths, map outbound paths. Can the agent send email, post chat messages, create public comments, update issue trackers, upload files, call webhooks, make HTTP requests, create pull requests, write documents, or export reports? Every outbound path is a possible exfiltration route.
Teams should separate internal writes from external sends. Updating an internal draft is not the same as emailing a customer. Creating a private ticket is not the same as posting to a public GitHub issue. A safe design makes the riskiest outbound actions explicit and reviewable.
4. Keep retrieval scoped to the task
RAG systems often leak data because retrieval is too broad. The agent asks a narrow question but retrieves a wide set of documents that include unrelated customer information, internal notes, or sensitive examples. The model may then summarize more than the user should see.
Use scoped retrieval by tenant, user role, project, workspace, document class, and task. Retrieval filters should be enforced by the backend, not left to the model. If the user cannot access a document directly, the agent should not retrieve it on their behalf unless there is a specific approved delegation rule.
5. Treat tool output as untrusted data
Tool output can contain hostile instructions. A web page, PDF, issue comment, support ticket, or document can tell the agent to reveal secrets, ignore policy, encode data, or send context somewhere else. The agent should treat this text as data, not as a higher-priority instruction.
Prompt templates should clearly label retrieved and tool-returned content as untrusted. The system should prevent tool output from changing tool permissions, destination allowlists, approval requirements, or the agent’s core goal. This is especially important for browsing agents and MCP-connected tools.
6. Use destination allowlists
If an agent can call arbitrary external URLs, exfiltration becomes easier. Destination allowlists reduce that risk. The agent should only send data to approved domains, APIs, email destinations, chat workspaces, storage buckets, or internal systems that match the workflow.
Unknown webhooks, newly created domains, raw paste services, public file hosts, and unreviewed callback URLs should be blocked by default. If the workflow requires a new destination, add it through an explicit review process rather than letting the model decide.
7. Show data movement in approval screens
Approval gates are weak when they hide the actual data movement. A user should not approve a vague message such as “send summary.” The approval screen should show the destination, the type of data being sent, the tool name, the record or file identifiers, and a short preview of the payload.
For higher-risk actions, the screen should also show whether the destination is internal or external, whether the action is reversible, and whether sensitive fields were redacted. The user should approve the real operation, not a simplified story about it.
8. Redact secrets before model and tool exposure
Secrets should not rely on the model to behave. API keys, tokens, passwords, private keys, session cookies, database URLs, and signing secrets should be redacted before they enter prompts, logs, memory, or tools that do not need them.
Use automated secret scanning on retrieved documents, tool outputs, uploaded files, and agent logs. When a secret is detected, block the action, redact the value, rotate the credential if exposure is possible, and record an incident note.
9. Separate summarization from sending
A common pattern is to ask the agent to summarize sensitive content and then send it somewhere. Separate those steps. Let the agent draft a summary internally, then require explicit review before it is sent externally. This gives humans and policy checks a chance to catch private details.
The draft should carry provenance: which documents were used, which fields were included, and which redactions were applied. Without provenance, reviewers cannot tell whether the summary accidentally included restricted content.
10. Monitor unusual data volume
Exfiltration is often visible in volume. An agent that normally reads one ticket but suddenly reads hundreds of records, exports a large file, sends many messages, or calls an unusual endpoint deserves attention.
Track records read, bytes retrieved, files touched, external requests, upload size, message count, token spend, and repeated failed policy checks. Cost anomalies can also be security signals when attackers use stolen credentials or agent access to run large jobs.
11. Log without creating a second leak
Audit logs are necessary, but they can also become a data leak if they store raw sensitive content forever. Log enough to investigate: source identifiers, tool names, parameter summaries, destination, policy decision, approval actor, timestamp, and outcome.
For sensitive payloads, store hashes, redacted previews, or controlled evidence links instead of full raw content. Define retention periods and access controls for agent logs. Security teams need evidence, but not every operator needs full customer data in logs.
12. Test exfiltration attempts before launch
Create a small test set that tries to make the agent leak data. Include malicious retrieved text, poisoned tool output, fake support tickets asking for secrets, documents that request external uploads, prompts that ask for encoded data, and tool calls to unapproved destinations.
The test should confirm that the agent refuses, asks for approval, redacts sensitive content, blocks the destination, or limits retrieval. Repeat the test whenever prompts, tools, retrieval filters, model versions, or approval policies change.
13. Prepare containment steps
If data exfiltration is suspected, the team needs a fast path: disable the agent, revoke tool credentials, block outbound destinations, preserve logs, identify affected records, rotate exposed secrets, notify the right internal owner, and prepare customer communication if needed.
Do not wait for a serious incident to define ownership. A data exfiltration runbook should name the incident lead, security reviewer, product owner, legal/compliance contact, and customer communication owner.
Practical launch rule
If an AI agent can read private data and communicate outside the current trusted boundary, it needs explicit exfiltration controls. The minimum set is scoped retrieval, destination allowlists, visible approvals, secret redaction, outbound logging, volume monitoring, and regression tests.
Related resources
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
- MCP Security Checklist for AI Agents
- AI Agent Tool Risk Register Template
- AI Agent Data Governance Checklist
For a broader launch review, start with the AI Agent Readiness Self-Assessment.