OWASP's LLM08:2025 covers weaknesses in how retrieval augmented generation systems create, store and retrieve embeddings. The controls that work are architectural: permission-aware vector stores, validated and authenticated sources, classified data, and tamper-resistant retrieval logs. A line in a system prompt is not on that list.
What is LLM08, in plain terms?
Many LLM apps answer questions by retrieving text from a knowledge base, stored as vectors, and handing it to the model. OWASP describes the risk as weaknesses in generating, storing or retrieving those embeddings that can be exploited, on purpose or by accident, to inject harmful content, change model output or expose sensitive information.
The data layer becomes part of your attack surface. It is easy to forget, because it feels like "just search".
Which risks does OWASP list?
- Unauthorized access and data leakage. Weak access control lets users reach embeddings that hold personal or proprietary data.
- Cross-context leaks. In a multi-tenant setup sharing one vector database, one group's context can surface in another group's queries. Conflicting sources can also confuse the model.
- Embedding inversion. Embeddings can be reverse engineered to recover much of the original text, so a vector is not a safe stand-in for the document.
- Data poisoning. Insiders, seeded data or unverified providers can corrupt the knowledge base.
- Behavior alteration. Retrieval can change how the model answers, for example making answers accurate but less empathetic.
Which controls work?
OWASP lists four groups of mitigation. Here is what each looks like in practice.
Permission-aware retrieval. Use fine-grained access control in the vector store and partition datasets so groups cannot reach each other's data. Filtering must happen in the retrieval layer, before text reaches the model.
Validation and source authentication. Accept data only from trusted, verified sources, validate it in a pipeline, and audit the knowledge base for hidden content. OWASP's example is a resume with invisible text telling the screening system to favor the applicant. Its fix is text extraction that ignores formatting and detects hidden content, with validation before a document enters the knowledge base.
Classification when combining sources. Review merged datasets, and tag content so access levels hold and mismatches are caught.
Monitoring and logging. Keep detailed, tamper-resistant logs of retrieval so odd behavior can be found quickly.
Which controls do not work?
OWASP does not publish a "does not work" list, so what follows is our reading, tied to its text and to LLM06.
Telling the model in a prompt not to reveal another tenant's data is not access control. The model should never receive that data in the first place, which is what the permission-aware store achieves. OWASP's LLM06 page makes the same point from the other side: enforce authorization in downstream systems instead of trusting the LLM to decide.
Treating embeddings as anonymized is also unsafe, given the inversion risk OWASP names. If the source text is sensitive, so are its vectors.
And one-time data review is thin. OWASP asks for regular audits, because a knowledge base keeps changing.
What about the empathy example?
It looks minor, but it is a quality control point. OWASP describes a student loan scenario where the base model gave supportive advice and the retrieval augmented version gave purely factual, transactional answers. Its mitigation is to monitor and evaluate how retrieval changes behavior, and tune accordingly. Add evaluation to your release checks, not just security tests.
What to do
- Map every vector store to its data owners and the people allowed to read each partition.
- Enforce access checks in retrieval, using the end user's identity, not a shared service account.
- Separate tenants logically and physically when data is sensitive.
- Put an ingestion pipeline in front of the knowledge base that authenticates the source and strips hidden or formatting based content.
- Treat embeddings of sensitive text as sensitive data in classification and retention rules.
- Log retrieval requests in a form that cannot be edited by the application team, and review them.
- Re-audit the knowledge base on a schedule.
Safeguard covers adjacent ground: software composition and SAST for the code around your RAG pipeline, and an MCP server so agents can query security context. It does not replace data-layer access control.
Quick check
Are embeddings safe to share because they are just numbers?
No. OWASP names embedding inversion, where much of the original text can be recovered, so sensitive text should be treated as sensitive in vector form too.
Where should access control be enforced in a RAG system?
In the retrieval layer, using a permission-aware vector store, before any text reaches the model.
Sources
Last reviewed: 18 October 2026.
