RAG Security
RAG security means treating retrieved documents as untrusted data and filtering retrieval by the requesting user’s actual permissions.
Prerequisites
Overview
RAG introduces two distinct security concerns: a retrieved document could contain adversarial instructions (a form of prompt injection), and retrieval could surface content the requesting user isn’t actually permitted to see.
Where It Fits
Query
Permission-Filtered Retrieval
Only what this user can see.
Retrieved Content
Treated as untrusted data.
Model
Key Points
- Permission-aware retrieval
- Retrieval must be filtered by the requesting user’s actual access rights, not just similarity — otherwise search can leak content across permission boundaries.
- Retrieved content as untrusted data
- A document from your own index can still carry adversarial text if it was ingested from an external or user-editable source.
- Index poisoning
- If users can contribute content that later gets indexed and retrieved for others, that’s a path for injecting adversarial instructions into the system.
Interview Question
Why not simply store embeddings in PostgreSQL without any additional access controls?
That question is really about vector storage generally, not RAG security specifically — but the security answer is the same either way: retrieval needs to be filtered by the requesting user’s actual permissions at query time, or similarity search can surface documents across permission boundaries regardless of which database stores the vectors. The storage choice doesn’t solve that — the filtering logic does.
Explain It in 30 Seconds
RAG security means two things: filtering retrieval by the requesting user’s real permissions, not just similarity, and treating every retrieved document as untrusted data that could carry adversarial instructions, especially if the index accepts externally- or user-contributed content.
Real-World Stack
Technologies commonly used to implement this in production.