The vector store inherits every access problem
OWASP lists Vector and Embedding Weaknesses as its own entry. A vector store is a copy of your corpus in another shape: if the original documents had per-user access rules, the index does not inherit them, and anything retrievable is reachable by anyone the system will answer.
Why it is like this
Retrieval is a similarity search over everything indexed. There is no natural place for an authorisation check unless you build one, and the obvious design — index everything, filter later — filters after the model has already seen the passage.
Not to be confused with
A database with your permissions model. Embeddings also retain information about their source text, so an index is not an anonymising transformation — treat it with the sensitivity of the documents that went into it.
In practice
The correct pattern is to filter before retrieval, by the identity of the asker. Filtering the generated answer is too late: the passage was already in the prompt.
Source: OWASP Top 10 for Large Language Model Applications, 2025 — LLM08:2025 Vector and Embedding Weaknesses. Read on .
The OWASP Top 10 for LLM Applications is © the OWASP Foundation and published under a Creative Commons licence; NIST AI 600-1 is a US Government work in the public domain. These cards are independent commentary written in our own words. ytyk.org is not affiliated with or endorsed by the OWASP Foundation or NIST.
Predict Check yourself
An internal assistant indexes every document in the company and filters sensitive answers in post-processing. Where is the hole?
Show the answer
The restricted passage reaches the model before any filter runs — authorisation has to constrain retrieval, not the answer.
Once a passage is in the context, it can surface by paraphrase, summary or inference. Post-filtering guesses at all of those; pre-filtering does not have to.