ATLAS Exfiltration Tactic (AML.TA0010) Guide: Stopping Data Leaving Through Models, Agents and Tools

In AI systems, stolen data rarely leaves through an obvious tunnel: it leaves as a rendered image link, an email the agent was asked to send, a tool parameter, or millions of ordinary looking inference calls. MITRE ATLAS groups these routes under the Exfiltration tactic, AML.TA0010, which it defines as the adversary "trying to steal AI artifacts or other information about the AI system". This hub explains how the five current techniques in ATLAS 2026.10 work together, how they chain from earlier tactics, which ones to tackle first, and what to monitor across the tactic. It is written for AI security engineers, detection teams and architects who own copilots, agents, MCP integrations and model APIs. Each technique has its own deep guide, linked below; this page does not repeat them. For the framework itself, see the MITRE ATLAS Guide.

Key takeaways

• The agent is the exfiltration channel. Of 35 Exfiltration steps recorded in ATLAS case studies, 10 use AML.T0086 Exfiltration via AI Agent Tool Invocation and 5 use AML.T0077 LLM Response Rendering: the AI system itself sends the data out.
• Traditional channels still dominate the count. AML.T0025 Exfiltration via Cyber Means appears in 16 steps, mostly in incidents where AI infrastructure such as Ray clusters, notebooks or coding agents was the entry point and data then left by DNS, SFTP, HTTP or reverse shells.
• Collection is almost always the step before. In the case study step graphs, 16 of the steps that lead into Exfiltration are Collection steps and 7 are Credential Access, so controlling what an agent can read is the cheapest exfiltration defence.
• Model outputs are data too. AML.T0024 Exfiltration via AI Inference API covers extraction and distillation through legitimate queries; three case studies (AML.CS0056, AML.CS0075, AML.CS0076) describe large scale distillation campaigns.
• Egress, rendering and tool scope are the three control points. Block untrusted URL and image rendering, allow list agent network and tool destinations, and require approval for any tool that can send data outside the tenant.

What the Exfiltration tactic means for AI systems

ATLAS takes its tactic description from ATT&CK: data may be stolen "for its valuable intellectual property, or for use in staging future operations", usually over a command and control or alternate channel, sometimes with size limits. The AI difference is that the system under attack has legitimate, authorised ways to move data: it renders Markdown, calls tools, fetches URLs, writes to tickets and answers API queries. An adversary who can influence the model's context, usually through prompt injection, can turn each of those features into an outbound channel without installing anything.

Two families sit in the tactic. The first steals information the AI system can reach: emails, documents, chat history, API keys and credentials files in a developer workspace. The second steals the AI system itself: model weights, training data properties or model behaviour reconstructed from outputs. Defences differ. The first is an access and egress problem; the second is a query volume, output and artifact protection problem. See the Data Exfiltration Guide for the general discipline.

Every technique in the tactic

ATLAS 2026.10 lists five techniques under AML.TA0010 and no sub-techniques. Maturity is the ATLAS rating: Feasible (shown in research), Demonstrated (shown against a real system) or Realized (used in a real attack). Case study steps are counted from the ATLAS 2026.10 data file: each case study procedure step tagged with tactic AML.TA0010 and that technique.

Related techniques in other tactics feed this one: AML.T0085 Data from AI Services gathers the data, and AML.T0137 Training Data Information from AI Models and AML.T0144 Recover AI Model Internals describe what an inference API attacker is after. Each has its own guide.

How adversaries chain into Exfiltration

ATLAS case studies record each step with the step it leads to. Counting the steps that lead directly into an Exfiltration step across the 2026.10 data gives: Collection 16, Credential Access 7, Execution 6, Defense Evasion 5, Discovery 2, AI Attack Adaptation 2, and one each from Command and Control, Privilege Escalation and Exfiltration itself. Three patterns recur.

Pattern 1: indirect prompt injection, collection, render or send

Untrusted content (an email, calendar invitation, Jira ticket, web page or Slack message) carries instructions. The assistant retrieves private data in the victim's context, then encodes it in an image URL or sends it with a tool. ATLAS records this in ChatGPT Conversation Exfiltration (AML.CS0021), Google Bard Conversation Exfiltration (AML.CS0029), Data Exfiltration from Slack AI via Indirect Prompt Injection (AML.CS0035), Living Off AI via Jira Service Management (AML.CS0039), and EchoLeak (AML.CS0059), where the image request was routed through allowed Microsoft domains to get past the Content Security Policy. See the EchoLeak breach analysis: one crafted email, no click, and data left through a link the client fetched automatically.

Pattern 2: poisoned tool or MCP server

The tool itself is the adversary. In Poisoned Postmark MCP Server Email Exfiltration (AML.CS0053) a malicious npm package added a blind copy address so every email sent through the tool was also delivered to the attacker; in Data Exfiltration via Remote Poisoned MCP Tool (AML.CS0054) the tool's model-visible description told the agent to read credentials files, hide this from the user and place them in an unnecessary parameter. The postmark-mcp breach analysis shows why this is hard to see: the copies used the victim's own sending credentials and looked like normal traffic.

Pattern 3: compromised AI infrastructure, then conventional exfiltration

Exposed Ray clusters (AML.CS0023 ShadowRay), compromised PyTorch dependencies (AML.CS0015), exposed agent control interfaces (AML.CS0048) and AI generated malware such as LAMEHUG (AML.CS0044) end with ordinary network exfiltration. Recent agentic case studies (AML.CS0068, AML.CS0071, AML.CS0073) show autonomous agents carrying out the full chain, including moving credentials and records out through repositories and callback infrastructure.

Where to start: ranked techniques for defenders

