Permission-aware RAG: access before retrieval

The model is not the access-control layer

If a caller cannot read a document, the application should not pass its content to the generator and hope a prompt suppresses it. The access boundary belongs in the retrieval and application path. That includes snippets, document titles, metadata and citations when those reveal restricted information.

Authorization needs resource-level checks using trusted identity. The model may formulate a search query, but it should not define the authenticated user, group membership or tenant. Those values come from the application and its authoritative policy.[1]

A permission snapshot has an age

An index can enforce the permissions it knows while still holding an outdated view of the source. Microsoft’s Azure AI Search documentation explicitly describes source-specific synchronization behavior for native document-level access controls; some functionality is preview, and certain inherited permission changes require explicit refresh. These are product-specific details, not universal guarantees of immediate revocation.[2]

Define the freshness requirement for the data class. Options include current-source authorization at read time, a policy service that receives changes reliably, versioned access metadata with fail-closed behavior, or a documented exposure window where that is acceptable to the product owner. The design should not silently assume synchronization is instantaneous.

Deletion and revocation are different events but both affect reuse. Removing a document from an index does not remove its text from a previously generated answer, a conversation history or an observability system. List those derived stores and define their retention and access behavior.

Worked scenario: an answer survives a revoked source

A synthetic internal assistant answers a question using document D7 and caches the response. The cache records the source ID and version but is keyed only by the question. Later, D7 is restricted to another group. A different caller asks the same question.

Returning the cached answer immediately would bypass the updated source policy. The application should revalidate the answer’s evidence dependencies for the current caller, or invalidate the cached entry through a reliable permission-change mechanism. If access cannot be established, rebuild from permitted evidence or return an unavailable answer.

A user-specific cache key alone is not enough: the same user can lose access. A tenant-specific key alone is not enough when documents have different permissions inside the tenant.

Filter before selection, then validate the selected evidence

Where the search system supports it, apply tenant and access constraints while constructing the candidate set. This avoids giving restricted candidates to downstream ranking or generation components. If the architecture retrieves candidate identifiers first, it must still authorize before fetching or exposing content, including to a model-based reranker.

Filtering only after a small top-k retrieval can also damage quality: restricted items may occupy the candidate slots, leaving too little permitted evidence. Evaluate the retrieval behavior under realistic permissions, not only as an administrator who can see every document.

• Use trusted principal and group information in server-generated constraints.
• Validate source ownership and current access before assembling model context.
• Keep citation resolution behind the same access rules as the source.
• Treat summaries and derived chunks as dependent on their source permissions.
• Fail closed when a required access decision cannot be established, according to the product’s defined policy.

Make revocation a test, not a diagram annotation

Where it fits in the security design

Permission-aware retrieval is necessary for many enterprise systems, but it is not the complete security design. The product also needs appropriate handling of prompts, tools, external destinations, telemetry and model-provider data policy. A correctly filtered document can still contain hostile instructions.

A credible review states the authority source, enforcement points, synchronization behavior and tested failure cases. It does not declare an entire RAG product secure because a vector query contains a tenant filter.