Agent Data Exfiltration
Could protected information leave through an allowed-looking action?
Reference notes by Min · Reviewed October 15, 2026
Definition
Agent data exfiltration is the unauthorized transfer of information from an agent-accessible source to a destination outside its permitted boundary. It can occur through tools, generated artifacts, messages, network requests, or operational records.
An agent can read data legitimately and still be unauthorized to send it elsewhere. Source access and destination permission therefore need separate checks. A task can also expose information through generated files or message metadata even when the visible chat answer looks harmless.
What it covers
- Source access
- Limit which protected records the task can read.
- Destination
- Check recipient, tenant, endpoint, and sharing permissions.
- Payload
- Assess what leaves through bodies, attachments, URLs, and metadata.
- Secondary channels
- Review logs, traces, memory, and exported artifacts.
Map each route by which content can leave the trusted environment. Include user-facing exports, tools, external APIs, browser navigation, webhooks, and observability backends. Identify where policy can be enforced for the actual transfer.
In practice
Practical design patterns by Min.
- Apply least privilege to both reading and outbound actions.
- Approve sensitive transfers against their actual recipient and payload.
- Constrain network and sharing capabilities at the service boundary.
- Treat telemetry and third-party tools as potential data destinations.
An approval request should show a meaningful recipient and data scope. A generic confirmation to “continue” is insufficient if the user cannot see that a restricted attachment or external endpoint is involved. Recheck changes before committing the transfer.
Working example
An external translation request
An agent proposes sending a restricted document to a translation service.
- Check whether the current task permits using that service for this data class.
- Block the transfer if the destination or data use is unapproved.
- Offer an approved route or human review without copying the restricted content into ordinary error logs.
Why the controls matter
In the translation example, denying the proposed destination does not require disclosing the document to explain the denial. The service can record a policy reason and protected reference while keeping the content inside the approved boundary.
Common pitfalls
- Assuming a permitted domain makes every payload safe.
- Checking the final answer while ignoring attachments and tool calls.
- Sending sensitive content to a monitoring vendor while investigating a leak.
Data-loss detection can help identify patterns but has false positives and gaps. Combine it with permission design, destination controls, minimized payloads, and incident procedures instead of treating it as a complete authorization system.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which paths can move protected content externally?
- Is permission bound to the actual destination and payload?
- What secondary stores receive copies?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- OWASP LLM02:2025: Sensitive Information Disclosure ↗Accessed October 15, 2026
- OWASP Foundation: MCP Tool Poisoning ↗Accessed October 15, 2026