RAG permissions: decide what each employee can retrieve

Start with a concrete access map

List the source systems and the groups allowed to read them. Distinguish broadly shared guidance from team records and restricted documents. Use the permissions already established by the organization rather than inventing a parallel set just for the assistant.

For an illustrative pilot, a support team might access product guidance while only designated managers can retrieve a separate planning collection. Write down both allowed and denied examples before ingestion. That gives the implementation a reviewable target.

Enforce the boundary during retrieval

The retrieval service must identify which records the current user is allowed to access before supplying context for generation. Microsoft documents document-level access-control approaches in Azure AI Search, with different supported mechanisms depending on the data source and configuration.

Review the capabilities of the selected stack instead of assuming one feature covers every connector. The design must define how identity and permission metadata reach the query, and what happens if either is unavailable. An instruction in a prompt is not an access-control mechanism.

Reference: Microsoft Learn: Document-level access control in Azure AI Search

Preserve permissions when documents are split

A source document may become many searchable chunks. Those chunks need enough identity and permission information to preserve the source boundary. A passage must not become broadly accessible merely because it was indexed separately from its original document.

Make permission handling part of the ingestion contract. Check identifiers, deletion behavior and the treatment of moved documents. If an ingestion job cannot establish the required permissions, choose an explicit restricted or failed state rather than silently making the content available.

Test changes after the first successful answer

Initial access is only one scenario. Remove a user from an allowed group, restrict a previously shared document and delete a source. Check whether search results, citations and saved answer views follow the intended policy after each change.

Define how quickly those changes must take effect and which part of the system enforces the requirement. Delayed refreshes and cached content need deliberate treatment. Record observed behavior rather than relying on a connector’s advertised capability alone.

Keep operational visibility proportionate

The team needs enough evidence to investigate an incorrect answer or an access failure. Record relevant identifiers, decisions and system outcomes while limiting unnecessary document content in logs. Restrict diagnostic access as deliberately as access to the source collection.

Separate retrieval failures from answer-quality failures. A user receiving no permitted results is different from a model overlooking an available passage. Distinguishing those cases helps the team repair the right part of the system without broadening access as a shortcut.

Make permission tests a release gate

Use a small matrix of users, groups and documents with known expected outcomes. Include negative cases where a user should learn nothing from a restricted document, including through snippets, citations or a cached response. Review the results before adding more sources.

Repeat those checks when changing connectors, indexing rules or the identity model. A RAG pilot is easier to expand when its access behavior is demonstrable. Broader coverage should follow a working boundary rather than postpone the need to establish one.

Common questions