RAG security: how do poisoned documents and weak access control hurt you?

A retrieval augmented generation app can leak data or follow hostile text because the knowledge base is an attack surface. Poisoned documents change answers, and loose access control lets one user retrieve another user's content. Fix both at the data layer, not in the prompt.

OWASP names this class "Vector and Embedding Weaknesses" in its 2025 list for LLM applications. The page is short and worth reading in full. Below are the mistakes it points at, in the order teams usually hit them.

Mistake one: one index for everyone

The easy design puts every document into a single vector store and relies on the app to be polite. OWASP lists "unauthorized access and data leakage" first: weak or misaligned access controls can let embeddings holding sensitive information be retrieved and disclosed. In multi-tenant setups, where several user classes or apps share one vector database, it also describes cross-context leaks between users or queries.

The control it recommends is permission-aware vector and embedding stores, with strict logical and access partitioning of datasets. In practice that means the permission check happens at retrieval time, using the identity of the person asking, before any text reaches the model. A system prompt that says "only answer from documents the user may see" is not a control.

Mistake two: trusting whatever gets ingested

Poisoning can be deliberate or accidental. OWASP says poisoned data can come from insiders, prompts, data seeding or unverified data providers. Its worked example is a resume containing hidden white-on-white text that instructs the model to recommend the candidate. The screening system ingested the text and later followed it.

The academic work agrees on the shape of the problem. A paper titled PoisonedRAG describes the knowledge database in a RAG system as a new and practical attack surface. We cite it for the framing only and describe no technique here.

Defensive points from OWASP: validate documents before they enter the knowledge base, use text extraction that ignores formatting and detects hidden content, accept data only from trusted and verified sources, and audit the knowledge base regularly for hidden instructions and poisoning.

Mistake three: treating retrieved text as instructions

OWASP's prompt injection entry describes indirect injection, where the model reads content from files or websites and that content alters its behavior. It includes a scenario where an attacker modifies a document in a repository used by a RAG app, so the changed text steers answers when a query retrieves it. It also says RAG and fine-tuning do not fully mitigate prompt injection.

So label retrieved text as untrusted data, keep it separate from instructions, and limit what the model can do after reading it. If the model can send email or call internal tools, a poisoned document becomes an action, not just a wrong answer.

Mistake four: no record of what was retrieved

When something odd happens, teams cannot say which chunk produced the answer. OWASP recommends detailed immutable logs of retrieval activity so you can detect and respond to suspicious behavior. Log the query, the identity, the document ids and the scores. Keep the log somewhere the app cannot rewrite.

Mistake five: mixing data classes silently

Combining sources without review creates conflicts and leaks. OWASP advises reviewing combined datasets and tagging and classifying data in the knowledge base to control access levels. A public FAQ and an HR policy folder should not sit in one undifferentiated pile.

What to do

1. Inventory every source feeding the index and name an owner for each.
2. Attach the source ACL or classification to each chunk as metadata at ingestion.
3. Filter by that metadata at query time using the caller's identity, not a service account.
4. Strip formatting and scan for hidden text before documents are embedded.
5. Restrict who can write to source repositories, and review changes to indexed documents.
6. Treat retrieved text as data and cap the model's tools after retrieval.
7. Log retrievals immutably and review them for odd patterns.
8. Test with a seeded document you control, to confirm a lower-privileged user cannot retrieve it.

Quick check

Sources

• OWASP LLM08:2025 Vector and Embedding Weaknesses, fetched 18 October 2026
• OWASP LLM01:2025 Prompt Injection, fetched 18 October 2026
• PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models, arXiv, abstract fetched 18 October 2026

Last reviewed: 18 October 2026.