Almost everyone treats the RAG index as a database. It is untrusted input with high priority — the whole pipeline exists precisely to push that text into the model's context.
The boundary is at ingestion
Access control usually sits on the query side: who may ask. But the risk sits with who may write to the corpus. Internal wiki, shared drive, meeting transcripts, ticket base — if anyone in the company (or a public form) feeds the index, anyone can plant an instruction the agent will read with maximum confidence.
Whoever controls one paragraph of the corpus controls a slice of everybody's prompt.
Retrieval is the attacker's choice too
The poisoned document does not have to be retrieved by accident: it can be written to win the search. Repeat the terms of the expected question, cover the synonyms, pad it with plausible context. It is search engine optimisation, turned against your retriever.
What to apply
- Tag every retrieved chunk with its origin and confidence level, and hand that to the model alongside the text.
- Separate curated corpus from open corpus, with a distinct policy for each.
- A fixed rule: retrieved content is reference, never instruction. No action fires straight from a document chunk.
- Write review for low-trust sources before indexing, not after the incident.
The reindex detail
A document approved today can be edited tomorrow. If reindexing is automatic and approval was manual, you validated one version and you serve another. Either approval binds to a content hash, or it is worth nothing.
