Moving access control to the point where AI context is chosen
An enterprise RAG system makes an access decision when it selects information for a user. If policy is applied only after an answer has been generated, sensitive content may already have entered the model context, logs, traces or caches.
Policy needs to move earlier in the flow. The strongest design translates the user's access rights into constraints that the retrieval system applies while selecting candidates. This is pre-retrieval policy enforcement.
Three enforcement points that should not be confused
The term policy-aware RAG can describe very different controls.
Output filtering
The system retrieves content, sends it to the language model and inspects the generated answer. This can remove visible text or sensitive info or PII from the response. It cannot undo the model's exposure to the source content or reliably determine every way that content influenced the answer.
Policy filtering before model context
The system retrieves candidate chunks or data, evaluates them against policy and excludes denied chunks or information before building model context. The language model receives only the authorised subset.
This protects the model boundary and illustrates the value of enforcing policy before context assembly in governed retrieval for RAG and agent systems.
Pre-retrieval enforcement
The system resolves identity and policy first, compiles an enforceable constraint and binds that constraint inside the search operation. Denied information is outside the candidate set used for ranking.
This is the most precise use of the term pre-retrieval.
Why post-retrieval filtering is an incomplete design
Filtering retrieved candidates before model context is materially safer than filtering the generated answer. It still has limitations when the search itself is unconstrained.
Assume a vector search returns the 20 most similar chunks and a user may access only three of them. A post-retrieval policy check removes the other 17. The system now has three candidates, even if many highly relevant authorised chunks existed below the original top 20.
This creates four operating problems.
Retrieval quality can depend on denied content
Unauthorised chunks consume positions in the candidate set. The final answer can become incomplete because authorised content was never retrieved for evaluation.
Restricted information enters more system surfaces
Candidate content may appear in retrieval traces, diagnostic logs, intermediate caches or application telemetry. Every additional surface needs its own protection.
The retrieval score is calculated across the wrong population
Ranking occurs before the system knows which information the user may receive. The resulting order reflects relevance across the entire index rather than relevance within the user's authorised information.
Deny behaviour becomes harder to reason about
A control placed after retrieval has to inspect and remove results correctly on every path. Search, chat, citations, previews and new application endpoints can drift into different enforcement behaviour.
The pre-retrieval sequence
A strong enforcement flow has a clear order:
- Authenticate the caller and resolve the user or workload identity.
- Collect relevant role, group and approved policy inputs.
- Resolve the requested action and governed resource scope.
- Evaluate policy and produce an allow constraint or a deny decision.
- Compile the constraint into the retrieval system's native filter language.
- Bind the filter inside vector, keyword or hybrid search.
- Rank only the authorised candidates.
- Build model context from the authorised result set.
- Record the identity, policy version, decision and retrieved resources for audit.
The retrieval service should reject the request when identity, policy state or constraint compilation cannot be established.
Policy inputs must match the claim being made
An enforcement engine can use only the inputs it actually receives and supports. Role-based policy can determine access from the user's approved role. Sensitivity and semantic classifications can describe the governed content. More advanced claims involving purpose, agent identity, device posture or dynamic risk require those inputs to be defined, supplied and enforced throughout the request.
A platform may allow administrators to define access using user roles and label content with sensitivity or user defined semantic classifications.
Filtering granularity determines the protection
File level filtering is useful when every passage in a file has the same access rule. Enterprise content often has finer boundaries.
Granular metadata allows a governed RAG flow to decide whether a particular retrieved passage may enter model context. Runtime policy controls ensure that only authorised retrieved data is supplied to the language model.
This control is described as policy before model context. The broader architecture described in this article moves the same decision into candidate selection so retrieval and ranking operate only over authorised information.
Protection needs evidence
An allow or deny response is insufficient for operational accountability. The audit record should connect:
- the resolved identity;
- the requested action;
- the policy and version used;
- the resource or filter scope;
- the decision and reason;
- the retrieval operation; and
- the information supplied to model context.
This record supports investigation, policy review and change analysis. It does not by itself establish regulatory compliance. Compliance depends on the complete organisational and technical control environment.
The design rule
Policy should be enforced at the earliest point where the system has enough information to make the correct decision. For RAG, that means resolving identity and access before information is selected for the request. When a platform currently filters candidates before model context, it should state that boundary precisely and avoid calling every such flow pre-retrieval. It also gives security, data and AI teams a common basis for testing what the system actually prevents.