AML.T0070 RAG Poisoning: Ingestion Controls, Source Trust and Retrieval Monitoring

Any content your RAG pipeline indexes is content an attacker may be able to write, and once it is indexed it is replayed into the model every time a matching question is asked. MITRE ATLAS tracks this as AML.T0070 RAG Poisoning, in the Persistence tactic (AML.TA0006): adversaries inject malicious content into data indexed by a retrieval augmented generation system to contaminate future threads through RAG search results. ATLAS notes the content may be targeted to surface for a specific query, and may carry false information, prompt injections or false RAG entries. This page is about the defender's three levers: what gets ingested, how much each source is trusted, and how retrieval is monitored. Architecture-level RAG controls are in the RAG Security Guide and the vector store risks in the OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide. It is for engineers who own ingestion pipelines and for detection teams.

Key takeaways

• It is persistence, not a one-off. ATLAS files RAG poisoning under Persistence because a poisoned entry fires on every retrieval until someone removes it.
• Ingestion paths are the attack surface. In the ATLAS cases the attacker never touched the index: Copilot indexed received email and Slack AI indexed public channel messages.
• A few documents are enough. The PoisonedRAG research reported a 90% attack success rate with five malicious texts per target question in a database of millions.
• Trust must be a property of the source. Our recommendation: every indexed item carries an origin and trust tier set by the pipeline, and sensitive workflows retrieve only from high-trust tiers.
• Retrieval logs are the detection source. Without chunk IDs and source per answer, you cannot find a poisoned entry or measure its reach.

How poisoning reaches the index

ATLAS created AML.T0070 in March 2025, last modified it in May 2026, and rates it as demonstrated. It usually follows AML.T0064 Gather RAG-Indexed Targets, where the attacker learns which sources are indexed from public documentation or from the system's own answers, and pairs with AML.T0066 Retrieval Content Crafting, content written to be retrieved for chosen queries.

Two cases show the pattern. In AML.CS0026, Zenity researchers found that Copilot for Microsoft 365 indexed every email received, opened or not, and sent a message whose content was crafted to be retrieved for bank-detail queries; the prompt then ran whenever that entry was retrieved. In AML.CS0059, EchoLeak, the poisoned email was written to look like ordinary business content so it would be retrieved in later, unrelated Copilot sessions. See the EchoLeak 2025 breach page, which describes spreading the payload across topics so everyday questions would retrieve it, and the forged-document variant in MITRE ATLAS AML.T0071 False RAG Entry Injection.

In 2026 SalesBleed showed the same thing for structured records: instructions in a public Web-to-Lead submission were read as business data when an employee asked an agent about new leads. Salesforce fixed the reported issues before disclosure, and the lesson our breach page draws is to treat externally submitted records as untrusted input.

What a poisoned entry is used for

• Misinformation: false facts that the user trusts because the assistant presents them, such as replaced bank details in CS0026.
• Prompt injection carrier: instructions that redirect the model, often to leak data. See the Prompt Injection Guide and MITRE ATLAS AML.T0051 LLM Prompt Injection.
• Agent hijack: where the retriever feeds an agent with tools, poisoned content can trigger actions. See MITRE ATLAS AML.T0080 AI Agent Context Poisoning.
• Training data, not retrieval: poisoning that changes the model itself is a separate technique; see MITRE ATLAS AML.T0020 Training Data Poisoning.
• Credential harvesting: a crafted entry retrieved next to secrets the user can read. See MITRE ATLAS AML.T0082 RAG Credential Harvesting.

Ingestion controls

ATLAS links AML.M0020 Generative AI Guardrails (apply retrieval guardrails to reject untrusted, malicious, irrelevant or unsupported RAG content) and AML.M0035 AI Red Team. AML.M0025 Maintain AI Dataset Provenance supports both. In practice:

1. Decide per source whether to index it at all. The cheapest control is not indexing inbound email from external senders, public form fields or open channels for workflows that do not need them.
2. Record provenance on every chunk (AML.M0025): source system, author or sender, external or internal origin, ingestion time, content hash and the trust tier. Store this in the index record, not in the text.
3. Extract text safely: OWASP LLM08 recommends text extraction that ignores formatting and detects hidden content. Flag white-on-white text, zero-size fonts, hidden HTML, comments and metadata fields with long free text.
4. Scan for instructions and markers: run an injection classifier and rules for imperative instructions aimed at an assistant, references to the assistant itself, URLs with long parameters, and strings that mimic your prompt template or chunk headers.
5. Quarantine, do not silently drop: send flagged items to a quarantine collection with the reason, so analysts can review and tune.
6. Control write access to high-trust sources: owners, review before publication, and alerting on edits to pages that are frequently retrieved.

