To stop one user's data surfacing in another user's answers, make retrieval permission-aware: filter results by the asking user's access rights before anything reaches the model, and partition data by tenant or access level. OWASP lists weak access control in shared vector stores as a core risk in LLM08.
The failure
OWASP's LLM08:2025, Vector and Embedding Weaknesses, describes cross-context leaks in multi-tenant vector databases, where context can leak between users or queries. Its example scenario is a shared database in which one group's embeddings are retrieved for another group's queries, exposing business information.
It happens easily. A team builds a prototype over one folder, it works, and then more folders and more customers get added to the same index. The model never sees an access list. It sees whatever the retriever hands it.
Where the check belongs
Put the permission check in the retrieval layer, in code, before the prompt is built. Do not ask the model to hide things it was given. OWASP's prompt injection guidance makes the general point that privileged functions should be handled in code rather than relying on the model.
Two common designs:
Separate stores or namespaces per tenant. Simple and strong isolation. Costs more to run and manage as tenants grow.
One store with metadata filters. Each chunk carries tenant and access labels, and every query is run with a filter built from the caller's identity. Cheaper, but one missing filter is a leak.
OWASP's mitigation list names fine-grained, permission-aware vector stores and logical partitioning by access level. It also recommends tagging and classifying data to control access and prevent mismatches.
Checklist
- The user's identity reaches the retriever from your auth layer, not from the prompt.
- Every query has a mandatory filter. A query with no filter should fail, not return everything.
- Labels are attached at ingestion and cannot be set by the document author.
- When source permissions change, the index updates. Stale copies of revoked documents are a quiet leak.
- Combined datasets are reviewed. OWASP calls out reviewing merged data and classification so access levels do not get mixed.
- Retrieval events are logged with the user and chunk IDs. OWASP recommends detailed, immutable logs of retrieval activity.
Test it
Write three tests and run them on every release.
- User A asks a question whose only answer is in user B's document. The answer must not contain it.
- Revoke a user's access to a document, re-index, and ask again.
- Send a query with a missing or malformed identity. It should be refused.
These tests are quick to write and catch the most common mistake, which is a code path that skips the filter.
What it does not cover
Permission-aware retrieval protects confidentiality across users. It does not stop poisoning from a writer who is allowed to write, and it does not stop prompt injection inside a document the user is allowed to read. Those need separate controls. See how RAG poisoning attacks work.
Quick check
Is embedding the data enough to hide it?
No. OWASP lists embedding inversion, where attackers reverse embeddings to recover much of the original information, so embeddings need the same access controls as the source.
Should the model decide what a user may see?
No. Filter in code before the model sees the text.
Sources
Last reviewed: 19 October 2026.
