A retrieval augmented generation (RAG) system ranks content by how well it matches a question, so an attacker who writes text to match the questions your users ask can decide what your assistant reads before it answers. MITRE ATLAS tracks this as AML.T0066 Retrieval Content Crafting: adversaries write content designed to be retrieved by user queries and to influence the user, abusing the trust the user places in the system. The content may carry a prompt injection or stand alone as a misleading document or email. This page covers the crafting and ranking side: what makes planted content win retrieval, where that shows up in your logs, and the ranking and guardrail controls that blunt it. How content gets into the index is covered in the MITRE ATLAS AML.T0070 RAG Poisoning guide and the architecture view in the RAG Security Guide. It is written for engineers who own retrievers and rankers, and for detection teams.
Key takeaways
- Crafting is about ranking, not access. ATLAS separates getting content into the store (AML.T0070) from writing it so it is retrieved for chosen queries (AML.T0066); defenders need controls at both points.
- Relevance is the attacker's tool. In every ATLAS case the planted text mirrored the vocabulary of the target question: bank details, API keys, everyday HR topics.
- A handful of texts can dominate. The PoisonedRAG research reported about 90% attack success with five crafted texts per target question in a knowledge base of millions of texts.
- Look for chunks that win too often. A low-trust chunk retrieved for many unrelated questions, or a cluster of near-identical chunks from one sender, is the clearest signal in retrieval logs.
- Cite everything that was retrieved. In the Slack AI case the answer cited only the victim's message, not the attacker's, which hid the source of the instruction.
What the technique is
ATLAS added AML.T0066 on 12 March 2025, last modified it on 31 August 2026, rates its maturity as Demonstrated and lists the Generative AI and Agentic AI platforms. In the ATLAS 2026.10 data it sits under the AI Attack Adaptation tactic (AML.TA0001). ATLAS states the adversary must get the crafted content into the victim's database, such as a vector database used by a RAG system, either through cyber access or by abusing normal ingestion, and notes that large language models may be used to help write the content (see AML.T0016.002 Generative AI, which names retrieval content crafting as one use).
In plain terms: a RAG system converts a question into a search, ranks stored chunks by similarity, and places the top results in the model's context. The model and the user both tend to treat retrieved text as the organisation's own knowledge. Retrieval content crafting exploits that ranking step. The text does not need to be clever to the human eye; it needs to score well for the right questions and look ordinary enough to survive filtering.
| ATLAS ID | Name | Question it answers for the attacker |
|---|---|---|
| AML.T0064 | Gather RAG-Indexed Targets | Which sources does the system index? |
| AML.T0066 | Retrieval Content Crafting | What must the content say to be retrieved for the target questions? |
| AML.T0070 | RAG Poisoning | How does the content get into the index and stay there? |
| AML.T0071 | False RAG Entry Injection | How can content pose as a separate, legitimate retrieved document? |
| AML.T0051.001 | LLM Prompt Injection: Indirect | What does the model do once the content is in context? |
Each of these has its own page; see MITRE ATLAS AML.T0064 Gather RAG-Indexed Targets and the prompt injection hub at MITRE ATLAS AML.T0051 LLM Prompt Injection.
How attackers use it: the ATLAS cases
| Case | Store and ingestion path | How the content was made retrievable | Outcome |
|---|---|---|---|
| AML.CS0026 Financial Transaction Hijacking with M365 Copilot as an Insider | Microsoft 365 Copilot index of received email | Zenity researchers wrote targeted content designed to be retrieved by specific user queries about banking details | Answer steered towards attacker-chosen transaction details |
| AML.CS0035 Data Exfiltration from Slack AI via Indirect Prompt Injection | Public channel messages searchable by all workspace members | The attacker posted in a public channel with only themselves as a member; the message used "API key" and related terms so it was retrieved alongside the victim's own private message | Secret appended to a link presented as "click here to reauthenticate" |
| AML.CS0059 EchoLeak (CVE-2025-32711) | Microsoft 365 Copilot index of received email | Business-like email text likely to be retrieved in later interactions; Aim Labs described spreading the payload across many topics so everyday questions (onboarding, HR, leave) would pull it in | Zero-click data exfiltration, fixed server-side by Microsoft |
The common pattern across these cases has three parts. First, query mirroring: the content repeats the words and phrasing a user would type for the target task. Second, coverage: one message or several are written to match many topics, which the EchoLeak researchers called RAG spraying. Third, camouflage: the text reads as normal business correspondence so that injection classifiers and human reviewers pass it. See the EchoLeak 2025 breach page for the full timeline and identity lessons.
Research shows how little content is needed. PoisonedRAG (Zou et al., arXiv preprint, version 3, August 2024) framed the attack as an optimisation problem with separate approaches for black-box and white-box attackers, and reported roughly 90% success with five malicious texts per target question. The authors evaluated several defences and found them insufficient. Treat this as evidence that volume-based thresholds alone will not catch a careful attacker.
Retrieval content crafting is not limited to internal indexes. Assistants that search the open web retrieve pages written by anyone; see the LLM Grooming and AI Search Poisoning guide, and AML.T0134 AI Targeted Cloaking for content served differently to AI crawlers.
What to detect and where
Most detection for this technique lives in the retriever, not the model. If your pipeline does not log what it retrieved for each answer, start there. OWASP LLM08:2025 Vector and Embedding Weaknesses calls for detailed, immutable logs of retrieval activity for the same reason.
| Layer | Signal | Fields you need |
|---|---|---|
| Retriever and ranker | A chunk from a low-trust or external source appears in the top results for many unrelated queries (high "retrieval breadth") | Query ID, chunk ID, document ID, source, trust tier, rank, similarity score |
| Retriever and ranker | A new document reaches top rank for sensitive intents (payments, credentials, HR, legal) within hours of ingestion | Ingestion timestamp, intent label of the query, rank |
| Ingestion pipeline | Clusters of near-duplicate chunks from one sender or account, or one message touching many unrelated topics | Sender or author, content hash, near-duplicate cluster ID, topic labels |
| Ingestion pipeline | Hidden or off-screen text, instruction-like phrasing, or text addressed to an assistant rather than a person | Extraction flags, scanner verdict, quarantine reason |
| Prompt and agent logs | Answers that contain links, payment details or credential requests not present in high-trust sources | Retrieved chunk IDs per answer, output URLs and entities |
| AI gateway | Outbound requests or rendered links built from retrieved content | Request URLs, query strings, the answer ID that produced them |
| Agent tool calls and MCP | A tool call whose arguments trace back to a low-trust chunk | Tool name, arguments, the context chunk IDs at decision time |
Two derived measures are worth building. Retrieval breadth is the number of distinct query intents for which a chunk appeared in the top results over a period; legitimate reference documents score high, but they should be high-trust. Source share is the proportion of context for sensitive intents that came from external or low-trust sources. A rise in either for one sender is worth a look.
Mitigations
ATLAS 2026.10 maps no mitigation directly to AML.T0066. NHI Mgmt Group recommends AML.M0020 Generative AI Guardrails, which ATLAS describes as controls that evaluate prompts, retrieved context, model outputs and agent actions before they are accepted. The practical controls below put that into effect at the ranking stage. Ingestion controls such as quarantine and trust tiers are on the AML.T0070 page and are not repeated here.
- Weight ranking by source trust. Combine similarity with the trust tier set at ingestion so that a well-matched external email cannot outrank a curated policy document for a sensitive intent. For payments, credentials and access changes, retrieve from high-trust sources only.
- Cap per-source share. Limit how many of the top results may come from one sender, mailbox, channel or domain. This breaks the spraying pattern where one author fills the context window.
- Collapse near-duplicates. Deduplicate near-identical chunks before ranking so five copies of one message count once.
- Apply a retrieval guardrail. Run retrieved chunks through a classifier for instructions addressed to the assistant, out-of-place links and credential or payment requests before they enter the context. Treat a hit as a reason to drop the chunk and alert, not just to warn the model.
- Keep retrieved content marked as data. Delimit retrieved text and label its source and trust tier in the context so the model and any downstream policy can treat it as untrusted. ATLAS AML.M0021 Generative AI Guidelines covers this kind of system-level instruction.
- Cite every chunk used. Show the user every retrieved source behind an answer, including external ones, so a planted message cannot hide behind a trusted citation.
- Enforce permissions at retrieval. Retrieve only what the asking user may read, so crafted content cannot pull another user's data into a shared context; see the Permission-Aware RAG Guide.
Small versus large deployments: a team running one internal assistant over a curated wiki gets most of the benefit from items 1, 3 and 6. Organisations that index inbound email, chat or web content for many users need all seven, plus the breadth and source-share monitoring above, because their stores accept writes from outsiders.
How to test
- Define target intents. List the sensitive questions users ask the assistant (bank details, password resets, supplier changes, approvals).
- Plant benign canaries. In a test tenant, send harmless marker documents through each external ingestion path, worded to match those intents, without any working instructions.
- Measure rank. Record whether and where each canary ranks for the target questions, with and without trust weighting and per-source caps.
- Test spraying. Repeat with one canary written to touch many topics and with several near-duplicate copies; confirm deduplication and caps hold.
- Confirm detection. Check that breadth and source-share alerts fire and that the answer cites the canary.
- Retest after change. Rerun whenever the embedding model, chunking, ranker or ingestion sources change, because all of these shift rankings.
Roll back by removing canaries by their marker ID and confirming they no longer appear in retrieval logs. Use an authorised test plan; see the AI Red Team Test Plan Template.
Measuring it
- Retrieval log coverage: percentage of answers with chunk IDs, sources and trust tiers recorded (target 100% for production assistants).
- Low-trust share for sensitive intents: proportion of context from low-trust sources for payment, credential and access questions (target zero).
- Canary rank: best rank achieved by test canaries for target intents after controls (target: outside the context window).
- Citation completeness: percentage of answers where every retrieved chunk is cited.
- Time to purge: time from detection of a crafted chunk to its removal from the index and any caches.
Common failure patterns
- Pure similarity ranking: treating the best match as the best source lets an external email outrank the finance policy.
- Partial citations: citing only the most relevant internal document, as in the Slack AI case, hides the chunk that carried the instruction.
- Classifier as the only gate: EchoLeak's business-like text passed an injection classifier; guardrails need ranking and source controls behind them.
- No retrieval logs: without chunk IDs per answer you cannot measure breadth, find the planted item or prove what the model saw.
- Silent ingestion growth: new sources, such as uploaded files and connected drives, are added to an assistant and change who can write to its index. Slack AI began ingesting uploaded documents and Google Drive files alongside messages on 14 August 2024, a setting owners and admins can restrict.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0066 Retrieval Content Crafting; AML.TA0001 AI Attack Adaptation | The technique and its tactic in ATLAS 2026.10 |
| MITRE ATLAS | AML.M0020 Generative AI Guardrails | Our recommended mitigation (no direct ATLAS 2026.10 mapping) |
| OWASP Top 10 for LLM Applications 2025 | LLM08:2025 Vector and Embedding Weaknesses; LLM01:2025 Prompt Injection | Data poisoning in RAG, retrieval logging, source validation; the injection the crafted content often carries |
| NIST SP 800-53 Rev. 5 | SI-10 Information Input Validation; SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting | Validating retrieved content, monitoring retrieval, reviewing retrieval logs |
| NIST SP 800-53 Rev. 5 | CA-8 Penetration Testing | Canary-based retrieval testing |
For the OWASP view see the OWASP LLM Top 10 LLM08 Vector and Embedding Weaknesses Guide.
Practitioner checklist
- List the sensitive intents your assistant serves and the sources allowed to answer each.
- Log query, chunk ID, source, trust tier, rank and score for every answer.
- Weight ranking by trust tier and restrict sensitive intents to high-trust sources.
- Cap results per sender, channel or domain and collapse near-duplicates before ranking.
- Run a retrieval guardrail on chunks before they enter the context.
- Cite every retrieved chunk in the answer, external ones included.
- Alert on retrieval breadth and low-trust source share per sender.
- Retest with benign canaries after any embedding, chunking, ranking or source change.
Standards and references
- MITRE ATLAS: Retrieval Content Crafting (AML.T0066)
- MITRE ATLAS: Generative AI Guardrails (AML.M0020)
- 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 (LLM08:2025 Vector and Embedding Weaknesses)
- 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
Related NHI Mgmt Group resources: MITRE ATLAS AML.T0071 False RAG Entry Injection, Threat Modelling RAG Systems, Vector Database Security Guide, MITRE ATLAS Guide.