RAG leaks docs to the wrong users when retrieval returns out-of-scope candidates before permissions are applied. Fix it by enforcing tenant, library, visibility, and user scope in the candidate query itself, then enriching and answering only from allowed source artifacts.
Last updated: June 20, 2026.
Why is post-answer filtering too late?
If a restricted source enters the model prompt, the leak already occurred. The final answer might be filtered, but the model still had access to text the user should not see. Permissions must shape the candidate set before context assembly.
The NIST AI Risk Management Framework is a useful governance reference: trusted systems need controls that reduce risk before harm occurs. The retrieval layer is one of those controls.
Where does oversharing happen?
Oversharing can happen at several points:
| Failure point | Example bug |
|---|---|
| Vector search | Search runs across all tenants before filtering |
| Library scope | A project library is ignored during retrieval |
| Visibility | Private content is enriched for a non-owner |
| Shares | Share joins omit tenant boundary |
| Logs | Out-of-scope snippets are stored in traces |
| Prompt assembly | Candidate list includes restricted documents |
Answer Engine’s tenant-isolation implementation pattern, described in Permission-aware retrieval, binds tenant_id and library scope before content enrichment and answers. That is the pattern to demand from any memory or RAG system.
How do you inspect an ACL leak?
Trace the request:
- Who is the authenticated actor?
- Which tenant and library scope were selected?
- Which visibility rules apply?
- Which content ids were eligible before vector search?
- Which ids returned from search?
- Which ids were enriched?
- Which snippets entered the prompt?
- Which citations appeared in the answer?
If you cannot see this trace, you cannot prove the leak is fixed.
How do you fix it?
Apply permissions before retrieval. For full-text search, put scope in the SQL WHERE clause before ranking. For vector search, pass filters into the vector function or prefilter allowed ids and post-filter only inside that allowed candidate pool. For joins, match tenant ids across content, tags, shares, and library membership.
Then add negative tests. A user from Tenant A should not retrieve Tenant B’s unique phrase. A user without private access should not retrieve a private source by exact title. A library-scoped query should not return content outside the library.
How does deletion relate?
Deleted or disabled sources are also permission failures if they still retrieve. The GDPR right to erasure is one external reason deletion matters, but the product reason is simpler: unavailable sources should not enter candidate memory.
What should a negative test look like?
Use unique phrases that exist in one restricted source and nowhere else. Then test from an actor that should not have access:
| Test | Expected result |
|---|---|
| Tenant B asks for Tenant A’s unique phrase | No active source returned |
| Non-owner asks for private document title | No snippet, citation, or summary returned |
| Library-scoped query asks for out-of-library source | Candidate excluded before ranking |
| Deleted document exact phrase search | Deleted source unavailable |
These tests should inspect retrieval candidates, not only the final answer. A final answer can be empty while restricted snippets still reached the model.
What should you log?
Log the authorization boundary without leaking restricted content: tenant id, library id, actor id, allowed candidate count, rejected candidate count, source ids that entered the prompt, and citation ids returned. Do not log full restricted snippets into a broadly visible debug stream.
For high-risk workflows, keep a trace that an auditor can replay with the same actor and scope. That is how you prove that a leak fix works rather than merely changing the wording of the answer.
What should you read next?
Read Permission-aware retrieval, RAG returns wrong results, and the Memory Failure-Mode Catalog. Use the Memory Leaderboard to compare permission controls across systems.