Retrieval-Augmented Generation (RAG)

RAG addresses two problems at once: it reduces confabulation by grounding responses in retrieved source material, and it lets an application answer questions about content the model was never trained on — internal documents, a live product catalogue, recent support tickets. The tradeoff is a new attack surface at every stage of the retrieval pipeline.

The pipeline has three security-relevant stages. Ingestion: what content enters the index, from where, and with what validation? Retrieval: given a query, what content is returned, and is retrieval scoped to what the querying user or context is authorised to see? Generation: how does the model use the retrieved content — as a citation, as an instruction, or ambiguously as both?

Indirect prompt injection is the most consequential RAG-specific risk: content ingested into the knowledge base can carry instructions that the model treats as authoritative when it is later retrieved and placed in context. This is distinct from training-data poisoning — the model's weights are untouched; the poisoned content is retrieved fresh on each query, so removing it from the index removes the risk going forward.

Access control is the other primary risk category. A knowledge base that serves multiple users or tenants but retrieves without per-user authorisation scoping will surface content to a user who is not entitled to see it, functionally a broken-object-level-authorisation vulnerability expressed through a retrieval pipeline rather than a REST API.

Required controls: content validation at ingestion; retrieval scoped to the querying user's or context's authorisation, not just the corpus as a whole; source attribution in generated output so a claim can be traced back to what was actually retrieved; and a documented re-ingestion/re-validation trigger when the source content changes.