Permission-trim AI retrieval before it touches customer data

Source facts: search relevance and authorization are different decisions

Microsoft’s document-level access-control guidance for Azure AI Search describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features.

The security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index.

Microsoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions.

DSE recommendation: make every retrieval prove the caller can see the result

Design the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions.

1. Declare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access.
2. Carry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved.
3. Evaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user.
4. Use two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person.
5. Control caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary.
6. Test negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose.

Factual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system.

Measure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place.

Official references

• Microsoft Learn, Document-Level Access Control in Azure AI Search.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1.
• Microsoft Security, New tools and guidance: Announcing Zero Trust for AI, March 19, 2026.