Azure AI Search has added support for Microsoft Purview sensitivity labels in public preview, and this is one of those features that addresses a real blocker for enterprise AI adoption. The problem is simple: if you ground your AI agents in documents that include confidential information, you need a way to keep that information out of responses for users who should not see it.
Purview sensitivity labels are Microsoft’s mechanism for classifying data as Internal, Confidential, Highly Confidential, or whatever categories your organization defines. Up until now, those labels lived in the source systems SharePoint, OneDrive, SQL Server, file shares but they did not survive the ingestion pipeline into Azure AI Search. Once your data hit the search index, all the classification metadata was lost. Your RAG application had no way to know which documents a particular user was allowed to see.
How it works
Azure AI Search indexers now extract sensitivity labels from supported source systems during ingestion and store them as metadata in the search index. At query time, the search service evaluates whether the user’s credentials grant them access to documents with specific labels. A user who is not cleared for “Confidential” will not get those documents back in search results, even if the semantic match is perfect.
The label enforcement happens at the query layer, not the ingestion layer. This is important because it means you can index everything once, and access control is applied dynamically based on who is asking. You do not need separate indexes for different security tiers.
Why this matters for AI agents
The feature is specifically designed for the grounding pipeline in Azure AI Foundry. When you build a copilot or agent that uses Azure AI Search as a knowledge source, the sensitivity labels flow through the entire chain: source system, search index, agent knowledge base, and finally the response the user sees. If a user asks the agent about something that only exists in confidential documents, the agent simply does not have access to those documents, and the response reflects that.
This removes a common objection from compliance teams. The standard concern is that an AI agent might accidentally surface a confidential document to someone who should not see it. With sensitivity label enforcement built into the search layer, the agent literally cannot retrieve the document to include in its context window. The compliance team can define the labels in Purview, and the AI stack honors them automatically.
What is supported
The preview covers the main Azure AI Search indexers: SharePoint, OneDrive, Azure SQL, and file shares. The labels are extracted during the indexing process and stored as a metadata field that the query system can filter on. The integration also works with SharePoint ACLs for comprehensive document-level security.
For the query side, the enforcement uses the user’s Azure AD identity to determine which labels they are authorized to see. This means the same label-based access control that applies in SharePoint and Microsoft 365 also applies to the AI Search results, without any additional configuration.
What this means for your architecture
If you are building a RAG application on Azure today, you have likely already encountered the access control problem. The usual solutions are not great: duplicate the data into separate indexes per permission level, implement a post-query filter in your application code, or just accept that some documents might leak across authorization boundaries. None of these scale well.
Label-based enforcement at the query layer is the cleanest solution I have seen. You label the data once in Purview, build one search index, and let the search service handle the authorization. The application code does not need to know about sensitivity labels at all it just queries the index, and the index returns only what the user is allowed to see.
How it compares to other approaches
Before this feature, the common workaround for RAG access control was document-level filtering based on SharePoint permissions or custom ACLs stored alongside the indexed content. SharePoint ACLs work for content that lives in SharePoint, but they break down when you have data from multiple sources feeding into the same search index. You end up with a permissions model that is inconsistent across sources, and your application code has to reconcile them.
Purview labels provide a uniform classification layer across all your data sources. A SharePoint document, an Azure SQL row, and a file share PDF can all carry the same “Confidential” label, and the search index treats them identically. This consistency is the main advantage over the older approach.
Another approach some teams use is to keep sensitive data in a separate index that only privileged users can query. This works but duplicates infrastructure and makes it harder to do cross-document search. The user has to know which index to query, which is not how most search interactions work. The label-based approach is invisible to the user: they search once, and the results are filtered automatically.
Getting started
The feature is in public preview, which means you can enable it today in any Azure AI Search service that supports indexers. The configuration steps are documented on Microsoft Learn. You will need Purview labels defined on your source data, and your Azure AI Search indexer configured to extract the label metadata field. Query-time enforcement is configured through the search service’s security filtering options.
For teams already using Purview for data classification, this is a straightforward extension of existing policy into the AI layer. For teams that are not using Purview yet, this is probably a good reason to start, especially if you are building AI agents that need to access sensitive operational data. The preview is available now, and it is worth testing with your own data to see how the label enforcement behaves in practice.