The response cache.
Keyed on the question alone, a cache returns one user's answer to another. Key by identity, or scope per user.
Filter before
you search.
Retrieval access control only works one way: restrict the candidate set with the asker's identity before relevance scoring. Everything else is too late.
READ THE DEFINITION ↓PRE-FILTER · FRESHNESS · ISOLATION
01 / DEFINITION
The short answer first.What is RAG access control?
RAG access control is the enforcement of document permissions inside a retrieval pipeline, so that only material the requesting user may see can be retrieved. It requires per-chunk access metadata and filtering applied before relevance scoring, not after generation.
This is the single most common architectural gap in enterprise retrieval deployments. Indexing everything is the fast path to a working prototype, and adding permissions afterwards is not a configuration change — it means rebuilding the index with access metadata carried through the pipeline.
02 / PRE-FILTER, POST-FILTER, OR PROMPT
Three options, one of which works.| Approach | Mechanism | Result |
|---|---|---|
| Pre-filter | Restrict candidates by the user's permissions before scoring | Correct. Out-of-scope material cannot be retrieved at all |
| Post-filter | Retrieve, then drop unauthorised passages before the prompt | Workable but wasteful; correct only if nothing slips into context |
| Filter the answer | Generate, then check whether sources were permitted | Too late. Restricted content has already shaped the response |
| Instruct the model | Tell the model not to use certain documents | Not a control. See AI agent access control |
Pre-filtering has a performance implication worth planning for: a vector index searched with a restrictive filter can return fewer than k results, or degrade in recall, depending on how the filter interacts with the index structure. The mitigations are to over-retrieve before filtering, to use an index that supports efficient filtered search, or to partition by tenant so that filters are coarse and cheap.
Post-filtering is acceptable as a defence in depth and unacceptable as the only mechanism, because any path that places a passage into the prompt before the check has already disclosed it. The failure is silent: the answer looks normal and no access log records anything unusual.
03 / FRESHNESS
The detail that catches careful teams.Yesterday's permissions
are not permissions.
Access rights change continuously: someone joins or leaves a matter, a confidentiality wall goes up, a document is reclassified, an engagement ends. An index whose permission metadata is refreshed on a nightly schedule is enforcing yesterday's rights, and for a boundary that exists to prevent a specific person seeing a specific matter, a day of lag is not acceptable.
Three workable patterns, in increasing order of cost and correctness:
- Cached metadata with short-lived invalidation. Permissions stored on the chunk, with an event-driven update from the source system. Adequate where changes are infrequent and the lag is bounded and known.
- Query-time authorisation. Candidate identifiers are checked against the authoritative system before content is returned. Correct, at the cost of a synchronous dependency.
- Partitioned indexes. Separate indexes per tenant or per confidentiality boundary, so isolation is structural rather than a filter that must be applied correctly every time.
Hard boundaries — conflicts of interest, ethical walls, statutory restrictions — belong in the third pattern where possible. A control that depends on a filter being applied correctly on every query path is weaker than one where the data is not in the same index.
04 / THE OTHER COPIES
Places permission filtering is commonly bypassed.Conversation history.
Content retrieved for one user persists in a thread. If the thread is shared or the user's access changes, so does the exposure.
Evaluation sets and logs.
Both accumulate real retrieved content in stores with their own access models, usually broader than the source.
Testing is what turns this from an intention into a control. A standing suite that queries as several test identities for content each should not reach, run on every re-index rather than once at launch, is the only reliable way to know the boundary still holds — permission metadata is the first thing an indexing rewrite loses, and nothing visibly breaks when it does. Privilege AI treats permissions and retrieval boundaries as the same design problem: which information a model can access, and which actions it can propose. See AI access control.
05 / QUESTIONS
Asked when retrieval meets real permissions.Can a vector database enforce document permissions?
+
Most support metadata filtering, which is the mechanism, but the enforcement is your application's responsibility: the filter has to be applied on every query path with the correct identity. Nothing in the database prevents a code path that forgets.
How do you handle permissions that change frequently?
+
Query-time authorisation against the authoritative source, or event-driven invalidation with a bounded and documented lag. For hard boundaries such as confidentiality walls, partitioning the index is stronger than any filter.
Is a separate index per tenant necessary?
+
It is the strongest isolation and the most operational overhead. For strict multi-tenant requirements, or ethical walls within one organisation, it is usually worth it; for internal departmental separation, filtered search with tested enforcement is generally adequate.
What about permissions on chunks rather than documents?
+
Permissions are almost always a document-level property, so every chunk inherits its parent's metadata. Where part of a document is more restricted than the rest, the safe approach is to split it into separate documents rather than to model chunk-level exceptions.
How do you test retrieval access control?
+
With a standing suite of adversarial queries run as several test identities, checking that content each identity should not reach is never returned. Run it on every re-index, because that is when permission metadata is most often lost.
Permission the index,
not the answer.
Privilege AI builds retrieval boundaries that define what a model can access, enforced before the search rather than after the answer.