Two case studies in MITRE ATLAS show the same pattern in RAG systems: untrusted text reaches the index, a later query retrieves it, and the model follows it. Morris II was a research worm that spread through an email assistant. The Slack AI case showed private data leaving through a public channel post.
Case one: Morris II
ATLAS describes Morris II as a zero-click worm built by researchers to attack generative AI ecosystems and spread between connected systems. It uses an adversarial self-replicating prompt that relies on prompt injection to copy itself into the model's output.
The researchers showed it on an email system with a RAG-based assistant. The target automatically ingests incoming mail, retrieves past correspondence and drafts a reply. A malicious email lands in the RAG database. Its instructions tell the assistant to include sensitive user data in the reply. Later requests may retrieve that email again, so the prompt replicates and the leak continues.
The design lesson: the assistant treated an incoming email as both data and instruction, and it wrote that email into a store it would trust later.
Case two: Slack AI
ATLAS records that a security firm demonstrated that private data could be exfiltrated from Slack AI through indirect prompt injection. The attack relied on Slack AI ingesting a malicious prompt from a post in a public channel into its RAG database, and then a victim user querying Slack AI, which caused the prompt to be retrieved and executed.
The design lesson here is about trust boundaries. Content that anyone in a public channel can write ended up in the same retrieval pool as content a user would later ask about privately.
What both have in common
- The attacker never touched the model directly. They only needed to write somewhere the index reads.
- The harm happened at retrieval time, not ingestion time. A scan at upload can miss it.
- The output path mattered. Each case needed a way for data to leave, through a reply or a rendered response.
Design changes that follow
Separate the write path from the trust level. Content from untrusted authors should be tagged as untrusted at ingestion, and retrieval should carry that tag into the prompt.
Do not auto-ingest what the assistant produces. Writing model output or incoming mail back into the index without review creates the loop that Morris II used.
Control what leaves. Limit what the assistant can include in a reply or a link, and check outputs with code that is not the model.
Permission-check retrieval. The retrieval step should respect who is asking. The permission-aware retrieval guide covers this.
Log retrievals. If you can see which chunk drove an answer, you can find the poisoned one. See what to log for RAG incident response.
Using case studies well
Read them for the mechanism, not the product. The same steps apply to any assistant that reads text from people you do not control. ATLAS holds many more case studies, and each links to the techniques it used, so you can go from a story to the control you would need.
Quick check
Do these attacks need the attacker to be inside the company?
Not in these cases. Morris II needed to send an email to the target, and the Slack AI case needed a post in a public channel.
Would an input filter at upload have stopped them?
It might catch some payloads, but filters are not complete. Controls at retrieval time and on outputs are needed as well.
Sources
- MITRE ATLAS data repository (mitre-atlas/atlas-data), case studies AML.CS0024 and AML.CS0035 in the 2026.09 release.
Last reviewed: 19 October 2026.
