Home › AI › RAG document access control
RAG document access control decides which source material a retrieval-augmented AI system may use for a particular person. The application needs an authenticated identity, enforceable retrieval permissions and a way to keep those permissions current before documents become context for an answer.
Permission belongs in retrieval
A question-answering system can search a shared collection of documents, choose relevant passages and pass them to a model. The access decision needs to happen while selecting that material. A prompt asking the model to respect confidentiality does not provide the identity checks that a retrieval service requires.
Microsoft’s Azure AI Search documentation describes several document-level approaches. A generally available security-filter pattern compares identity strings in a query with identity metadata in the index. Native token-based approaches use Microsoft Entra claims and indexed permission metadata, with the relevant capabilities marked preview. These approaches have different enforcement and synchronization requirements. Microsoft’s access-control overview
For a product team, start by writing the access question in ordinary language: may this authenticated person read this document now? Similarity to the question is a separate condition. A highly relevant passage can still be outside that person’s permissions.
A group string is not authentication
Azure’s security-filter pattern uses ordinary filter expressions. Microsoft explicitly states that the principal identifier is a string used for inclusion or exclusion; that field does not itself authenticate or authorize the caller. The application must supply the correct identity context and apply the filter consistently. Security trimming documentation
That distinction changes the trust boundary. Letting a browser choose a group identifier would make the supplied identifier part of the user’s request, not reliable evidence of membership. Resolve the caller through the application’s trusted identity path, then construct the retrieval request on the server.
The journal’s object-level authorization guide covers the underlying access-check principle. RAG adds a further consequence: content returned by a search can be copied into a generated answer, so restricting a document link after generation is too late for the text already used.
Carry permissions with every usable passage
A source document often becomes several indexed passages. The retrieval system needs permission information at the granularity where it can return content. Microsoft’s overview notes that chunked indexes require permission fields to be projected to the chunk rows under the documented ingestion approach. Access-control and chunking guidance
A practical design review should follow one restricted document through extraction, chunking, indexing, retrieval and answer assembly. Check the permission metadata at each transition. Test whether an empty or missing permission field causes the system to withhold material or accidentally treat it as public.
Include alternate retrieval surfaces in that review. A system might have a primary search route, a direct document fetch and a cached answer route. Each path needs an explicit access decision; the presence of a filter in one search request does not establish the behavior of the others.
Revocation has a synchronization delay
A permission-aware index can still contain yesterday’s access metadata. Microsoft’s documentation says that query-time checks evaluate permissions already stored in the index; source changes affect results after the relevant synchronization mechanism updates that metadata.
Its SharePoint indexer guidance gives a concrete preview limitation: changes inherited from parent scopes are not automatically picked up by later indexer runs and require the documented refresh procedure. It also describes supported and unsupported permission relationships, so a product should not assume the complete SharePoint access model is reproduced by every ingestion setup. SharePoint permission ingestion
The operational question is how long a removed permission can remain usable in each copy. Define that interval, monitor the synchronization process and decide how the application behaves when permission freshness cannot be established. A search index’s availability should not silently substitute for evidence that its permissions are current.
Keep answer evidence within the same boundary
The proposed review should include citations, conversation history and reusable answer caches. If a user loses document access, determine whether a stored answer can still expose a passage from it. A cache key that only contains the question may be too broad for a system serving users with different permissions.
Those are design checks, not claims that a particular cloud product automatically implements or fails them. The RAG provenance explainer covers how an answer remains connected to its sources. Provenance and authorization answer different questions: where did the statement come from, and was the recipient entitled to receive that source material?
Reporting & Sources
Documentation checked November 1, 2026. Microsoft’s access overview was updated September 17, 2026, and its security-filter article August 24, 2026. Preview capabilities and source-specific limitations are stated as such. The review scenarios above are editorial analysis, not reported testing.
