RAG Security Cheat Sheet: Threats to Retrieval & Embeddings
RAG — retrieval-augmented generation — makes a model useful by feeding it your documents at query time. It also turns those documents, and the vector store that holds them, into an attack surface. This is what goes wrong (OWASP LLM09, Vector & Embedding Weaknesses) and how to lock it down.
Test your own pipeline only. Poisoning an index or probing retrieval belongs on a RAG system you own or are authorized to assess — not on someone's live assistant.
Why RAG is a security problem
Two things make RAG risky. First, retrieved content lands in the prompt as text, and the model can't reliably tell a document from an instruction — so anything you retrieve can act as an indirect prompt injection. Second, the vector store is shared, durable state: what one user puts in, another can pull out, and what you embed can sometimes be reconstructed. Both mean the retrieval layer needs the same suspicion you'd give any user input.
The threats
Six ways a RAG pipeline gets abused. Most incidents are one of these, or a chain of them.
| Threat | How it works |
|---|---|
| Indirect prompt injection | A retrieved document carries instructions. The model reads them as commands, not data — the attacker never touches the chat. |
| Index poisoning | An attacker gets malicious content into the knowledge base (a wiki edit, an uploaded file), so it surfaces in future answers. |
| Cross-tenant leakage | One user's query retrieves another user's or tenant's documents, because retrieval isn't scoped to who's asking. |
| Access-control bypass | The model surfaces content the user isn't allowed to see, because permissions were enforced at the app but not at retrieval. |
| Embedding inversion | Embeddings aren't anonymised. Given enough of them, an attacker can reconstruct approximations of the original source text. |
| Sensitive over-retrieval | More than the answer needs is pulled into context — secrets, PII, whole documents — widening what a single injection can exfiltrate. |
Lock it down
The fixes are mostly about where you enforce trust: at retrieval, not just at the app.
- Enforce access control at retrieval. Filter what can be retrieved by the asking user's permissions before anything reaches the model — not after. This is the single biggest one.
- Isolate tenants. Separate indexes or hard metadata filters per tenant, so one customer's query can never match another's vectors.
- Treat retrieved text as untrusted. It can carry injection. Don't let it silently rewrite the system prompt or trigger tool calls; keep instructions and retrieved data at different trust levels.
- Validate what you index. Scan and sanitise documents before they enter the store — index poisoning happens at ingest, so that's where you catch it.
- Minimise what you embed. Keep secrets and unnecessary PII out of the index entirely; you can't leak or invert what isn't there.
- Retrieve less. Return the smallest set of chunks that answers the question — tighter retrieval shrinks the blast radius of any single injection.
- Monitor retrieval. Log what gets retrieved for whom; odd patterns (one user pulling broad, sensitive chunks) are an early signal.
Go deeper
- Prompt injection — especially the indirect kind, which is how most RAG attacks land.
- OWASP LLM Top 10 — LLM09 in the context of the full risk map.
- AI agent security — when the RAG system can also act, not just answer.
- LLM security lab — work the RAG and embedding challenges hands-on.
Aligned to OWASP LLM09:2026 Vector & Embedding Weaknesses; a plain-language distillation of current RAG-security practice. Running RAG and want a control added here? Tell me.