Permission-aware RAG: enforce document access before text reaches the model

Follow authorization from identity and document chunks through retrieval, caches and citations, with practical role-isolation and access-revocation tests.

Author
Aivan Editorial Team
Published
25 October 2026
Reading time
6 minutes
Sections in this guide
  1. Put the boundary before model context
  2. Take identity from the trusted application
  3. Carry permissions into every retrieved chunk
  4. Apply authorization on the real retrieval path
  5. Test revocation, not only initial access
  6. Include caches, summaries and traces
  7. Titles and links can disclose information too
  8. Deliver an authorization test matrix
  9. Frequently asked questions
  10. Sources and research

Put the boundary before model context

A salesperson may read a product brochure but not a confidential pricing meeting record. Sending both to a model and asking it not to disclose secrets places the boundary too late. In the proposed architecture, evidence passes authorization before entering context. Redacting the answer cannot undo the model's exposure to restricted input.

Microsoft documents security filters and native document-permission approaches, identifying some native capabilities as preview. The vendor-independent principle is to make trusted identity and permission metadata affect retrieval. Preview status is not evidence that every connector is production-ready.

Take identity from the trusted application

A question claiming 'I am the CEO' is not evidence of that role. Obtain identity and group membership from the organization's authentication path and calculate the scope server-side. Browser-supplied group or department parameters also require verification.

The illustrative search tool receives an application-calculated scope that the model cannot widen by rewriting its question. Give each request a trace identifier. Make delegated identity explicit: a broadly privileged service account must not silently lend all its authority to every end user.

Carry permissions into every retrieved chunk

A document may become dozens of retrieval records. If permission metadata stays only on the parent row, a chunk-search path can miss the intended restriction. Retain source identity and the metadata needed to enforce policy with each chunk, including extracted tables or images.

Index a synthetic group-restricted policy and ask for the same clause through lexical, vector and reranked paths. None should manufacture an unrestricted copy. Report incomplete permission metadata at ingestion; absence of known permissions must not silently mean public access.

Apply authorization on the real retrieval path

Microsoft's security-filter pattern matches identity or group values against index fields. It does not authenticate users by itself; the application still owns scope construction and consistent enforcement. Verify that the selected API and engine support the intended filter/retrieval combination.

Test a normal authorized query and an attempt to omit its scope. Missing trusted user context should have an explicit safe outcome, usually a stop or no-data response rather than an unrestricted search. Repeat through direct tools, rewritten queries and multi-step agents.

Test revocation, not only initial access

An index-time membership snapshot can become stale after someone leaves a group. Define synchronization delay, behavior during that delay and an immediate containment route for sensitive cases. The policy owner, not the language model, decides the acceptable window.

Confirm access, revoke it and repeat the question in both the existing and a new session. Check the source link too. Do not claim to retract information already delivered to a user's screen; define the controllable boundary around later requests and server-side retained copies.

Include caches, summaries and traces

A shared answer cache could return a manager's evidence to someone else even when the original query was correctly filtered. Query text alone is therefore not a sufficient reuse decision. Consider authorization scope, policy version and data validity; some sensitive answers may be better left uncached.

Map conversation summaries, tool outputs, traces and errors as additional stores. Operational logging does not automatically justify copying full confidential passages everywhere. Run identical questions under different roles sequentially to reveal cross-user reuse.

Titles and links can disclose information too

A hidden paragraph may still leak through a sensitive filename, title, count or preview. Include result metadata and download routes in policy design. An accurate citation is useful only when its reader is permitted to inspect the evidence.

Connect citations to a visible source version and enforce authorization again at the source route. A reusable permanent download token is not a substitute for user access checks. If the source later disappears or becomes restricted, show that state rather than presenting an inaccessible link as conclusive evidence.

Deliver an authorization test matrix

Define public, group-restricted and forbidden synthetic documents for three test roles. Test direct questions, sensitive titles, similar questions and multi-step retrieval. Success requires authorized evidence and absence of forbidden evidence, not merely a model that avoids mentioning a title.

Deliver data paths, policy ownership, synchronization targets, identity-service failure behavior and revocation results. These are architectural acceptance criteria, not certification that every named product already implements them. Enforced policy needs observable evidence rather than a reassuring prompt.

Frequently asked questions

Can we send every document and filter only the answer?

That is not an appropriate access boundary for material the user is not permitted to read. Authorize evidence before context and inspect output as another layer.

What if a chunk has missing permission metadata?

Specify the safe behavior. Missing metadata must not silently create public access; exclude affected sensitive content until resolved.

Is an ingestion-time ACL snapshot sufficient?

No. Membership changes, revocation, caches and source links also require update policies and tests.

Sources and research

Further reading in the Liyan knowledge base

Design a testable enterprise use case

Discuss your data, access boundaries and acceptance criteria with the Aivan team.