When an agent can send an email, post a comment or update a record, every one of those write tools is also a way to move data out, and the traffic looks exactly like normal work. MITRE ATLAS tracks this as AML.T0086 Exfiltration via AI Agent Tool Invocation, in the Exfiltration tactic (AML.TA0010). ATLAS describes sensitive data encoded into a tool's input parameters and sent to an adversary-controlled inbox, document or server, through a legitimate tool driven by prompt injection or through a malicious tool. Network-level controls are covered in the Agent Egress Control and Network Isolation Guide and investigation in Investigating Agent-Initiated Data Exfiltration. This page sits between them: how to classify an agent's write tools as exfiltration channels, and which ATLAS mitigations and detections stop data leaving through them. It is for teams building or approving agents with write access to business systems.
Key takeaways
- ATLAS rates this as realised. Unlike most agent techniques, AML.T0086 has a recorded real-world incident: the malicious postmark-mcp package that blind-copied agent emails to an attacker (AML.CS0053).
- The destination can be inside your own system. In AML.CS0039 the data was written back into a support ticket the external attacker could read, so no unusual network traffic was ever generated.
- Parameters are a channel. In AML.CS0054 credentials were placed in an unused tool parameter and sent to the tool's server; the case study notes the confirmation dialog did not show the full argument.
- ATLAS maps eight mitigations. AML.M0024 and AML.M0026 to AML.M0030, plus AML.M0032 and AML.M0033, are all linked to this technique.
- Classify write tools by audience. A tool that can reach someone outside the organisation is an egress point and deserves the same controls as one.
How the technique works
ATLAS created AML.T0086 in September 2025, last modified it in March 2026, and rates its maturity as realised. It needs two things: data the agent can read, and a tool that writes somewhere the attacker can see. The trigger is usually AML.T0051 LLM Prompt Injection, or AML.T0110 AI Agent Tool Poisoning, which ATLAS notes can also manipulate the inputs and destination of a separate legitimate tool.
| Variant | ATLAS case study | Channel | Why it is hard to spot |
|---|---|---|---|
| Injected instruction, legitimate email tool | AML.CS0037 (Zenity, Copilot Studio exercise, 2025) | Agent emails data to an address in the injected prompt | Sending email is the agent's normal job |
| Injected instruction, write-back to the source | AML.CS0039 (research exercise on Jira Service Management, 2025) | Agent posts internal data as a reply on the attacker's own ticket | No external destination at all |
| Malicious tool | AML.CS0053 (postmark-mcp, incident, 2025) | Hidden BCC added to every email the tool sent | Tool output looks correct to the user |
| Poisoned tool description | AML.CS0054 (research exercise, 2025) | Data placed in an extra tool parameter sent to the tool's server | Confirmation shows a simplified view |
| Shell tool | AML.CS0045 (research exercise, 2025) | Command run through a terminal tool posts data to a server | Command is one of many the agent runs |
ATLAS also lists creating or modifying documents, updating CRM records and generating images or videos as variants. Any field a person outside the trust boundary can later read is a possible channel.
Classifying write tools as exfiltration channels
A practical first step is to rate each tool an agent holds by who can read what it writes. The tiers below are our recommendation.
| Tier | Examples | Default control (our recommendation) |
|---|---|---|
| External recipient chosen at run time | Send email to any address, post to any URL, HTTP fetch with parameters, shell | Human approval with full arguments, or recipient allowlist |
| External party via a shared record | Reply on a customer ticket, comment on a public issue, update a shared document, CRM fields synced to partners | Output validation for sensitive data; approval when the record was created externally |
| Third-party tool server | Any remote MCP server or plugin that receives tool arguments | Pinned, reviewed tools; argument schema enforcement |
| Internal only | Write to an internal store with no external sync | Logging and normal access control |
The Jira case shows why "internal system" is not the same as "internal audience": the ticket was in the company's own service desk, but the requester was the attacker.
Prevention: the ATLAS mitigations
| ATLAS mitigation | What it means for this technique |
|---|---|
| AML.M0026 Privileged AI Agent Permissions Configuration | RBAC, ABAC and least privilege for agents that serve many users, so a hijacked agent cannot read everyone's data |
| AML.M0027 Single-User AI Agent Permissions Configuration | Delegated access from the user, with lifecycle management and decommissioning |
| AML.M0028 AI Agent Tools Permissions Configuration | Shared tools receive the permissions and restrictions of the calling agent, implemented in MCP servers or the tools themselves |
| AML.M0029 Human In-the-Loop for AI Agent Actions | A person approves high-impact actions; ATLAS notes the trade-off with operational overhead |
| AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Block automatic tool calls, or require confirmation, once untrusted data enters context |
| AML.M0032 Segmentation of AI Agent Components | Boundaries around tools and data, sandboxes with limited network access, rate limits on tool invocation |
| AML.M0033 Input and Output Validation for AI Agent Components | Schema validation and checks for sensitive information leaving through tool inputs and outputs |
| AML.M0024 AI Telemetry Logging | Logs of tool use, data access and agent identity for detection and investigation |
Add two controls ATLAS describes through its case studies: pin and review third-party tools, since the postmark-mcp change was a single added line in version 1.0.16, and show full tool arguments in any approval dialog.
Detection
| Data source | What to look for |
|---|---|
| Tool call logs | New recipients, domains or record owners; parameters much larger than usual; key-shaped or encoded strings in parameters |
| Email and messaging logs | BCC or CC recipients the user did not request; agent-sent mail to domains never contacted before |
| Ticketing and CRM audit logs | Agent-written replies or fields containing data from other records or customers |
| Agent trace (AML.M0024) | A read of sensitive data followed by a write tool call in the same turn after untrusted content entered context |
| Package and tool inventory | Tool version changes, new tools, or tool description changes since last approval |
D3FEND D3-OTF Outbound Traffic Filtering and D3-NTA Network Traffic Analysis help where the tool calls a remote server; for write-back channels the evidence lives in application audit logs instead. See also the AI Agent Behaviour Baselining and Anomaly Detection Guide.
Measuring it
- Channel inventory: share of agent write tools rated by tier.
- Approval coverage: share of top-tier tool calls that required approval with full arguments shown.
- Pinned tools: share of third-party tools pinned to a reviewed version.
- Validation hits: sensitive data detections in tool parameters per thousand calls, and the false positive rate.
- Mean time to trace: time to reconstruct which data left through which call during an investigation.
Implementation
- Inventory write tools: list every tool each agent can call that writes, sends or posts, and rate it by tier.
- Log first: turn on tool call logging with full parameters (masked where they hold personal data) and agent identity.
- Pilot controls in observe mode: run sensitive-data validation and recipient checks on top-tier tools for two weeks, reporting only.
- Enforce on the highest tier: require approval or allowlists for external recipients and block tool calls after untrusted content on agents that read sensitive data.
- Pin tools: move third-party tools to pinned versions with review before upgrade.
- Roll back: keep enforcement switchable per agent so a false positive does not stop the whole estate.
Where identity fits
A write tool exfiltrates only what the agent's identity can read and only where its credential can write. Scope both. Use delegated, per-user access so an agent working for one customer cannot read another's records, and give each tool its own narrowly scoped credential so a malicious tool cannot reuse it for anything else. See the AI Agent Authorisation Guide and the AI Agent Email Access Security guide.
Response
- Stop the channel: disable the tool or agent, and for a malicious tool remove it everywhere it is installed.
- Scope what left: pull tool call logs and application audit logs to list every parameter sent through the channel since the earliest possible start.
- Recover at the destination: where the destination is your own system, such as a ticket reply, remove the content and check who viewed it.
- Rotate exposed secrets: any credential that passed through the channel is compromised; the postmark-mcp breach page advises rotating secrets sent by email while the package was installed.
- Close the trigger: find the injected content or poisoned tool, and add a regression test. The investigation guide covers evidence collection in depth.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0086 (AML.TA0010); triggered by AML.T0051 or AML.T0110 | Technique and triggers |
| MITRE ATLAS mitigations | AML.M0024, AML.M0026 to AML.M0030, AML.M0032, AML.M0033 | Mitigations ATLAS links to the technique |
| MITRE ATT&CK | T1567 Exfiltration Over Web Service | Closest enterprise technique where a web service is the destination |
| NIST SP 800-53 Rev. 5 | AC-4, AC-6, SC-7, SI-4, AU-12 | Information flow, least privilege, boundary, monitoring, logging |
| NIST CSF 2.0 | PR.AA-05, DE.CM-09, DE.AE-02 | Access policy, monitoring, analysis |
| MITRE D3FEND | D3-OTF, D3-NTA | Outbound filtering and traffic analysis |
Common failure patterns
- Only watching the network: missing write-back exfiltration into tickets, comments and shared documents.
- Approval without arguments: users approving a tool name without seeing where the data goes.
- Auto-updating tools: third-party tools upgraded without review, as in the postmark-mcp malicious MCP server case.
- Over-broad read access: a customer-facing agent able to read every customer's records, so any injection can collect them.
- No parameter logging: tool calls logged by name only, so nobody can say what left.
Practitioner checklist
- Rate every agent write tool by who can read what it writes.
- Require approval with full arguments, or recipient allowlists, for external write tools.
- Block or confirm tool calls after untrusted content on agents that read sensitive data.
- Validate tool parameters for sensitive data and enforce argument schemas.
- Pin third-party tools and review each upgrade.
- Scope agent read access per user or customer.
- Log tool calls with parameters and agent identity.
- Rehearse response: stop the channel, scope, recover, rotate, close.
Standards and references
- MITRE ATLAS: Exfiltration via AI Agent Tool Invocation
- MITRE ATLAS: Poisoned Postmark MCP Server Email Exfiltration
- MITRE ATLAS: Living Off AI, Prompt Injection via Jira Service Management
- MITRE ATLAS: Data Exfiltration via Agent Tools in Copilot Studio
- MITRE ATLAS: Restrict AI Agent Tool Invocation on Untrusted Data
- MITRE ATLAS: AML.CS0045 Data Exfiltration via an MCP Server used by Cursor
- MITRE ATLAS: AML.CS0054 Data Exfiltration via Remote Poisoned MCP Tool
Related NHI Mgmt Group resources: Agent Egress Control and Network Isolation Guide · Investigating Agent-Initiated Data Exfiltration · AI Agent Tool and Plugin Security Guide · MITRE ATLAS Guide