MITRE ATLAS AML.T0071 False RAG Entry Injection: Detection, Mitigation and Response

If text inside one retrieved chunk can make the model believe it is looking at a second, separate document, an attacker can forge a source that no index, monitor or deletion process knows exists. MITRE ATLAS tracks this as AML.T0071 False RAG Entry Injection, in the Defense Evasion tactic (AML.TA0007). ATLAS describes content, designed to be interpreted by the LLM as a document, hidden inside a normal entry in the retrieval database, so that when the entry is retrieved the model treats part of it as a separate RAG result. Because the false document lives inside a legitimate entry, ATLAS notes it bypasses data monitoring tools and cannot be deleted directly. Broader content poisoning of search and retrieval is covered in LLM Grooming and AI Search Poisoning and memory poisoning in the OWASP Agentic Top 10 ASI06 Guide. This page is about the prompt-assembly weakness that makes a fake entry possible and how to design it out. It is for engineers who build RAG prompt templates and ingestion, and for analysts who investigate odd answers.

Key takeaways

• It is a boundary forgery. The attack works when the markers your template uses to separate retrieved documents can be reproduced by text inside a document.
• Your index sees one real entry. Monitoring, access control and deletion all operate on the real entry, so the forged one has no record of its own.
• Template keywords are reconnaissance targets. ATLAS says adversaries may use discovered system keywords to learn how to make a model treat content as a RAG entry, which makes system prompt leakage a precursor.
• Metadata is forged too. ATLAS notes the attacker may set the injected entry's title, author and creation date, so provenance shown from model text is worthless.
• Unforgeable boundaries are the fix. Our recommendation: per-request random delimiters, escaping of anything that resembles your boundary format, and structured retrieval passed outside free text where the platform allows it.

How it differs from related techniques

ATLAS created AML.T0071 in March 2025, last modified it in December 2025, and rates it as demonstrated. It is easy to confuse with neighbouring techniques; the differences decide which controls apply.

In practice these appear together. ATLAS case study AML.CS0026 combines them: an email to a Microsoft 365 Copilot user carried content designed to be retrieved for banking-detail queries (AML.T0066), an obfuscated injection (AML.T0068), a marker that made the retrieved text look like a snippet from a real document (AML.T0071), and citation instructions (AML.T0067.000).

Why prompt assembly is the weak point

Most RAG systems build a single text prompt: system instructions, then retrieved chunks separated by headers such as a document number, title and source, then the user question. The model has no structural way to know where one chunk ends; it infers it from the text. If a chunk contains text that looks like the end of a document and the start of another, the model may accept it. Three design facts make this easier for an attacker:

• Static, guessable separators: the same header format on every request, often visible in leaked or published system prompts. See the OWASP LLM Top 10 LLM07 System Prompt Leakage Guide.
• Metadata as text: titles, authors and dates inserted as plain text beside content, so a forged header carries forged metadata.
• Mixed-trust collections: external email or web content indexed alongside internal documents with the same formatting.

Designing it out

1. Random per-request delimiters: wrap each retrieved chunk in a boundary token generated per request and not stored anywhere an attacker can read. Microsoft's July 2025 MSRC post describes this as the delimiting mode of spotlighting.
2. Escape lookalike boundaries at ingestion: detect and neutralise text in documents that resembles your chunk header format or common RAG markers, and log the event.
3. Datamark untrusted content: spotlighting's datamarking mode interleaves a marker through untrusted text so instructions inside it are easier for the model to treat as data.
4. Use structured inputs where available: some model APIs accept documents or search results as separate structured objects rather than concatenated text; check your provider's current documentation and prefer them where supported.
5. Metadata from the store: show users titles, authors and dates from the index record of the real chunk, never from anything in the model output.
6. Separate trust tiers: keep external-origin content in its own collection with a visible origin label, and exclude it from sensitive workflows such as payments and credential help.

Roll out in stages: enable random delimiters and lookalike escaping in monitor mode, compare answer quality on an evaluation set, then enforce. Rollback is a template version switch, so keep templates versioned. For retrieval access design, see the Permission-Aware RAG Guide.

Detection and measurement

ATLAS mitigation AML.M0024 AI Telemetry Logging makes investigation possible: log retrieved chunk IDs, the assembled prompt (or a hash and template version) and the completion.

Measuring it

• Delimiter coverage: share of RAG applications using per-request random boundaries.
• Lookalike hits: boundary-like strings found per thousand ingested items, by source.
• Phantom citations: citations whose title or ID does not match a retrieved chunk (target zero).
• Purge time: time to remove or re-index a source entry once a false entry is found inside it.

Response

1. Find the carrier: from the logs, identify which real chunk contained the false entry; the forged title will not exist in the index.
2. Remove at source: delete or quarantine the carrier document at its origin (mailbox, site, repository), then remove its chunks and vectors; deleting the forged title is not possible because it is not a record.
3. Sweep: search the index for the same marker strings and for other items from the sender or source.
4. Assess impact: list users who received answers based on the carrier and check for actions taken, such as payment changes.
5. Harden: add the marker to the ingestion scanner and the case to regression tests; follow the Prompt Injection Incident Response Playbook.

Common failure patterns

• Static template headers: the same document separator on every request, published in a blog or leaked in a system prompt.
• Trusting model-stated provenance: showing the title and date the model wrote instead of the index record.
• Deleting by title: responders search the index for the forged document, find nothing and close the case.
• External mail in the main index: inbound email indexed with the same weight and format as internal policy documents.
• Chunk-only scanning: scanning chunks for injection phrases but not for structural markers that mimic the template.

Framework mapping

Practitioner checklist

• Generate a random chunk boundary per request and keep it out of logs readable by users.
• Escape boundary-like and RAG-marker strings in content at ingestion, and log each hit.
• Render citation titles, authors and dates from the index record only.
• Reject or flag answers that cite more documents than were retrieved.
• Keep external-origin content in a separate, labelled collection.
• Treat the RAG prompt template as sensitive and version it.
• Log chunk IDs and template version with every completion.
• In incidents, remove the carrier at source and re-index, not the forged title.

Standards and references

• MITRE ATLAS: False RAG Entry Injection (AML.T0071)
• MITRE ATLAS: Financial Transaction Hijacking with M365 Copilot as an Insider (AML.CS0026)
• MITRE ATLAS: RAG Poisoning (AML.T0070)
• OWASP: Top 10 for LLM Applications 2025
• Microsoft MSRC: How Microsoft defends against indirect prompt injection attacks
• The Register: Copilot vulnerabilities presented at Black Hat 2024
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: RAG Security Guide, Threat Modelling RAG Systems, MITRE ATLAS AML.T0067 LLM Trusted Output Components Manipulation, Vector Database Security Guide.