When an AI agent moves data out of your environment, the theft is performed by an authorised identity, through approved tools, often inside a single user request, so the usual insider and malware playbooks miss the questions that matter. Investigators have to establish which channel carried the data, exactly which records the agent read and emitted, whether the agent was steered by injected content, misused by a person or running on stolen credentials, and what must be revoked. This guide gives a channel-by-channel evidence map, a scoping method for "what left", a decision path for root cause and the containment steps specific to agent exfiltration. It is for incident responders, SOC leads and the platform teams who run agents. For building the run timeline itself, see the Agent Activity Timeline Reconstruction guide; for the general incident runbook, see the AI Agent Incident Response Playbook.
Key takeaways
- Name the channel before scoping. Agent exfiltration leaves through a small set of paths: a write tool, a rendered link or image, a web fetch, code execution egress or a connector sync. Each has a different evidence source and a different way to measure volume.
- The read set is not the leak set. The agent's data access logs show what it could have disclosed; the tool arguments, rendered output and outbound requests show what actually left. Notification decisions need the second.
- Root cause is one of three. Injected instructions in content the agent processed, a person deliberately misusing the agent, or an attacker driving the agent with stolen credentials. The containment and the notification differ for each.
- Content logging is usually off. Prompt, response and tool argument capture is opt-in in OpenTelemetry and disabled by default in services such as Amazon Bedrock model invocation logging, so evidence may exist only in downstream systems.
- Allowlists age. The ForcedLeak research showed an expired domain still trusted by a content security policy becoming the exfiltration endpoint; check every trusted destination, not only untrusted ones.
How agents exfiltrate data
MITRE ATLAS gives the vocabulary. AML.T0086 Exfiltration via AI Agent Tool Invocation covers write-capable tools invoked to send data to an adversary-controlled location, with the data encoded in tool parameters (an email, a document, a CRM record, even generated media). AML.T0077 LLM Response Rendering covers output that, when rendered by the client, makes an automatic request carrying data, typically a markdown image URL with the data in the query string. The usual trigger is AML.T0051 LLM Prompt Injection, in its indirect form (AML.T0051.001) when the instructions arrive in content the agent reads. OWASP's Top 10 for LLM Applications 2025 frames the same conditions as LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling and LLM06 Excessive Agency.
| Channel | What the agent does | Primary evidence | How to measure what left |
|---|---|---|---|
| Write tool (AML.T0086) | Sends an email, posts a message, creates a file or ticket, updates a record with data in the arguments | Tool call records (name, call ID, arguments if captured); the target system's own audit log (mail trace, file audit, CRM field history) | Reconstruct each payload from the target system; count records and fields |
| Rendered output (AML.T0077) | Emits a link or image whose URL carries data; the client fetches it | Stored responses; proxy or CDN logs for the destination; browser or client telemetry | Decode query strings in requests to the destination |
| Web fetch or browsing tool | Requests an attacker URL with data in the path or parameters | Fetch tool logs; egress proxy logs from the agent runtime | Requested URLs and request bodies |
| Code execution sandbox | Runs code that opens a network connection or uploads a file | Sandbox execution logs; network flow from the sandbox | Bytes out per destination; files written |
| Connector or MCP server | Calls a third-party or attacker-supplied server that receives the data as input | MCP client and gateway logs; server registration and approval records | Requests to that server and their parameters |
| Credential theft then direct access | Agent reveals a token or key; the attacker uses it outside the agent | Responses containing secrets; the issuer's sign-in and API logs for that credential | Everything the credential accessed after exposure |
The last row matters for NHI teams: an exfiltrated API key turns a content leak into an access incident that the agent logs alone will never show. See the AI Agent Tool and Plugin Security Guide.
Evidence sources by platform
Collect these early, because several have short default retention or are not enabled by default.
| Source | What it records | Watch out for |
|---|---|---|
| Microsoft Purview audit, CopilotInteraction records | AppHost, AgentId and AgentName, AISystemPlugin (BingWebSearch when the public web was used), AccessedResources with SiteUrl, SensitivityLabelId, Action and XPIADetected, Messages with JailbreakDetected | The documented fields reference messages by ID; Microsoft's page does not state that prompt or response text is included. Third-party AI app records (AIAppInteraction) require pay-as-you-go and are retained 180 days |
| Amazon Bedrock model invocation logging | Full request and response bodies, modelId, operation and identity.arn of the caller, to CloudWatch Logs or S3 | Disabled by default; covers Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream on bedrock-runtime; bodies over 100 KB go to S3 |
| OpenTelemetry GenAI spans from your agent framework | invoke_agent and execute_tool spans, gen_ai.tool.name, gen_ai.tool.call.id, gen_ai.conversation.id, gen_ai.agent.id | Conventions are at Development status; gen_ai.tool.call.arguments and message content are Opt-In |
| Identity provider and token issuer | Which identity the agent used, token issuance, scopes, sign-in location | Agents acting on behalf of users may appear as the user |
| Target SaaS audit logs | Records read, exported or modified; messages sent; files shared | Integration users often have different log coverage from humans |
| Egress proxy, DNS and flow logs for the agent runtime | Destinations, request sizes, timing | Hosted agents may egress from provider address space you do not log |
Join keys and clock alignment across these sources are covered in the Agent Activity Timeline Reconstruction guide; this page assumes you can produce one ordered run.
Scoping what left
- Fix the window: from the first appearance of the triggering content (a lead record, an email, a document, a tool description) to containment. Injected content can sit dormant and fire on many later requests, so the window may cover many sessions.
- Enumerate affected runs: search for every conversation or run that retrieved the triggering content, not just the one that was reported. In EchoLeak, the researchers described spreading the payload across several emails so retrieval would pick it up for everyday questions.
- Build the read set: from AccessedResources, data plane logs or the target system, list every object the agent read in those runs, with sensitivity labels.
- Build the emit set: from tool arguments, stored responses, destination logs and the target system, list what was written, sent or requested outward. Decode URLs and encoded parameters.
- Intersect and classify: data that appears in both sets is confirmed disclosure; data in the read set only is "accessed, not shown to have left". Record the evidence for each claim.
- Check credentials in the emit set: any token, key or password that left is treated as compromised; pull the issuer's logs for its use after the exposure time.
If content logging was off, reconstruct the emit set from the receiving side: the mail trace, the CRM field history or the destination's web server logs if you can obtain them. Where you cannot, say so in the report and treat the read set as the upper bound.
Determining root cause
| Cause | Indicators | Implication |
|---|---|---|
| Indirect prompt injection | Untrusted content in context shortly before the anomalous tool call; instruction-like text in a record, email or page; XPIADetected or similar classifier flags; the user's request unrelated to the exfiltrating action | The user is a victim; fix the content path, output handling and destination controls; search for the same payload elsewhere |
| Deliberate misuse by a person | The user's own prompts request the export or the external destination; repeated attempts after refusals; JailbreakDetected flags | Insider case: HR and legal involvement; follow the Insider Data Theft Response Playbook |
| Stolen or misused credentials | Agent or user token used from a new location or client; runs no legitimate user started; activity outside working patterns | Identity incident: revoke and reissue, review the token's full activity, not only agent runs |
| Malicious or poisoned tool | A tool or MCP server whose description or behaviour changed; data sent to a server not in the approved list | Supply chain incident: remove the tool across all agents, review its version history |
Causes combine: a poisoned tool description is a form of injection, and a misused credential can be used to plant injected content. Record every contributing condition, because each needs its own fix.
Containment specific to agent exfiltration
- Stop the channel, then the agent: block the destination at egress and in any URL allowlist, disable the write tool or connector involved, then pause the agent if the cause is not yet understood. Pausing first can destroy in-flight state you need.
- Quarantine the triggering content: remove or neutralise the injected record, email or document so other runs stop retrieving it. Preserve a copy with hashes first.
- Revoke delegated access: revoke the agent's tokens, consent grants and any credentials that appeared in output. See Revoking Delegated Access During an Active Agent Incident.
- Review trusted destinations: check every domain on content security policy and URL allowlists for expiry and current ownership. ForcedLeak used an allowlisted domain that had expired and was re-registered for about $5.
- Turn content logging on for the incident: enable invocation and tool argument capture for affected agents while the investigation runs, with access restricted to the response team.
Where identity fits
Every agent exfiltration is performed by an identity: the agent's own service principal or workload identity, a user's delegated token, or a connector's OAuth grant. Investigations stall when the agent has no distinct identity and its actions are logged as the user. Fixes that make the next investigation possible: a separate identity per agent, recorded in gen_ai.agent.id or the platform's AgentId; on-behalf-of tokens that carry both the user and the agent; narrow scopes so the read set is small by design; and short token lifetimes so a leaked token expires before it is used. See the Agent Identity and Access Guide.
Detection and measurement
- Write tool calls after untrusted retrieval: alert when a send, share or update tool call follows retrieval of external content in the same run, especially to a recipient or domain the user has not used before.
- URLs with long query strings in output: flag rendered images or links to non-corporate domains carrying encoded parameters.
- Read volume spikes: an agent reading far more records or files than its baseline in one run.
- Classifier flags: treat XPIADetected and JailbreakDetected in Purview records, or equivalent guardrail events, as triage inputs rather than noise.
Metrics that show readiness: percentage of production agents with tool call logging and content capture available on demand; median time to produce the emit set for a reported run; share of agents with a distinct identity; number of expired or unowned domains on URL allowlists (target zero); time from detection to revoking the agent's credentials.
Framework mapping
| Framework | Reference | Use in this investigation |
|---|---|---|
| MITRE ATLAS | AML.T0086, AML.T0077, AML.T0051.001, AML.T0057 | Classifying the channel and the trigger |
| OWASP Top 10 for LLM Applications 2025 | LLM01, LLM02, LLM05, LLM06 | Root cause categories for the report |
| MITRE ATT&CK v20 | T1567 Exfiltration Over Web Service, T1530 Data from Cloud Storage, T1078.004 Cloud Accounts | Non-AI steps around the agent, such as use of leaked credentials |
| NIST SP 800-53 Rev. 5 | AU-12 Audit Record Generation, AU-6 Audit Record Review, SI-4 System Monitoring | Forensic readiness for agent logs |
| NIST CSF 2.0 and SP 800-61 Rev. 3 | DE.AE-02, RS.AN-03 | Analysis of events and establishing what happened |
Common failure patterns
- Investigating only the reported run: injected content keeps firing for every user who retrieves it; the true scope is every run that touched the content.
- Treating the read set as the leak: over-notifying when the emit set is small, or under-notifying when the read set was never compared with outputs.
- Trusting allowlisted destinations: the ForcedLeak research showed data sent to a domain the platform still trusted after it had expired.
- Assuming a sanitiser covers all output forms: in EchoLeak, ordinary external links were removed but reference-style markdown images survived, and Microsoft URL services allowed by the content security policy fetched the attacker address.
- Agent actions logged as the user: without a distinct agent identity, responders cannot separate the user's actions from the agent's, and the insider question cannot be answered.
- Missing the credential in the output: a token disclosed in a response is used later from outside; the agent logs show nothing more.
Lessons from incidents
Both cases linked here were responsibly disclosed research with no reported in-the-wild exploitation, but they show the evidence problem clearly. In ForcedLeak, the trigger was a public Web-to-Lead form whose Description field accepts up to 42,000 characters; the agent queried other leads' data and placed it in an image URL. Salesforce began enforcing Trusted URLs for Agentforce and Einstein AI on 8 September 2025. In EchoLeak (CVE-2025-32711), the trigger was external email retrieved into Microsoft 365 Copilot's context, and the fix was server-side. In both, the investigator's first artefacts would be the triggering record, the agent's data access, and the destination requests, which is exactly the read set, emit set and channel method above.
Practitioner checklist
- Identify the channel (write tool, rendered output, fetch, code execution, connector, credential) before scoping.
- Preserve the triggering content with hashes, then quarantine it so other runs stop retrieving it.
- Enumerate every run that retrieved the triggering content in the window, not just the reported one.
- Build the read set and the emit set separately and record the evidence for each item.
- Treat any credential in the emit set as compromised and pull the issuer's logs for its later use.
- Decide the root cause (injection, misuse, stolen credential, poisoned tool) and route to the right playbook.
- Block the destination, disable the tool, revoke the agent's delegated access, then pause the agent.
- Audit URL and content security policy allowlists for expired or re-registered domains.
- Enable Purview audit, Bedrock invocation logging or OpenTelemetry tool spans with opt-in content capture before the next incident.
Standards and references
- MITRE ATLAS: Exfiltration via AI Agent Tool Invocation (AML.T0086)
- MITRE ATLAS: LLM Response Rendering (AML.T0077)
- OWASP: Top 10 for LLM Applications 2025
- Microsoft Learn: Audit logs for Copilot and AI applications
- AWS: Amazon Bedrock model invocation logging
- OpenTelemetry: GenAI semantic conventions
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
Related NHI Mgmt Group resources: Agent Activity Timeline Reconstruction · AI Agent Incident Response Playbook · Agent Egress Control and Network Isolation Guide · T1567 Exfiltration Over Web Service