TL;DR
RAG retrieval permissions must reflect the effective requester, the application’s approved scope, and the restrictions on the requested content. A valid login establishes identity. A working service account establishes that the application can reach a backend. Neither independently establishes which documents this request may use.
Enforce authorization through trusted services before restricted content reaches the generation path. Preserve the same controls through search expansion, caches, conversation history, and source viewing. Measure permission revocation across the complete application, and define what happens when identity resolution or policy freshness cannot be established.
Relevance determines what might answer the question. Authorization determines what the system may use to answer it.
Introduction
Return to the hypothetical support assistant from Part 1.
An engineer supported Customer A last week. This week, the engineer moves to Customer B, and the source repository removes access to Customer A’s incident reports. The engineer remains employed, can still sign in, and can still use the assistant.
The next question asks about Customer A’s recovery history. The application’s service identity can query the shared index, and a previous answer remains in the conversation cache.
Should the assistant return it?
Not merely because the login succeeds, the search service accepts the query, or the answer was permitted yesterday. The application needs a current authorization decision under its defined consistency and freshness rules.
Part 1 established the data boundary: source admission, approved processing, lineage, and lifecycle controls. This article assumes those foundations exist and concentrates on request-time enforcement for an indexed enterprise assistant. The architecture and policy contract below are proposed implementation patterns, not claims that every RAG platform provides these controls automatically.
Separate the User’s Rights from the Application’s Access
An indexing identity, a retrieval-service identity, and an end-user identity serve different purposes. Design their permissions separately rather than allowing the broadest credential to define the assistant’s audience.
For an interactive request, I would evaluate four independent constraints: the requester’s resource permissions, the application’s approved scope, the selected customer or business boundary, and the permitted processing use. Every applicable constraint must be satisfied.
This does not mean that every entry in a source access-control list must match. A source may grant access through either a direct user assignment or an eligible group. The application’s additional boundaries constrain that source decision; they do not replace its semantics.
OWASP’s Authorization Cheat Sheet distinguishes authentication from authorization and recommends permission checks on every request. Applied here, a successful application login is the beginning of the decision, not its conclusion.
Delegation Is Different from App-Only Access
Where a downstream API supports delegated user access, use its documented mechanism. Microsoft’s OAuth 2.0 On-Behalf-Of flow illustrates this pattern: a middle-tier API obtains a downstream token representing the user through delegated scopes. It is not an app-only privilege-expansion mechanism.
A shared backend credential may still be necessary in another design. In that case, the retrieval gateway becomes a security-critical enforcement component. Restrict its scope and prevent ordinary clients or model-selected tools from bypassing it.
For scheduled work without a human requester, use an explicitly authorized workload identity and purpose. Separately authorize whoever will receive the resulting report. Do not impersonate the administrator who originally created the schedule.
Establish Identity Before Interpreting the Question
Build request context in trusted middleware, not from the prompt.
For an API accepting access tokens, use supported validation middleware configured for the intended issuer, audience, and validity requirements. Microsoft’s access-token documentation assigns validation to the receiving resource API and warns against accepting tokens intended for another resource. Decoding a token is not equivalent to validating it.
Keep credentials out of model context. Pass the model the question and approved evidence, not the bearer token used to obtain them.
Customer selection needs its own check. An identity-provider tenant and an application’s customer boundary are not necessarily the same thing. In the support scenario, employees from one corporate directory may support different customers. Resolve the requested customer against verified assignments rather than treating a customer name in the prompt as authority.
Missing Group Information Is Not an Empty Permission Set
Microsoft Entra can emit a group-overage indicator instead of a complete group list. Its Access token claims reference documents the need to retrieve group membership through the supported directory mechanism in that case.
When a decision requires group information, distinguish a resolved empty membership from an unresolved membership. Do not remove the group constraint because resolution failed, and do not assume a partial list is safe where group membership can impose restrictions.
Choose Where Retrieval Permissions Are Enforced
Choose the enforcement pattern according to the source permission model, supported interfaces, required freshness, and operational dependencies.
| Pattern | Where it fits | What the implementation must establish |
|---|---|---|
| Source-enforced delegated retrieval | The source supports search or read operations in the requester’s delegated context | The downstream API evaluates the intended identity and permission model, with understood consistency behavior |
| Native document-level enforcement in search | The search service supports the required identity and source permissions | Permission ingestion, query identity, supported operations, and synchronization meet the application’s requirements |
| Trusted gateway with compiled security filters | The application must integrate custom identities or heterogeneous sources | The policy translation is faithful and every protected query passes through the gateway |
These are design choices, not interchangeable security labels. The most convenient connector is not necessarily the one that preserves the source’s permission semantics.
In particular, do not assume native query-time enforcement means a live source authorization check for every result. Identify which decisions use current directory information, indexed permission metadata, cached decisions, or a combination of them.
Keep Authorization Separate from Model-Generated Search Criteria
Microsoft’s Security filters for trimming results in Azure AI Search makes an important distinction: the principal identifier in the filter is a string used for comparison. The string does not authenticate the principal.
The application must establish which identifiers belong in the request and apply the filter consistently. A filter containing a real group identifier remains unsafe if the caller was allowed to choose that identifier without verification.
Keep the search request in two parts. Trusted code constructs mandatory authorization constraints. The model may propose relevance criteria, such as a product, date range, or document type, through a restricted interface.
Conceptually, the composition should look like this:
Eligible search scope =
verified customer boundary
AND source-policy decision
AND application and processing constraints
AND optional relevance criteria
Model-generated criteria may narrow the eligible scope. They must not replace it, remove a constraint, or introduce an alternative branch that bypasses authorization.
Use typed query construction or a constrained expression builder rather than concatenating untrusted filter text. Apply the same rules when the application rewrites a question, fans out into several searches, or retries with different search terms.
A request to search more broadly is not a request to search with more privilege.
Draw the Boundary Before Reranking and Generation
The diagram below separates request authorization from model processing. The important boundary is where retrieved material leaves the component responsible for enforcing access.
OWASP’s RAG security guidance explicitly rejects relying on the language model to enforce access control. Asking the model to ignore unauthorized passages does not establish that those passages were kept out of its context.
Prefiltering and Postfiltering Need a Precise Interpretation
Azure AI Search documents filtering during vector traversal and filtering after candidate selection. Its guidance describes a recall and performance tradeoff: selective prefiltering can require more computation, while postfiltering can miss eligible matches outside the selected candidate set.
Internal search processing is not the same as releasing unrestricted results to another service. Evaluate the actual enforcement boundary, not only whether a setting contains the word “pre” or “post.”
For this design, unauthorized content must not leave the trusted retrieval boundary for request-specific reranking or generation. If a search service returns candidates to an application-side policy broker, that broker must itself be approved to handle them and must enforce access before further use.
Do not improve recall by dropping the security filter when the first query returns too few results. Adjust retrieval strategy within the authorized scope.
Context Expansion Is Another Read Operation
An eligible chunk may lead the application to load neighboring chunks, a parent document, a linked attachment, or an incident summary. Authorize those additional resources before adding them to context.
Review previews, direct document lookup, downloads, counts, and suggestions as well. Where an interface cannot preserve the required restrictions, exclude it from the ordinary user path rather than treating it as a harmless search convenience.
Preserve the Source Permission Model
A flat list of allowed groups is appropriate only when it faithfully represents the relevant source decision.
Test the source’s actual rules for direct grants, inheritance, nested membership, explicit restrictions, and exceptional sharing. Avoid imposing a universal “deny always wins” or “any group match wins” rule across systems whose permission semantics differ.
As checked on September 10, 2026, Microsoft’s document-level access overview distinguishes generally available security-filter techniques from native ACL/RBAC, SharePoint ACL, and sensitivity-label capabilities documented in preview. It also warns of delays before changed restrictions are recognized.
The query-time enforcement documentation gives concrete reasons to inspect connector details. It distinguishes refresh requirements for different sources and documents an unsupported mixed relationship involving a Microsoft Entra group nested inside a SharePoint group.
Treat unsupported relationships as a design limitation to resolve. Do not silently flatten them into a more permissive approximation. A representative permission test set should be an entry requirement for a new source, alongside the admission contract from Part 1.
Measure Revocation Across the Complete Application
Permission revocation is a distributed-state problem, not simply an index update.
Google’s Zanzibar research addresses authorization consistency across changes to access-control lists and object contents. The relevant lesson for this design is that a policy decision needs a defined relationship to changing state, not merely a timestamp saying the check ran recently.
Define a revocation objective from the authoritative change to verified denial across the application’s controlled disclosure paths. Establish the relevant data classes, allowed freshness bounds, and exception process with security and data owners.
The following diagram shows why measuring only the search path is insufficient:
In a hypothetical test, search might deny access after one minute while a cached answer remains available after five. That does not demonstrate one-minute revocation for the assistant. It demonstrates a remaining disclosure path.
Measure the full path under normal operation and dependency failures. A freshness objective is not permission to ignore an observed unauthorized disclosure.
A New Cache Entry Can Contain Old Policy
Distinguish the time a decision was cached from the freshness of the information used to make it. Repeatedly checking an unchanged local copy does not establish that the authoritative source has not changed.
Carry the underlying policy revision, observation state, and validity conditions through caching. Where the source cannot provide a usable revision or bounded freshness signal, document that limitation and select a different enforcement or availability policy.
Revalidation Narrows a Race; It Does Not Create Atomicity
For sensitive responses, revalidate the evidence set before release. If access changed after context assembly, withhold the generated answer and rebuild from currently authorized evidence and history. Removing a citation does not remove the information the model already incorporated.
A final check still does not make separate policy and delivery systems atomic. Define the decision snapshot, maximum request duration, cancellation behavior, and residual race explicitly. Buffering protected responses until release checks complete reduces streaming exposure, at the cost of delayed first output.
Treat Cache Hits and Conversation Reuse as New Access Decisions
OWASP’s Multi-Tenant Application Security Cheat Sheet recommends scoping protected cache entries by the attributes that affect them and explicitly states that cache-key separation does not replace authorization.
For the support assistant, maintain a protected dependency manifest connecting a cached answer to its source versions and policy dependencies. Authorize access before reading the protected answer payload, and validate those dependencies before reuse.
A user identifier in the cache key does not solve revocation for that same user. A customer identifier does not solve different document permissions among employees supporting that customer.
For answers derived from several restricted sources, require access to all applicable dependencies unless an independently approved transformation created a differently governed artifact. If lineage is incomplete, treat the entry as unusable rather than asking the model whether it seems safe.
Conversation reuse needs equivalent controls. Reassess retained assistant messages, retrieved excerpts, and generated conversation summaries before reintroducing them into context. When access has changed, exclude or regenerate affected state according to the platform’s policy.
Revocation cannot make a recipient forget information already read or erase copies outside the platform’s control. It can govern subsequent platform-controlled disclosures, including opening saved conversations and viewing their sources.
Define a Retrieval Authorization Contract
The following YAML extends Part 1’s source admission contract into the request path. It describes controls for a custom gateway; it is not configuration accepted directly by Azure AI Search or another managed RAG service.
This example deliberately denies protected operations when a required authorization dependency or freshness decision is unavailable. A different availability policy needs explicit approval and bounded validity rules, not an undocumented fallback.
schema_version: "1.0"
policy_id: support-rag-retrieval-v1
request_context:
subject_source: verified_api_identity
customer_scope: verified_assignment
application_scope: support-assistance
unresolved_required_identity: deny
authorization:
source_policy_adapter: support-corpus-policy-v1
freshness_profile: restricted-support-data-v1
unresolved_permissions: deny
unprovable_freshness: deny
dependency_failure: deny
retrieval:
mandatory_constraints_owner: trusted_gateway
model_criteria: narrowing_only
unconstrained_fallback: deny
context_expansion: authorize_each_resource
before_external_processing: authorize_evidence_set
answer_cache:
scope: [customer_id, subject_id, approved_use]
before_payload_read: authorize
before_reuse: reauthorize_all_dependencies
unresolved_lineage: cache_miss
conversation:
before_context_reuse: reauthorize_dependencies
before_history_delivery: authorize
response_release:
mode: buffered
before_delivery: revalidate_evidence_set
denied_dependency: discard_and_rebuild_authorized_context
audit:
record: [request_id, decision_id, policy_revisions,
resource_versions, outcome, reason_code]
credentials: exclude
Replace the adapter and freshness-profile names with implemented, versioned components. The scope list defines required isolation dimensions, not a complete cache key; request identity, source versions, and other result-changing attributes still need appropriate handling.
Validate the contract against a strict schema and reject unsupported settings. Each declared control needs an enforcing component and a test. A policy file that the application merely stores is documentation, not enforcement.
Successful operation produces authorized evidence and a traceable decision. An unresolved policy returns a controlled failure without silently querying a broader corpus. A revoked cached dependency prevents reuse, even when the cache lookup itself succeeds.
Fail Closed Without Hiding the Operational Cause
An authorized search with no matches, an explicit denial, and an unavailable authorization service are different outcomes. Preserve that distinction in telemetry and support diagnostics without disclosing restricted document names or existence to the requester.
Microsoft’s current query-time ACL/RBAC documentation states that an ACL-evaluation failure returns a server error rather than a partially filtered result set. Application behavior should preserve that boundary instead of retrying through an unprotected route.
Use the following troubleshooting model for the proposed gateway:
| Symptom | Investigate | Safe response |
|---|---|---|
| An authorized user receives too few results | Identity mapping, permission translation, synchronization, and filter selectivity | Repair or tune the authorized path; do not remove its constraints |
| A user retains access after reassignment | Policy dependencies, group resolution, answer caches, and retained conversation state | Block affected disclosure paths and verify the revocation boundary |
| Authorization dependencies are unavailable | Directory resolution, policy service, connectivity, and freshness state | Deny affected protected operations; use only separately authorized fallback services |
| Direct document access works after search denies it | Document resolver and alternate interface enforcement | Close the bypass and repeat object-access tests |
A read-only assistant is not automatically a safe fallback during a disclosure incident. For this design, a permitted fallback might serve an independently approved general-knowledge corpus or route work to an authorized human process. It must not reuse the protected evidence whose authorization is unresolved.
Prove Enforcement with a Permission-Change Drill
Start with synthetic customer-restricted documents and representative identities. Establish a successful authorized baseline, then change permissions without restarting the assistant or clearing every cache manually.
Repeat the original question through vector search, keyword or hybrid search, cached answers, resumed conversations, context expansion, and source viewing. Exercise an identity with unresolved required group information and an unavailable policy dependency. Test the direct interfaces exposed by the deployed application, not only its chat screen.
Inspect the evidence leaving the enforcement boundary as well as the final answer. A model refusal is not a passing result when restricted content already entered an unauthorized processing path.
Record the authoritative change time, observed enforcement times, policy and resource versions, request outcomes, and unresolved coverage. These are acceptance tests to execute, not results claimed by this article. A finite passing suite supports a bounded release decision, not a universal guarantee.
Assign identity resolution to the identity team, source-policy translation to the data and integration owners, and retrieval, cache, and history enforcement to the application and platform teams. One service owner should remain accountable for the complete revocation objective.
When a deployment is rolled back, retain current revocations and serving restrictions. A previous application build must satisfy today’s permission state before receiving production traffic.
Conclusion
Enterprise RAG retrieval permissions are not established by a working service account, a populated ACL field, or a successful login. They are established by a trusted request path that evaluates the correct principal, preserves source semantics, and enforces its decision wherever protected information is used or disclosed.
The practical next step is to run one permission-change drill against the complete assistant. Remove access from a test identity and establish what happens to search results, cached answers, conversation history, and source access without relying on a restart to clean up the state.
That exercise will reveal whether authorization is a property of the application or merely a feature of its primary search query.
The service account may carry the request. It must not become a substitute for the requester’s authority.
Part 3, A Citation Is Not Proof: Building an Evidence and Disclosure Control Layer, examines whether the authorized evidence actually supports the answer and how citations remain controlled when they are displayed and opened.
External References
- Microsoft: Access tokens in the Microsoft identity platform
Canonical URL: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens - Microsoft: Access token claims reference
Canonical URL: https://learn.microsoft.com/en-us/entra/identity-platform/access-token-claims-reference - Microsoft: Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow
Canonical URL: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-on-behalf-of-flow - Microsoft: Security filters for trimming results in Azure AI Search
Canonical URL: https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search - Microsoft: Document-level access control in Azure AI Search
Canonical URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview - Microsoft: Query-time ACL and RBAC enforcement in Azure AI Search (preview)
Canonical URL: https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement - Microsoft: Add a filter to a vector query in Azure AI Search
Canonical URL: https://learn.microsoft.com/en-us/azure/search/vector-search-filters - OWASP: Authorization Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html - OWASP: Retrieval-Augmented Generation (RAG) Security Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html - OWASP: Multi-Tenant Application Security Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html - Google Research: Zanzibar: Google’s Consistent, Global Authorization System
Canonical URL: https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/
TL;DR Enterprise RAG security begins before the first question reaches the model. Decide which sources may enter the platform, which processing services...