Back to course syllabus
Design answers that can show their evidenceLesson 8 of 11

Document-level access control for enterprise RAG, from search to citation

Carry verified identity, tenant scope, and document ACLs into every chunk, then test denial across retrieval, model context, citations, cache, and revocation.

DECISION TOPICGrounded answers
LESSON OUTPUT · document-access traceUPDATED · Oct 1, 2026
GUIDES READ0 / 11
HOW TO USE THIS LESSON

Read with one real task in mind, then complete the workbench. The lesson is done when another person can review what you made.

An enterprise knowledge assistant cannot enforce document permissions by asking the model to keep secrets. The application credential used to search an index commonly has wider reach than the employee asking the question. Once a restricted passage has reached the model, an answer that happens not to quote it is not evidence that access control worked.

This lesson answers a narrower question than a general retrieval evaluation: for this request, which documents may this caller see, and does that decision survive every route to the final citation? The result is a request-level authorization trace and a set of positive and negative probes. It is useful whether the search backend offers native ACL enforcement or the application builds verified filters.

Start with a trusted principal, not a phrase in the question

Validate the login session or token on the server. Resolve a stable subject, the active tenant, and the groups or roles that the tenant’s authorization system recognizes. Neither “I am the finance lead” in the prompt nor a group name supplied by browser code can enlarge that scope. If the principal is absent, tenant membership is ambiguous, or the authorization service is unavailable, fail the protected search closed. An unfiltered fallback is a permission change, not a graceful recovery.

Write the allow rule in business terms before translating it to a search filter: the document belongs to the active tenant and is public within that tenant or grants access to the verified subject or one of its verified groups. Explicit denials and narrower document exceptions must follow the actual policy. A group called Finance in tenant A must not match an unrelated Finance group in tenant B. This is a policy sketch, not ready-made syntax for a particular engine.

Azure AI Search describes a string-based security-filter pattern. Its documentation explicitly says that matching a principal string does not itself authenticate or authorize the principal; the application must supply trustworthy identity and a filter on each query. Azure also documents native document-level options based on source permission metadata, with preview scope that varies by source and feature. Verify the actual product, API version, and source before relying on a native path.

Keep a decidable grant on every searchable chunk

Give the parent document a stable ID, tenant ID, source revision, ACL revision, and the subject or group identifiers needed for the chosen enforcement path. Every indexed child chunk must retain its parent link and the metadata needed for authorization at query time. Azure’s index-projection guidance recommends repeating parent fields on children in a single index; a two-index design does not get a free query-time join. Sample a document with, say, 12 chunks and verify that all 12 carry the expected tenant and grant.

Inheritance needs an exception rule. A handbook visible to everyone might contain a legal appendix visible only to counsel. Do not give the appendix the handbook’s broad grant merely because both came from one uploaded file. Make the appendix a separate permission unit or override the default with a narrower child grant. Keep a chunk out of searchable content if its effective grant is unknown. Titles, extracted summaries, table cells, and the text returned for a vector hit need the same boundary. Marking an ACL field as non-retrievable does not protect a text field that an unfiltered query returns.

Enforce the decision at search and at every later fetch

The backend should construct the tenant and principal conditions before sending a search request. Cover every enabled route: keyword, vector, hybrid, reranking, and suggestions if they retrieve content. Fetching global top-k and deleting restricted hits in application code risks exposing text to logs or downstream stages and can bury the few permitted hits under global ranking. Record the actual filter, query ID, index revision, and returned chunk IDs for review; production logs need not copy sensitive passages.

Search hits often trigger a parent-section expansion, full-text fetch, attachment preview, or citation link. Recheck the current request’s authority at each materialization step. Access to one chunk does not authorize every sibling attachment. The model receives only permitted material. A citation ID must be checked when it is resolved into source content; the source system must still enforce its own access rule when a user follows the link. For answer or retrieval caches, isolate entries by tenant and effective authorization scope or policy revision, and invalidate affected entries after a permission change. A cache keyed only by question text can replay a privileged answer to a different caller.

Treat revocation as a time-bounded change

The source ACL, searchable copy, session claims, and caches may update on different clocks. Azure’s index-update documentation says updates become queryable after background indexing. An accepted update request is therefore not proof that a subsequent search enforces the new ACL. Set an acceptable revocation window. During propagation, use an authoritative request-time check to block the revoked document or pause its retrieval; then probe each affected chunk to confirm that the old principal no longer gets body text, summary, parent expansion, citation, or cached answer.

Track the source ACL revision, the revision visible in search, cache invalidation time, and the first successful denial probe. A particularly useful probe removes a user from a group without changing any document ACL. For a custom filter, the changed object may be the caller’s group claims or session rather than the index. A still-valid token carrying old groups can delay the tighter decision; the identity and session policy must define that window.

