An agent trusts what its tools return, so anyone who can write a ticket, a document, a repository comment or a database row that the agent will later read can steer what the agent does next. MITRE ATLAS tracks this as AML.T0099 AI Agent Tool Data Poisoning, in the Persistence tactic (AML.TA0006): adversaries manipulate data in a victim-controlled, trusted or connected source that an agent tool reads, such as document repositories, databases, source code repositories, knowledge bases, search indexes, enterprise applications or third-party data services. The content may carry false information or instructions that become an indirect prompt injection when retrieved. This page is about protecting those data sources and the path from tool result to action. Poisoned tool definitions are covered in MCP Tool Poisoning Detection and poisoned agent memory in the AI Agent Memory Poisoning Guide; neither is repeated here. It is for teams building agents on enterprise data and the owners of the systems those agents read.
Key takeaways
- The target is the data, not the tool. The tool works as designed; it faithfully returns content an attacker placed in a source it trusts.
- It persists. ATLAS files AML.T0099 under Persistence because the poisoned record keeps firing every time a query retrieves it, until someone removes it.
- Anyone with write access to a source is in scope. Public service portals, shared channels, issue trackers and inbound email all let outsiders write into data that agents read.
- Guardrails are the mapped mitigation. ATLAS maps AML.M0020 Generative AI Guardrails: apply retrieval guardrails to reject untrusted, malicious, irrelevant or unsupported tool-retrieved content.
- Design so a successful injection is harmless. Restrict tool use after untrusted data enters context (AML.M0030) and require approval for consequential actions, because no filter catches everything.
Where AML.T0099 sits among its neighbours
ATLAS created AML.T0099 in November 2025, last modified it in July 2026, and rates it as feasible. Its description separates it from several close techniques, and the boundaries matter for detection and ownership.
| Technique | Where the malicious content lives | Who controls that place |
|---|---|---|
| AML.T0099 AI Agent Tool Data Poisoning | A data source an agent tool queries: tickets, documents, repositories, databases, search indexes, enterprise apps, third-party data services | The victim or a trusted party |
| AML.T0070 RAG Poisoning | Data indexed by a retrieval augmented generation system | The victim |
| AML.T0093 Prompt Infiltration via Public-Facing Application | Entered through a victim's public-facing app (portal, inbox); ATLAS notes this may also constitute T0099 | The victim |
| AML.T0078 Drive-by Compromise | A website the attacker controls, fetched directly | The attacker |
| AML.T0110.002 AI Agent Tool Poisoning: Runtime Response | A malicious or compromised tool alters its own result | The tool provider |
| AML.T0080 AI Agent Context Poisoning | The agent's memory or thread context | The agent platform |
The effect on the model is usually AML.T0051.001 LLM Prompt Injection: Indirect. For the prompt injection overview see AML.T0051 LLM Prompt Injection; for neighbouring pages see MITRE ATLAS AML.T0071 False RAG Entry Injection and MITRE ATLAS AML.T0093 Prompt Infiltration via Public-Facing Application, plus MITRE ATLAS AML.T0070 RAG Poisoning, MITRE ATLAS AML.T0078 Drive-by Compromise and MITRE ATLAS AML.T0110 AI Agent Tool Poisoning.
How it shows up in real cases
As of ATLAS 2026.10 no case study is mapped to AML.T0099 itself; ATLAS records the cases below under the neighbouring techniques (T0093, T0070, T0051.001). Each involves content written into a trusted source and later returned by an agent tool, which is the pattern T0099 describes.
| Case | Poisoned source | Tool that read it | What the content steered |
|---|---|---|---|
| Living Off AI, Jira Service Management (AML.CS0039, research) | A support ticket created through the public service portal | Atlassian MCP tools used by a support engineer's assistant | Collecting other tickets and posting them as a reply visible to the attacker |
| Slack AI (AML.CS0035, research) | A message in a public channel the researcher created | Slack AI's search over channels | Returning the victim's API key from a private channel inside a link |
| Claude Code GitHub Action (AML.CS0067, research) | Issue body, pull request description or comment | The action fetching event content into context | Reading the process environment and emitting an API key |
| EchoLeak, Microsoft 365 Copilot (AML.CS0059, research, fixed) | An inbound email | Copilot retrieval over the mailbox | Placing internal data in a URL the client fetched |
The common thread is that the attacker never touched the agent. They wrote into a system where outsiders are expected to write, and a later, legitimate user request caused the agent to read it. Microsoft reported EchoLeak (CVE-2025-32711) as fixed server-side with no customer action required; see EchoLeak 2025.
Which sources are exposed
Rank each source an agent tool reads by who can write to it. That ranking is the core of the risk assessment for this technique.
| Source type | Who can write | Exposure |
|---|---|---|
| Public portals, inbound email, web forms, public issue trackers | Anyone on the internet | Highest: treat every record as untrusted |
| Shared chat channels, wikis, shared drives with broad edit rights | Any employee, guest or compromised account | High |
| Code repositories with external contributors | Contributors, forks, bots | High for issues, comments and pull requests |
| Third-party data services and partner APIs | The provider and its own upstream sources | Medium to high, depends on provider controls |
| Internal databases and line-of-business apps | Applications and named staff | Medium, often fed by external inputs further upstream |
| Curated knowledge bases with reviewed publishing | A small editorial group | Lower, if review is enforced |
Watch for indirect paths: a CRM record created from a web form, or a database row populated from a partner feed, is externally writable even if the database is internal.
Mitigations
| Control | How it applies to tool data |
|---|---|
| AML.M0020 Generative AI Guardrails (ATLAS mapping) | Retrieval guardrails between tool result and model that reject untrusted, malicious, irrelevant or unsupported content |
| AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Once a tool returns content from a low-trust source, block or require confirmation for further tool calls, scaled to the consequence |
| AML.M0033 Input and Output Validation for AI Agent Components | Schema validation and sanitisation of tool results; return structured fields rather than free text where possible |
| AML.M0029 Human In-the-Loop for AI Agent Actions | Approval for sending, posting, paying, deleting or changing access |
| AML.M0028 Enforce Access Controls for AI Agent Tools | Tools run with the calling user's delegated rights, so a poisoned ticket cannot reach tickets the user cannot |
| AML.M0025 Maintain AI Dataset Provenance | Record author and origin for records agents read, so trust can be decided per record |
| AML.M0024 AI Telemetry Logging and Monitoring | Log each tool result source and the actions that followed it |
Practical controls that make those work:
- Label trust at the source: pass author, origin (external or internal) and source system with every record a tool returns, and let policy act on the label rather than on the text.
- Separate untrusted text from instructions: Microsoft describes spotlighting (delimiting, datamarking or encoding untrusted text) and Prompt Shields classification as probabilistic layers, combined with deterministic blocking of known exfiltration paths and user consent for actions.
- Narrow the query: tools that fetch one named record leave less room for planted content than open-ended search across a whole tracker or workspace.
- Tighten write access: review who can create content in sources agents read; restrict guest edit rights on wikis and drives that feed agents.
- Block silent egress: restrict rendered links and images and the agent's outbound destinations so steered output cannot leave quietly.
Decision guidance
| Situation | Priority control (our recommendation) |
|---|---|
| Support or service desk agent reading customer tickets | Treat ticket text as untrusted, scope tools to the current ticket, approval before replies that include data from other records |
| Coding agent triggered by issues and pull requests | Do not trigger on content from untrusted contributors; no secrets in the agent process environment; read-only tokens |
| Enterprise assistant searching mail, chat and files | Trust labels for external mail and guest content, restricted rendering, approval for sends |
| Agent reading a third-party data API | Structured fields only, schema validation, no free-text fields passed to the model unless required |
| Small team, one internal agent | Start with write-access review on its sources and approval for every action with side effects |
Detection
| Where | What to look for |
|---|---|
| Tool result scanning (gateway or MCP proxy) | Instruction-like text, hidden or encoded content, or URLs with data placeholders in records returned by tools |
| Source system audit logs | New records from external or rarely seen authors in sources agents read, especially with unusual length or formatting |
| Agent action logs | A low-trust tool result followed in the same turn by a write, send or post, or by reads across unrelated records |
| Output and egress logs | Responses containing links to unknown domains or data embedded in URLs |
| Canary records | Planted test records that should never cause an action; alert if they do |
Measuring it
- Source trust coverage: share of agent data sources with trust labels on returned records.
- Externally writable sources: count of sources outsiders can write to that agents read, with an owner for each.
- Gated actions: share of side-effect tools that require approval or are blocked after untrusted input.
- Test pass rate: share of seeded poisoned records in the test suite that fail to cause an unwanted action.
- Time to purge: time from detecting a poisoned record to removing it from the source and any index or cache.
How to test
- Map sources: for each agent, list every tool, the source it reads and who can write to that source.
- Seed test records: in a staging copy, place harmless marker instructions in tickets, documents and comments (a request to add a fixed word to the reply is enough to prove influence).
- Run normal tasks: ask the agent ordinary questions that retrieve those records and record whether behaviour changed.
- Check the gates: confirm side-effect tools were blocked or asked for approval after the low-trust record entered context.
- Repeat on change: rerun when tools, models, prompts or source permissions change; include it in AI red team work (AML.M0035).
Defensive testing only: use marker instructions that prove influence, never live exfiltration or destructive instructions, and run in staging copies of the sources.
Response
- Find and quarantine the record: remove it from the source and from any search index, vector store or cache built from it.
- Trace what it caused: from agent logs, list every session that retrieved it and every action that followed.
- Contain effects: reverse posts and changes, and rotate any credential that appeared in an affected response.
- Check memory: if the agent stores memory, look for entries written while the record was in context.
- Close the write path: tighten who can write to the source or add a trust label for that path. See the AI Agent Incident Response Playbook.
Where identity fits
Poisoned data turns the agent's identity into the attacker's tool: whatever the agent's token can read or write, the planted content can ask for. In the Jira case the assistant's MCP access reached other support tickets; in the GitHub Action case the process held an API key. Delegated, per-user access for tools (so the agent can do only what the requesting user can) and keeping secrets out of the agent's environment limit the blast radius. See the Agent Identity and Access Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0099 (AML.TA0006 Persistence); effect AML.T0051.001; neighbours AML.T0070, AML.T0093, AML.T0078, AML.T0110.002, AML.T0080 | Technique and boundaries |
| MITRE ATLAS mitigations | AML.M0020 (mapped); AML.M0024, AML.M0025, AML.M0028, AML.M0029, AML.M0030, AML.M0033 | Guardrails, provenance, permissions, approval, tool restriction, validation |
| MITRE ATLAS case studies | AML.CS0035, AML.CS0039, AML.CS0059, AML.CS0067 | Illustrative cases mapped to neighbouring techniques |
| OWASP Top 10 for LLM Applications 2025 | LLM01:2025 Prompt Injection; LLM06:2025 Excessive Agency | Indirect injection and the agency that makes it harmful |
| NIST SP 800-53 Rev. 5 | AC-3, AC-6, SI-10, SI-4, AU-12 | Access enforcement, least privilege, input validation, monitoring, logging |
Common failure patterns
- Treating internal systems as trusted: forgetting that tickets, mail and CRM records are written by outsiders.
- Free text everywhere: passing whole records to the model when a few structured fields would do.
- Auto-triggered agents: agents that run on any new issue, ticket or email with write tools enabled.
- Cleaning the source but not the index: removing the record while it stays in a vector store or search cache.
- Relying on a classifier alone: no restriction on actions once untrusted content is in context.
- Agent rights broader than the user's: a shared service identity that lets one ticket reach every ticket.
Practitioner checklist
- List every source each agent tool reads and who can write to it.
- Attach author, origin and trust labels to records returned by tools.
- Apply retrieval guardrails between tool results and the model.
- Restrict or gate tool calls after low-trust content enters context.
- Require approval for sends, posts, payments, deletions and access changes.
- Run tools with the requesting user's delegated rights, and keep secrets out of the agent environment.
- Seed marker records in staging and test after every change.
- On detection, purge the record from source, index and cache, then trace its effects.
Standards and references
- MITRE ATLAS: AI Agent Tool Data Poisoning
- MITRE ATLAS: Generative AI Guardrails
- MITRE ATLAS: Restrict AI Agent Tool Invocation on Untrusted Data
- MITRE ATLAS: Living Off AI: Prompt Injection via Jira Service Management
- MITRE ATLAS: Data Exfiltration from Slack AI via Indirect Prompt Injection
- OWASP: LLM01:2025 Prompt Injection
- Microsoft Security Response Center: How Microsoft defends against indirect prompt injection attacks
Related NHI Mgmt Group resources: MITRE ATLAS Guide · MITRE ATLAS AML.T0080 AI Agent Context Poisoning · AML.T0053 AI Agent Tool Invocation · MITRE ATLAS AML.T0086 Exfiltration via AI Agent Tool Invocation