A RAG red team test plan should cover seven things: who can write to the index, hidden text in documents, cross-user retrieval leaks, injected instructions that trigger tool calls, secrets in the index, output exfiltration paths, and whether your logs can explain what happened. Each can be tested in a day with a harmless marker.
Ground rules
Use the planning habits from the ATLAS AI Red Team mitigation: written scope, rules of engagement, stop conditions, and cleanup. Run tests in a staging copy when you can. Use harmless markers such as a made-up word, never real secrets or real customer data. Remove every test document afterwards.
The tests
1. Write access to the index. List every location the ingestion job reads. For each, who can add or change files? Add a marker document through the least trusted path you find. Does it get indexed? How long until it shows up in answers?
2. Hidden text. Make a file with a hidden instruction, such as white text that says to reply with a marker word. Upload it through each ingestion path. See the hidden text defence guide.
3. Cross-user leaks. With two test users in different groups, plant a marker in user B's data and ask for it as user A. Repeat after revoking access. OWASP's LLM08 scenario of one group's embeddings retrieved for another is exactly this.
4. Injected tool calls. If the assistant has tools, plant an instruction in a retrieved document that asks for a harmless tool call, such as creating a test note. Does it happen without approval?
5. Secrets in the index. Ask the assistant for API keys, passwords and tokens. ATLAS describes RAG Credential Harvesting, where credentials in internal documents get ingested and then retrieved by an agent. Better still, scan the source documents for secrets before you ever need this test.
6. Exfiltration paths. Can the assistant render links, images or formatted output that carry data to an outside address? Test what the interface renders from model output.
7. Observability. For each test above, try to answer from logs alone: which chunk was retrieved, who added it, which tool ran. Gaps become findings. See what to log.
Record results
Use one row per test:
- Test name and ATLAS technique it covers
- Steps to reproduce
- Result: blocked, partly blocked, succeeded
- Evidence location
- Owner and fix date
After the run
Fix what succeeded. Convert each success into an automated regression test, as described in evals versus red teaming. Retest after the fix.
What this plan does not cover
It does not test the model itself for jailbreaks or harmful content, nor does it replace a broader exercise by specialists. It is a minimum for the retrieval path.
Quick check
Can I run this against production?
Prefer staging. If you must use production, use only harmless markers, agree stop conditions first and clean up every artifact.
How long does it take?
For a single app with a few ingestion paths, a day of focused work is realistic, though results vary by system.
Sources
- MITRE ATLAS data repository (mitre-atlas/atlas-data), AML.M0035 and AML.T0082, 2026.09 release.
- OWASP LLM08:2025 Vector and Embedding Weaknesses
Last reviewed: 19 October 2026.