Source trust scoring

A trust tier should be set by the pipeline from facts it can verify, never from the content. A simple model we suggest:

Use the tier in retrieval: filter low-trust items out of sensitive workflows (payments, credentials, HR, legal), show origin labels to users beside citations, and reduce the rank of low-trust items. Re-score when a document changes.

Small and large deployments

A small team with one assistant can get most of the benefit by excluding external-origin content and showing citations. A large organisation with many RAG applications should build provenance and trust tiers into a shared ingestion service so every application inherits them, and connect quarantine to the security team's case management.

Retrieval anomaly monitoring

AML.M0024 AI Telemetry Logging makes detection possible: for each answer, log query, retrieved chunk IDs, scores, source, trust tier and the response.

Metrics

• Provenance coverage: share of indexed chunks with origin and trust tier recorded (target 100%).
• Low-trust exposure: share of answers in sensitive workflows that used a low-trust chunk (target zero).
• Quarantine rate and review time: flagged items per thousand ingested, by source, and time to decision.
• Time to purge: from detection of a poisoned entry to removal at source, from the index and from caches.
• Red team success rate: share of seeded test documents that change answers (AML.M0035).

How to test

AML.M0035 AI Red Team describes seeding controlled malicious or misleading content into representative ingestion sources, then improving source authorisation, provenance, content validation, indexing controls and retrieval-time filtering. A test plan we suggest:

1. Map every ingestion path and who can write to it, including external email, forms and guest accounts.
2. Seed harmless marker documents through each path in a test tenant: false facts on a test topic, hidden text, and benign instructions such as adding a marker word to the answer.
3. Measure whether they are indexed, retrieved, cited and acted on, and whether scanners and trust filters catch them.
4. Repeat after model, embedding, chunking or prompt changes, since retrieval behaviour shifts. See AI security regression testing.

Roll out new filters in log-only mode first and compare answer quality on an evaluation set; rollback is a configuration change on the retrieval filter.

Response

1. Identify the entry: from retrieval logs, find the chunk IDs and their source record.
2. Remove at source and in the index: delete the email, message or record at origin, then its chunks, embeddings and any cached answers; otherwise re-indexing restores it.
3. Sweep: search for the same sender, author, hash, URLs and phrases across all collections.
4. Assess impact: list users and sessions that retrieved it, and any actions or decisions based on those answers.
5. Harden: add the pattern to ingestion scanning and the case to regression tests; use the Prompt Injection Incident Response Playbook.

Common failure patterns

• Indexing everything by default: all received mail and all public channels indexed because the connector allows it.
• Trust inferred from content: the model or pipeline believes the author, date or source written in the text.
• Index-only deletion: removing chunks while the source item remains, so the next sync re-ingests it.
• No retrieval logging: no record of which chunks fed an answer, so reach cannot be measured.
• Treating it as a vendor issue: in CS0035 the vendor described retrieval of public channel content as intended behaviour; what is indexed is a customer configuration decision.

Framework mapping

For the full mitigation catalogue see the MITRE ATLAS Mitigations Guide.

Practitioner checklist

• List every ingestion path for each RAG application and who can write to it.
• Stop indexing external-origin content where the workflow does not need it.
• Record origin, author, hash and trust tier on every chunk, set by the pipeline.
• Extract text with hidden-content detection and scan for instructions and template markers.
• Quarantine flagged items with a reason and a review owner.
• Exclude low-trust tiers from payments, credential, HR and legal workflows.
• Log chunk IDs, source and trust tier with every answer.
• Seed marker documents through every path and retest after pipeline changes.

Standards and references

• MITRE ATLAS: RAG Poisoning (AML.T0070)
• MITRE ATLAS: Financial Transaction Hijacking with M365 Copilot as an Insider (AML.CS0026)
• MITRE ATLAS: Data Exfiltration from Slack AI via Indirect Prompt Injection (AML.CS0035)
• MITRE ATLAS: EchoLeak, Zero-Click Prompt Injection Targeting M365 Copilot (AML.CS0059)
• OWASP: Top 10 for LLM Applications 2025
• Zou et al.: PoisonedRAG, Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models
• PromptArmor: Data exfiltration from Slack AI via indirect prompt injection
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Threat Modelling RAG Systems, Permission-Aware RAG Guide, Vector Database Security Guide, LLM Grooming and AI Search Poisoning, MITRE ATLAS Guide.