1. AML.T0086 Exfiltration via AI Agent Tool Invocation: rated Realized, rising fast in recent case studies, and invisible to network DLP when the destination is an allowed SaaS service. It also has the most ATLAS mitigations of any technique in the tactic (nine).
2. AML.T0077 LLM Response Rendering: the cheapest to remove. Disabling automatic rendering of external images and links in assistant output, or restricting it to an allow list, closes the zero-click route seen in four of the five case studies.
3. AML.T0025 Exfiltration via Cyber Means: the highest count, and your existing egress, EDR and DLP controls apply. The AI specific work is to include training clusters, notebooks, model registries and developer agents in their scope.
4. AML.T0024 Exfiltration via AI Inference API: priority for model owners who expose APIs; lower for organisations that only consume third party models. See the Model Extraction and Distillation Defence Guide.
5. AML.T0136 Exfiltration via AI User Interface: one case study (AML.CS0069, in which the operator approved a transfer of selected data over a web AI service). Treat it as part of your AI service use and data loss policy.

Detection priorities across the tactic

ATLAS maps AML.M0024 AI Telemetry Logging and Monitoring to AML.T0024 and AML.T0086. In practice that telemetry has to include prompts, retrieved context sources, tool calls with full arguments, and rendered output. See the Investigating Agent-Initiated Data Exfiltration guide for the investigation side.

Metrics that show it is working

• Rendering exposure: share of AI clients that block or allow list external images and links in model output.
• Tool egress coverage: percentage of agent tools that can send data outside the tenant which are behind an approval step or destination allow list.
• Argument logging: share of agent and MCP tool calls logged with full arguments and context provenance.
• Red team result: number of exfiltration paths found per quarter in AI red team exercises, and time to close them.
• Extraction detection: median time from the start of a systematic query campaign to a key being throttled or revoked.

Mitigation priorities

ATLAS 2026.10 maps 13 mitigations to techniques in this tactic. The table groups them by control point; the MITRE ATLAS Mitigations Guide explains each one.

Phased rollout

1. Inventory the outbound paths: list every AI client that renders Markdown, every agent tool that can send, post, fetch or execute, and every inference API you expose. See the Agent Egress Control and Network Isolation Guide.
2. Close rendering first: set a strict image and link allow list in assistant clients; test with your own injected test documents.
3. Log before you block: turn on full argument logging for agent and MCP calls and run destination analytics in alert only mode for two to four weeks to learn normal recipients.
4. Gate send tools: add approval or allow lists to external send tools, starting with email and HTTP fetch; keep a per tool switch so you can roll back a gate that breaks a workflow.
5. Protect the model itself: apply quotas and extraction analytics to exposed APIs, and include AI hosts in DLP and EDR scope.
6. Test continuously: add exfiltration scenarios from the case studies above to your AI red team plan. See the AI Red Teaming Guide.

Decision guidance

• Approval prompts or allow lists: approvals fit low volume, high value actions; allow lists fit high volume workflows where users would approve everything. In AML.CS0054 the poisoned tool told the agent to conceal its extra actions from the user, so an approval that shows only a summary protects little.
• Consumers versus model owners: organisations that only use hosted assistants should focus on AML.T0077 and AML.T0086; organisations that train or serve models add AML.T0024 and AML.T0025 on their AI infrastructure.
• Small teams: start with rendering restrictions, removal of unused send tools and scoped tokens; these need configuration, not new tooling.

Where identity fits

Every exfiltration route in this tactic runs on a credential: the user's delegated OAuth grant used by a copilot, the API token inside an MCP server, the cloud key on a training cluster, or the API key used for distillation. Scoping those identities limits what can leave. Give each MCP server and tool its own narrowly scoped token, keep send permissions separate from read permissions, and alert when an AI service key is used from new infrastructure. See the Agent Identity and Access Guide.

Common failure patterns

• Trusting first party domains: EchoLeak passed the Content Security Policy by routing through allowed Microsoft services; allow lists must cover redirecting and proxying endpoints, not just domains.
• Approval dialogs that summarise: users approve what they cannot see; show full tool arguments and destinations.
• Read and send in one agent: an agent that reads untrusted email and can send email is a complete exfiltration chain on its own.
• Unpinned tools: postmark-mcp became malicious in a later version; pin and review MCP server versions.
• AI hosts outside DLP scope: training clusters and notebook servers often sit outside endpoint and egress monitoring, which is where AML.T0025 steps succeed.

Framework mapping

Practitioner checklist

• Assistant clients block or allow list external images and links in model output.
• Every agent tool that can send data outside the tenant is inventoried, scoped and either approved per call or restricted to known destinations.
• Agents that process untrusted content cannot invoke send tools in the same session without approval.
• Agent and MCP tool calls are logged with full arguments and context provenance.
• MCP servers and agent plugins are pinned, from known publishers, with their own scoped tokens.
• Training clusters, notebooks and model registries are in EDR, DLP and egress monitoring scope.
• Exposed inference APIs have per key quotas and extraction analytics.
• The AI red team plan includes rendering, tool and MCP parameter exfiltration tests.

Standards and references

• MITRE ATLAS: Exfiltration (AML.TA0010)
• MITRE ATLAS: atlas-data repository (techniques, mitigations and case studies)
• MITRE ATLAS: EchoLeak case study (AML.CS0059)
• MITRE ATLAS: Poisoned Postmark MCP Server Email Exfiltration (AML.CS0053)
• MITRE ATT&CK: Exfiltration (TA0010)
• OWASP: Top 10 for LLM Applications 2025
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: MITRE ATLAS Guide, Data Exfiltration Guide, Prompt Injection Guide, Agent Egress Control and Network Isolation Guide.