How do you secure a RAG (retrieval-augmented generation) pipeline?

Retrieval-augmented generation grounds an LLM by fetching relevant documents from a knowledge base (usually a vector store) and stuffing them into the prompt. That extra context is also a new, large attack surface, and the core mindset is: every retrieved chunk is untrusted input.

Stage-by-stage risks

• Ingestion. Whatever you index, the model will later read and may obey. A poisoned or attacker-authored document becomes an indirect prompt injection that fires in someone else's trusted session. Vet sources, track provenance, and restrict who can contribute to the corpus.
• Storage / embeddings. Vector stores can be poisoned (planting adversarial documents that always rank highly) and embeddings can leak information through inversion attacks. Isolate stores per tenant and protect them like any sensitive datastore.
• Retrieval. The biggest practical failure is authorization: if retrieval doesn't filter by the requesting user's permissions, the model surfaces documents they should never see. Enforce access control at query time, scoped to the user — not as a post-hoc filter on the answer.
• Generation. Clearly delimit retrieved content as data, instruct the model not to follow instructions found inside it, and validate/sanitize the output before it's rendered or passed to tools.

Defense in depth

Combine least-privilege retrieval, ingestion vetting and signing, per-tenant isolation, indirect-injection mitigations, and output validation. No single control is sufficient.

What interviewers look for

The "retrieved content is untrusted" framing, calling out per-user authorization at retrieval, and awareness of indirect injection and knowledge-base poisoning as RAG-specific threats — not just generic database security.