A retrieval augmented generation system is only as safe as the documents it can fetch and the permissions it honors while fetching. The two failures to design against are poisoned content that steers answers and retrieval that ignores who is asking. OWASP covers both under LLM08, and these ten questions put it into practice.
What can go wrong?
OWASP's LLM08:2025 describes weaknesses in how vectors and embeddings are generated, stored or retrieved. It names the main risks: inadequate or misaligned access controls that expose embeddings containing sensitive information, context leaking between groups that share one vector database, poisoned data from insiders or unverified providers, and the possibility of recovering source text from embeddings.
OWASP gives a concrete scenario. A resume contains hidden white-on-white text telling the system to recommend the candidate. A screening system built on retrieval ingests it and later follows the hidden instruction. No exploit code was needed. The document itself was the payload.
The ten questions
Access
- Does retrieval filter by the asking user's permissions before results reach the model, or only afterwards?
- If several teams or customers share one vector store, are their data partitioned by access level?
- When a document's permissions change at the source, how long until the index reflects it?
Content 4. Who can add documents, and are sources authenticated and trusted? 5. Do you extract text with a tool that ignores formatting tricks and flags hidden text before indexing? 6. Do you scan new documents for instruction-like content aimed at the model?
Behavior 7. What can the model do with what it retrieves? If it can send email or call tools, a poisoned document has a path to action. Keep high-impact actions behind human approval, as OWASP advises for prompt injection. 8. Are answers shown with their source documents, so a reviewer can see what influenced them?
Operations 9. Do you keep detailed, tamper-resistant logs of what was retrieved for whom? OWASP recommends immutable logs of retrieval activity so suspicious behavior can be detected. 10. Do you have a way to remove a bad document and everything derived from it, fast?
What to do
- Move permission checks into the retrieval layer so unauthorized chunks are never fetched.
- Partition indexes by tenant or sensitivity, and test with two test users who must not see each other's data.
- Put an intake step before indexing: source check, text extraction that surfaces hidden text, and review.
- Classify documents so classification travels with each chunk.
- Strip the model's tool access to the minimum, and require approval for anything with side effects.
- Display citations to the retrieved sources in every answer.
- Log queries, retrieved chunk identifiers and the requesting identity.
- Run adversarial tests with benign marker text in your own test documents, and confirm the system does not obey them.
- Write a takedown runbook: find, remove, re-index, review logs for earlier use.
Why does poisoning matter for training too?
OWASP's LLM04 treats poisoning as an integrity attack on pre-training, fine-tuning or embedding data. Its advice for tracking data provenance, vetting vendors and monitoring behavior carries over to knowledge bases. Treat your document store like a supply chain with its own inventory.
Quick check
Is it enough to tell the model not to reveal restricted documents?
No. OWASP notes that prompt-level restrictions may not always be honored and can be bypassed. Enforce permissions in retrieval so the model never sees content the user may not read.
What is the simplest test for access control in RAG?
Create two test users with different permissions, plant a unique marker phrase in a document only one can read, and confirm the other user cannot retrieve or infer it through questions.
Sources
- OWASP GenAI: LLM08:2025 Vector and Embedding Weaknesses, fetched 18 October 2026.
- OWASP GenAI: LLM04:2025 Data and Model Poisoning, fetched 18 October 2026.
- OWASP GenAI: LLM01 Prompt Injection, fetched 18 October 2026.
Last reviewed: 18 October 2026.
