RAG Access Control: Which Documents Should Your AI Assistant Retrieve?

RAG access control should restrict retrieved documents to content the current user is authorized to read, before that content reaches the language model. Your application should establish identity, enforce document permissions and stop restricted retrieval when it cannot verify access. A prompt asking the assistant to keep information confidential cannot replace these checks.

This matters when one assistant serves people with different access: account teams, delivery staff, external partners or separate customer organizations. A shared knowledge index can be useful, but a successful search match does not establish permission to read it.

1. Define the permission boundary before choosing retrieval tools

Start with a concrete question: if someone cannot open a document in its source system, should the assistant be allowed to summarize it? For an assistant intended to preserve source permissions, the answer is no.

Authentication establishes who someone is. Authorization determines which resources they may access. OWASP's authorization guidance makes this distinction and recommends denying access by default and validating permissions on every request.

Write a small permission map before implementation. For each document collection, identify its owner, permitted audience and source of permission decisions. Include external collaborators and users who belong to multiple teams. Decide explicitly whether a document is public to all assistant users; missing permission metadata should not silently mean public.

Consider a hypothetical delivery assistant containing general operating instructions and customer-specific project notes. Everyone may read the instructions, while only assigned staff may read each project's notes. Record that rule in a form the application can enforce. Department names in a prompt are insufficient.

This article focuses on enforcing that boundary. The broader retrieval design is covered in the SBS guide to building RAG systems over enterprise knowledge bases.

2. Choose an enforcement approach your team can maintain

A product's search-service permissions and its document-level permissions answer different questions. Permission for an application to query an index does not establish that every user may read every document inside it.

Microsoft's document-level access overview distinguishes application-supplied security filters from native identity-based permission features. Its documented native ACL/RBAC, sensitivity-label and SharePoint ACL approaches are marked as preview. Check the current status, supported sources and API requirements before selecting one for production.

Use the following as review criteria, rather than a universal product ranking:

Separation can make boundaries easier to inspect, but it adds provisioning and maintenance work. Filters can support finer sharing rules, but the application must construct them correctly. Choose the approach your team can operate and test, including when permissions change.

3. Carry document permissions into every retrieved chunk

RAG systems often split documents into smaller passages. Each passage needs a dependable connection to its source and its access rules. A protected original file does not help if an independently searchable passage has lost that relationship.

For an application-managed design, keep a stable source identifier, tenant or workspace scope, and permitted principals with each searchable unit. A principal is a user or group to which access can be granted. Treat this as operational metadata with an owner and an update process.

Microsoft's security filter documentation describes matching user or group identifiers against indexed permission metadata. It also warns that hiding a permission field from returned results is not a security mechanism: the application must apply the security filter to every query.

Build those constraints on the server. A browser-supplied project identifier can describe what the user wants to search, but the server must check whether that scope is permitted. The model should not choose the user's identity, expand group membership or remove a tenant restriction.

Cover direct document lookups as well as ordinary search. Otherwise, filtered search results may coexist with an unrestricted endpoint that retrieves the same passage by identifier. Include follow-up searches and citation previews in the same review.

4. Plan for access removal, caches and conversation history

For your implementation, define what happens when someone leaves a project or a document becomes restricted. Ask the connector owner how permission changes reach the index, how failures surface and what the assistant does during uncertainty.

Document a measurable operating requirement for that propagation. Select it according to the material and business use, rather than assuming a universal acceptable delay. If the design cannot meet the requirement, exclude that collection or add another authorization check before using its content.

Review answer caching separately. Two people asking the same question may have different permitted evidence. A cache indexed only by question text can cross that boundary. Either avoid shared answer caching for restricted material or design cache reuse around verified access scope, permission changes and the underlying sources.

Conversation history needs a policy too. Removing a document from future search does not remove excerpts already stored in an earlier exchange. Decide whether later turns may reuse those excerpts, whether reopened conversations require checks, and how access changes affect stored summaries. The system cannot make someone forget information they already saw, but it can restrict further disclosure.

A useful engineering deliverable is a permission-change walkthrough: source update, index update, cache handling, conversation handling and evidence that the new restriction took effect.

5. Test denial paths and recognize common mistakes

Test what unauthorized users cannot retrieve, alongside whether authorized users receive useful answers. Use controlled fixtures with distinctive, harmless content so reviewers can trace exactly which document supplied a response.

Build paired tests: the same question, the same document collection, different users. Inspect retrieved passages and model context as well as the displayed answer. A refusal in the final answer does not prove that restricted content stayed outside the model request.

Common mistakes include applying permissions only to the first search, trusting a user-editable group list, treating empty metadata as unrestricted access, and allowing citations to expose protected document titles. Another is sharing an administrator's conversation with ordinary users without reviewing the evidence it contains.

Keep access testing separate from prompt injection testing. Permission checks decide which material may enter the workflow; injection defenses address instructions embedded in material the workflow encounters. The SBS article on keeping documents from authorizing AI actions explains that adjacent problem.

Vector retrieval also needs an applicability check. Microsoft's vector filter documentation explains that filter placement affects retrieval behavior and that postfiltering can produce false negatives. Test authorized answer coverage under the selected configuration. Increasing result counts does not excuse removing access constraints.

6. Use a release checklist with a named owner

Before widening access, review one complete journey from sign-in through retrieval to citations and stored history:

• Confirm that the server establishes user identity and permitted tenant or workspace scope.
• Verify that every searchable chunk has valid source and permission metadata.
• Test that missing identity, failed permission lookup and incomplete metadata stop restricted retrieval.
• Exercise search, direct lookup, follow-up questions, previews and downloads with unauthorized users.
• Remove a test user's access and inspect indexing, cached answers and reopened conversations.
• Check that citations and diagnostic logs do not reveal restricted titles or passages to unintended audiences.
• Confirm that authorized users still retrieve the evidence needed for representative tasks.
• Assign responsibility for connector failures, permission synchronization and regression tests.

These checks are proposed release criteria, not a claim that any particular platform passes them automatically. Keep the results with the workflow's release evidence and repeat affected tests when connectors, identity rules or retrieval paths change.

The next step is to select one bounded collection with a clear owner and known permissions. Create paired access tests, demonstrate an access removal, and document unresolved limitations before adding more content. That gives the business a concrete basis for deciding where the assistant is ready to help.