A practical review of document authorization in retrieval-augmented generation. Azure AI Search examples distinguish string filters, preview token-based ACL enforcement, chunk permissions, source synchronization, and answer reuse.
At a glance
Key findings
- Apply document authorization before retrieved content enters model context. An instruction telling the model to keep a secret is not a substitute for that decision.
- Every searchable chunk needs the permission metadata used to authorize it. Source permission changes also need an explicit synchronization path.
- Test retrieval, source links, and cached answers with different users. A permitted answer for one caller is not automatically permitted for another.
Start with the document the caller cannot read
Consider a hypothetical internal assistant used by engineering and finance. Both teams can read the incident handbook, but only finance can read an acquisition worksheet. A question about next quarter's infrastructure spending might make both documents relevant to a search engine. Relevance is not permission. The security question is whether the worksheet can enter the answer-building process for an engineering user at all.
Place the authorization decision before protected text is supplied to the model. Removing a source link from the final answer would not undo an earlier disclosure into the generation context. Nor should a system prompt be responsible for deciding which organizational groups can read a document. That decision belongs to the application's identity and access controls, where its inputs, rules, and failures can be inspected.
This article uses Azure AI Search to make that boundary concrete. Its native document permission features are documented under the 2026-05-01-preview API. The older security-filter pattern is different: it compares principal strings supplied in a query and does not authenticate those strings itself. These are distinct implementation choices, not interchangeable guarantees. [1][2]
Bind identity to the retrieval request
Write down three separate decisions: whether the person may use the application, whether the application may query the search service, and whether that person may read each returned document. A service credential that can search an index answers the second question. It should not silently answer the third. Keeping these decisions separate makes a failed permission test easier to diagnose.
For an application-managed filter, derive the allowed identities from the authenticated session and a trusted authorization service. Do not accept a browser's list of group identifiers as proof of membership. Treat a missing identity, an unresolved group lookup, or an invalid policy result as a denied retrieval path until the application has an explicit, reviewed alternative. Those are proposed design requirements, not claims about a particular tenant's configuration.
Azure's native token-based path adds a user token to the query and checks indexed permission metadata. Its documentation also distinguishes elevated investigation access from ordinary user queries. Keep privileged diagnostic paths separate from the assistant's normal retrieval client, and verify that the selected API version behaves as expected when the user token is absent. [3]
Permissions travel with the retrieved content
Identity and document permissions meet before protected chunks enter model context.
Source. Azure AI Search documentation [1]-[4].
Method. Original editorial architecture derived from documented permission flows. Table entries identify proposed review points, not observed failures. No deployment or leakage experiment was performed.
Accessible table and figure data
| Stage | Permission evidence | Failure to test |
|---|---|---|
| Source document | Current source ACL | Access changes without a refresh |
| Search chunk | ACL metadata on the returned record | A child chunk lacks the required ACL |
| Caller | Authenticated identity and trusted membership | The client supplies an unverified group |
| Retrieval | Document-level access decision | Relevant but unauthorized text is returned |
| Source link | Current access for the reader | The citation exposes a separate unprotected route |
| Cached answer | Appropriate identity and policy context | A different user receives private text |
| Stage | Permission evidence | Failure to test |
|---|---|---|
| Source document | Current source ACL | Access changes without a refresh |
| Search chunk | ACL metadata on the returned record | A child chunk lacks the required ACL |
| Caller | Authenticated identity and trusted membership | The client supplies an unverified group |
| Retrieval | Document-level access decision | Relevant but unauthorized text is returned |
| Source link | Current access for the reader | The citation exposes a separate unprotected route |
| Cached answer | Appropriate identity and policy context | A different user receives private text |
Authorize the chunk that actually reaches the model
A document can become several independently searchable records after splitting and embedding. Review the record returned by retrieval, not only the original file. If the permission model lives on a parent record while the query returns a child record, the application needs a reliable way to make the intended access decision for that child.
Microsoft's SharePoint indexer guidance distinguishes direct field mappings from index projections. When a skillset writes chunks, the ACL fields must be projected onto those chunks; a two-index design needs the appropriate metadata in both queryable indexes. This is a useful reason to inspect the stored search records during testing rather than assuming that successful ingestion preserved every security field. [4]
Build a small acceptance fixture with one shared document, one restricted document, and multiple chunks from each. Give the documents similar vocabulary so the restricted material is relevant to ordinary searches. The expected result is not that the restricted document ranks poorly. It is that unauthorized chunks are excluded. Record returned identifiers and authorization decisions without copying sensitive source content into the test report.
Give permission changes a visible synchronization path
Revocation introduces a timing question. Someone removes access in the source repository, but the assistant may still depend on permission metadata already stored in its index. Azure documents this synchronization dependency. For the SharePoint preview path, changes inherited from parent scopes require an explicit refresh rather than relying only on ordinary item change detection. [2][4]
Assign an owner to that interval. The design should state what starts a refresh, what confirms completion, how failures are reported, and what the assistant does while the permission state is uncertain. A conservative application might temporarily exclude affected content. Another design might perform a fresh source authorization check. The right choice depends on sensitivity and operational constraints, but leaving the interval undefined is not a control.
A useful revocation test records the source change, index update, and first denied retrieval as separate events. Repeat the test with a direct document change and an inherited permission change. Do not describe an observed delay as a guarantee for future changes. If an exercise was never run, publish the procedure and the unresolved question instead of an invented propagation time.
Keep citations and cached answers inside the boundary
The retrieval check is necessary but does not finish the review. A citation can open a different route, generate a download link, or request a preview. An answer cache can return text without repeating retrieval. Include these paths in the application's authorization design because they can expose the same protected content through a different mechanism.
For this proposed design, a source link should require the reader's current authority or lead to a source system that enforces it. A shared answer cache should only contain material whose access conditions are appropriate for everyone who can receive that entry. Where answers depend on private permissions, make the relevant identity and policy context part of the cache decision, or avoid sharing those entries.
Also consider an answer saved into a conversation and reopened after access changes. Decide whether the application rechecks permission, hides the earlier answer, or treats conversation retention as a separate approved disclosure policy. There is no universal answer across products. The requirement is a documented decision that does not arise accidentally from how the interface stores text.
Collect a permission receipt before release
Use synthetic accounts and documents for the release test. Exercise an allowed user, a denied user, a missing identity, a revoked membership, a chunk with incomplete metadata, and a cached answer reopened under a different session. Include direct retrieval and every application route that can display source content. A passing search test does not cover a separate download handler.
Record the fixture version, query, authenticated test role, returned document identifiers, expected decision, actual decision, and relevant refresh status. Keep the record small enough that a reviewer can see what was tested. A screenshot of a polite refusal is insufficient if the restricted material was already retrieved or written to logs behind the interface.
The release decision should identify unresolved cases as well as passing ones. Preview upgrades, connector changes, new chunking strategies, and new cache layers can all change where the boundary is enforced. Reuse the permission fixture after those changes. The objective is a repeatable access decision with evidence, not a claim that the model has learned which documents are confidential.
Method and provenance
Review of the cited primary documentation on August 28, 2026, with an original authorization workflow, hypothetical example, and proposed acceptance tests.
No Azure tenant, connector, permission propagation, or RAG leakage experiment was tested. Native ACL examples are preview features. Documentation update dates are not feature release dates.
AI assistance. AI assistance was used to research sources, draft and structure the article, and prepare the visual specification. No human technical review is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- Security filters for trimming results in Azure AI Search, updated August 24, 2026 Microsoft. Accessed .
- Document-level access control in Azure AI Search, updated August 12, 2026 Microsoft. Accessed .
- Query-time ACL and RBAC enforcement, updated August 8, 2026 Microsoft. Accessed .
- SharePoint indexer permission metadata, updated August 12, 2026 Microsoft. Accessed .