Example one: identical group names across tenants

Consider a synthetic two-customer procurement assistant. Both tenant A and tenant B have a group named Finance. An A employee asks about A’s supplier-payment rules. The shared search index contains similarly worded payment policies for both tenants. The employee may see A’s public rule and an appendix granted to A Finance. B’s policy must be absent from search results, model context, and citations even if its wording gives it the highest global score.

Run an allowed A Finance request, ask the same question under B Finance, then repeat without a tenant claim. Save the verified tenant, group source, actual filter, and returned IDs for each. A global Finance string can admit the wrong customer’s chunk. Telling the model not to mention B leaves the retrieval failure untouched. The fix is to bind group identity to the tenant and resolve it on the server, not to lower a similarity score.

Example two: a revoked reader can still open an old citation

In another synthetic case, procurement staff may read a contract body while a legal appendix is restricted to counsel. A legal employee once received an answer citing that appendix and later leaves the legal group. The next request must neither retrieve the appendix nor reuse the cached answer. The old citation ID must not bypass authorization when used to fetch an excerpt or preview.

First prove an allowed legal session can retrieve the appendix. Revoke membership and note the time. Probe with a fresh session and with a still-valid old one; request the saved citation directly; then inspect all appendix chunks after index synchronization. If the old session still reads, inspect claim refresh. If search denies but the citation opens, fix citation resolution. If citation resolution denies but the cached answer repeats the text, fix cache isolation or invalidation. A final answer that omits the citation does not excuse any of these failures.

Build a denial matrix before release

Choose an ordinary document, a group-restricted document, a narrower appendix, and one revocation event from the real policy. Give each a positive control under an allowed identity. Add negative identities: wrong group in the same tenant, same-named group in another tenant, missing identity, and a recently revoked member. For each request inspect search hits, actual model context, parent or preview fetch, citation resolution, and cache output. Any restricted content at any one of these points blocks release. Separately check that the allowed controls still find useful evidence; a filter that returns nothing to everyone is broken too.

Use the worksheet below for one request per row. Record expected allow or deny, source and indexed ACL revisions, trusted subject and tenant, actual search condition, returned IDs, downstream context, citation fetch, cache result, and revocation timing. Locate the first layer that crossed the boundary, repair it, and rerun the same positive and negative probes with a named reviewer. Once access is correct, the citation and freshness audit can check whether permitted evidence supports the answer. The chunking trial helps detect an appendix that inherited the wrong parent grant.

Boundary

This trace tests whether one RAG data path enforces an existing document ACL; it does not decide the organization’s entitlement policy, and a finite test set cannot prove that no leak is possible. Regional replicas, backups, analytics logs, exports, and offline training copies have separate data-governance paths. Filter semantics and native permission features vary across products, so translate these probes into the real backend’s requests and observable results before claiming coverage.

SOURCES CHECKED

Which first-party sources informed this guide?

Sources anchor definitions, risk boundaries, or operational facts. The decision framework and workbench are original to AI Vista.

  1. Azure AI Search document-level access control overviewChecked 2026-10-01
  2. Azure AI Search security filter patternChecked 2026-10-01
  3. Azure AI Search parent-child index projectionsChecked 2026-10-01
  4. Azure AI Search index updates and rebuildsChecked 2026-10-01

AI tools may assist with research, outlining, and language editing. Facts, cases, and final wording are reviewed by the editor. Report an error through the contact page.

TAKEAWAY TOOL

RAG document-access trace

Trace one verified caller through index, search, context, citation, cache, and revocation.

rag / access / trace
USE THIS WHENBefore releasing enterprise RAG or after an ACL or membership change
YOU WILL GETA request-by-request proof of permitted retrieval and denied access through citations and cache

This workbench saves a draft in this browser. Use sanitized identities and document IDs; do not paste restricted source text, tokens, membership lists, or live private links.

HOW TO USE01—03
  1. 01
    Describe the taskDescribe the result with a sanitized summary.
  2. 02
    Fill the decision fieldsRecord input categories, risk, evidence pointers, and handoff.
  3. 03
    Ask a colleague to reviewThe tool is ready when someone else can restate the decision.
DONE WHENFields are complete, boundaries are clear, and the result is reviewable.
Edits save automatically

LESSON READ

Finish the workbench, then mark it read.

The read state updates the syllabus and your course progress.

  1. 01Fields filled
  2. 02Case tested
  3. 03Reviewable

GUIDE PRACTICE NOTES

Leave a judgment you can review later.

The fictional examples below show the format. Your own notes stay in this browser. Record what worked, which boundary failed, or one question worth testing.

↗
RELATED GUIDEDocument-level access control for enterprise RAG, from search to citationSee examples and local notes →
0 examples and local notesINSIGHTS · QUESTIONS · IDEAS