False RAG entry injection is an attack where fake document text is placed inside an ordinary entry in a RAG data source, so that when the entry is retrieved, the model treats part of it as a separate retrieved result. ATLAS says it bypasses data monitoring and stops the fake document being deleted directly.
How it works
ATLAS describes the technique like this. The adversary adds content to a data source that will be ingested into the victim's RAG database. The content is shaped so the language model reads it as a document. When the entry is retrieved, the model is tricked into treating part of it as a false RAG result.
The adversary may use system keywords they have discovered to learn how to instruct a given model to treat content as a RAG entry. They may also manipulate the entry's metadata, such as document title, author and creation date.
Why it is hard to catch
ATLAS gives two reasons.
It bypasses data monitoring tools. The fake document sits inside a regular entry, so tools that inspect entries as units see a normal entry.
It cannot be deleted directly. The fake document has no entry of its own. To remove it, you must change or remove the carrying entry.
A third effect follows from the metadata point: a fake document can claim a trusted author or a recent date, which may raise the weight people or the ranker give it.
Where it fits
It sits next to related techniques in the 2026.09 data. Gather RAG-Indexed Targets finds the sources. Retrieval Content Crafting writes content designed to be retrieved. RAG Poisoning places manipulated content in indexed locations. False RAG Entry Injection is the variant that hides a fake document inside a real one. The mapping guide shows them together.
Reducing the exposure
These steps are practical measures, not a list from ATLAS.
- Separate structure from content. Build the prompt with clear delimiters that retrieved text cannot imitate, and strip or escape any marker syntax inside retrieved content before it reaches the prompt.
- Do not let content set metadata. Title, author and date should come from your system of record, not from text inside the file.
- Show provenance to the model and the user. Pass the true source and trust level of each chunk, and display citations people can click.
- Check chunks, not only entries. Scan the text of each chunk for strings that mimic your own document format.
- Log chunk IDs so a suspicious answer can be tied to the carrying entry.
- Make removal easy. Have a documented way to quarantine an entry and re-index.
How to test
Write a harmless entry containing text that imitates your own retrieved-document format, with a marker word as the "result". Ingest it, ask a matching question and see if the marker is treated as a separate source in the answer or in citations. If it is, your prompt structure can be spoofed.
Quick check
Is this the same as ordinary RAG poisoning?
It is a variant. Ordinary poisoning adds a bad document. This one hides a fake document inside a normal entry to avoid entry-level checks.
Would a stronger model fix it?
Not reliably. Fix the prompt structure and metadata handling, which you control.
Sources
- MITRE ATLAS data repository (mitre-atlas/atlas-data), technique AML.T0071 and related techniques, 2026.09 release.
Last reviewed: 19 October 2026.
