In a multi-tenant RAG system, enforce access control at retrieval time, so the search only returns chunks the requesting user may see. OWASP names cross-context leaks in shared vector databases as a core risk, and recommends permission-aware stores and strict partitioning between user groups.
The failure mode
RAG works by retrieving relevant text from a vector database and giving it to the model. If several customers share one database and retrieval ignores who is asking, the nearest match to a question can belong to someone else.
OWASP's scenario is exactly this: in a shared multi-tenant database, one group's embeddings are retrieved for another group's queries. The model then summarises content the user was never entitled to see. No attacker is needed.
Where to enforce permissions
Enforce at retrieval, not afterwards.
- Before the search. Filter the candidate set by tenant and by the user's entitlements, so restricted items never rank.
- Not in the prompt. Telling the model "only use documents the user may see" is not access control. OWASP stresses fine grained, permission aware vector stores.
- Not only at the UI. Hiding a citation in the interface does not stop the content shaping the answer.
Partitioning options
Choose by how strict the isolation must be:
- Separate store per tenant: isolation Strongest; cost and complexity Highest operational overhead
- Separate collection or namespace per tenant: isolation Strong; cost and complexity Moderate
- Shared index with metadata filters: isolation Depends on filter correctness; cost and complexity Lowest, easiest to get wrong
A shared index with filters is common and can be sound, but a single missing filter becomes a data leak. Test the filter path as you would an authorisation check.
Other items from the same OWASP page
- Review and classify combined datasets so data from different sources is tagged and access is controlled.
- Validate and authenticate data sources, and audit the knowledge base for hidden content and poisoning.
- Keep detailed, immutable logs of retrieval activity so suspicious behaviour can be found afterwards.
The page also warns about embedding inversion, where attackers recover significant source information from embeddings. That means embeddings are sensitive data and deserve the same access controls as the text they came from.
Test it
Create two tenants with distinct, recognisable content. Ask tenant A questions that tenant B's content would answer well. Any citation or paraphrase of B in A's answer is a leak. Run this in your test suite and after every indexing change.
Safeguard's compliance and evidence automation can keep the test results as evidence for audits.
Common mistakes. Filtering after retrieval is the classic error: the top results are fetched across all tenants, then filtered, and the answer is built from whatever survived or from a cache. Caches are another hazard. A semantic cache keyed on question similarity can serve one tenant's answer to another. Scope cache keys by tenant and permission set, and include them in your leak tests.
Quick check
Is the embedding itself sensitive?
Yes. OWASP notes that embedding inversion can recover significant information from embeddings.
Sources
Last reviewed: 19 October 2026.
