Threats & safeguards

Agent Data Exfiltration

Could protected information leave through an allowed-looking action?

Reference notes by Min · Reviewed October 15, 2026

Working security definitionAlso: Data exfiltration · Agent data leakage · Egress controls2 primary references

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.

  1. Check whether the current task permits using that service for this data class.
  2. Block the transfer if the destination or data use is unapproved.
  3. Offer an approved route or human review without copying the restricted content into ordinary error logs.
Illustrative scenario, not a reported deployment.

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?

References

Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.

  1. OWASP LLM02:2025: Sensitive Information Disclosure ↗Accessed October 15, 2026
  2. OWASP Foundation: MCP Tool Poisoning ↗Accessed October 15, 2026