Introduction

AI agentic grounding, Retrieval-Augmented Generation (RAG) apps/copilots, and enterprise search are game-changers, but they stay safe only when every response obeys the file-level permissions you already set in your data source. Without built-in help, developers have to hand-code security trimming, unravel nested groups, and tweak the logic whenever someone’s role shifts.

Starting with REST API version 2025-05-01-preview, Azure AI Search introduces native Microsoft Entra-based POSIX-style Access Control List (ACL) and Azure Role-Based Access Control (RBAC) support, alongside expanded capabilities in the Azure Data Lake Storage Gen2 (ADLS Gen2) built-in indexer. These enhancements make it easier to enforce document-level security across ingestion and query workflows, whether you’re pushing permission metadata directly or indexing content from ADLS Gen2.

Key functionalities:

1. Native ACL and RBAC Enforcement

Azure AI Search now natively supports ACL and RBAC container metadata for Microsoft Entra-based systems, enabling developers to push permissions via SDKs or REST API. Permission metadata is stored alongside text and vector data within the index.

2. Enhanced ADLS Gen2 Indexer

The built-in ADLS Gen2 indexer has been upgraded to automatically capture ACLs and RBAC container roles during indexing. With minimal configuration updates, permissions can flow directly into the index, eliminating manual intervention and enabling low/no-code ingestion workflows.

Note: You can use either Native ACL/RBAC enforcement or ADLS Gen2 Indexer enhancements to push permissions into the index, as both methods produce the same result for secure querying.

3. Query-Time Validation and Trimming

At query time, Azure AI Search validates the caller’s Microsoft Entra token and applies ACLs and RBAC roles to automatically trim the result set. This helps ensure users only access authorized documents without requiring developers to write custom filter logic or manage nested group expansions.

The result: Azure AI Search’s support for Microsoft Entra-based ACLs and RBAC roles eliminates the need for developers to manually handle security trimming, write custom filter logic, or expand nested groups during queries. Additionally, the enhanced ADLS Gen2 integration through built-in indexers reduces the complexity of propagating permission metadata from the source, removing the need for custom indexing code and offering a more seamless, built-in approach.

What’s Included in the Preview

Why Security Matters for Gen AI Apps and AI Agents

Generative-AI apps are good as long as they don’t “overshare. One stray, confidential slide deck in a response can erode employee trust, spark a compliance review, and freeze your rollout. By enforcing ACL/RBAC container permissions inside Azure AI Search, you help protect these pillars of a successful deployment:

User trust. Every query is trimmed to the user’s ACLs and RBAC roles before it reaches the Large Language Model (LLM), so users can explore freely without worrying about stumbling onto off-limits material as long as the permissions metadata is refreshed in the search index.

Audit-ready compliance. Because permission checks run inside a Microsoft-managed service and require a few defined steps to refresh the permissions, auditors can point to a standardized, fully documented control instead of sifting through pages of custom filter code. Setup is a one-time configuration update in service and code.

Also, when AI agents ground their responses on data retrieved through Azure AI Search, they honor ACLs and RBAC roles and enforce strict security boundaries that prevent accidental exposure of restricted or confidential information. By incorporating these permission controls into the query pipeline, organizations enable AI responses that are based solely on data the requesting user is authorized to access. This approach helps mitigate risks of oversharing sensitive content, which could otherwise compromise security, violate compliance policies, or create trust issues among employees.

Why It Matters for Developers

Building AI agents with grounding data and RAG apps usually means writing a second security system in parallel with the one your storage account already has. You fetch results from Azure AI Search, unroll every nested Entra group, and run an OR filter against user IDs. The code works—until a role changes or a new group is added, and suddenly you’re probably back in the editor, redeploying a fix during an audit crunch.

With the new Entra-based permission functionality managed on the service-end, an entire layer collapses into a few steps to make ACL/RBAC container roles in your source visible in your index.

• Ingestion stays familiar. Keep using the built-in indexer or your own indexing pipeline. The only difference is the new security configuration in your index, the options used while you push your data in your indexer configuration/push API/SDK options, and triggering the updates.


• Query security filter logic disappears. The SDK call you already use—keyword, vector, or hybrid—doesn’t change. Add the user’s Entra token and the service returns a result set that’s pre-filtered to that identity. No custom filter strings, no manual group expansion.


• Updates are low-touch. When roles or ACLs change, if you’re using ADLS Gen2 as the data source with built-in indexers, change lastModifiedDate timestamp, call /resetdocs for a few blobs, or kick off /resync (permissions) for everything and run the next scheduled crawl —whichever fits your workflow. No code edits, just an API call or a timestamp bump.


• You regain sprint velocity. Instead of burning cycles on security-trimming edge cases, you can focus on ranking quality, chunking strategy, or the chat UX—knowing the service layer keeps your results on policy.

This feature helps Entra-based ACL systems turning weeks of guard-rail engineering into fewer lines of configuration.

Architecture at glance

The diagram below walks through a high-level journey— from an ACL-protected file in ADLS Gen2 to a permission-trimmed answer in your chat UI. First, a built-in ADLS Gen2 indexer picks up both the document and its ACL/RBAC metadata. That metadata is stored inside the Azure AI Search index alongside your text and vector embeddings.

Importantly, ACLs are modeled and indexed in a specific way that enables Azure AI Search to efficiently handle high-performance queries over very large datasets, while applying ACL trimming. When a user’s query arrives, Azure AI Search validates the user’s Microsoft Entra token, intersects it with the stored permissions, and returns only the documents that the user is cleared to see, maintaining a balance between secure access control and scalable query performance.

Prefer to run your own ingestion logic and/or have a different Entra-based ACL system? No problem. You can push documents through the Azure AI Search REST API or SDKs and include the same userIds, groupIds, and rbacScope fields—achieving identical, service-side enforcement without the built-in indexer.

Get Started

 1. Pick your ingestion path and prepare your index:

     a) ADLS Gen2 Built-in indexer (low code)

You can use the built-in functionality to configure ACL/RBAC container role copy to your index via ADLS Gen2 indexers. Here’s the documentation on how this works and how to configure this functionality step-by-step:

• Concept and workflow:  https://aka.ms/azs-acls-rbac-indexers


• Step-by-step how-to: https://aka.ms/azs-howto-index-permissions


• Make sure your code has the triggers to keep ACLs/RBAC roles up to date, as you update them on the source: https://aka.ms/azs-acls-rbac-indexers

      b) Custom push pipeline (use custom code for indexing from any Entra-based ACL system).
You can also prepare your index for permission filtering, then send documents (new or updated) through the Search REST API or SDKs with the accompanying permission metadata. If you already have an ingestion job, it’s a minor tweak; if you’re starting fresh, a short script that reads each file and posts the payload is all you need. Either way, once those fields are included, Azure AI Search handles the enforcement.

Here’s how this works and how to configure it via your custom indexing pipeline code: https://aka.ms/azs-acls-rbac-push

2. Query exactly as before—just pass the user token

Attach the caller’s Microsoft Entra access token. Azure AI Search trims the result set server-side, so your chat prompt or UI receives only documents the user can read.
Here is how to query AI Search preserving RBAC roles and ACLs from an Entra-based ACL system: https://aka.ms/azs-acls-rbac-query

Developer Tips

• Pair with vector search + hybrid retrieval and semantic ranker to deliver secure, highly relevant answers in your Gen AI apps.​


• Give this functionality a try in your test environments. Use client-side filters via security trimming if you require production document-level access while this functionality is in public preview: Access Control in Generative AI applications with Azure AI Search | Microsoft Community Hub.


• Built-in indexer updates are not provided in real-time and it is expected that there is a drift between the source document ACL/RBAC role metadata and the search index stored metadata Very large containers with complex hierarchical folder structures or a large number of blobs are expected to take longer to copy the content and security data.


• Make sure you use the triggers mentioned in https://aka.ms/azs-acls-rbac-indexers to keep your ACL/RBAC role data updated.

What’s next?

• Multi-vector field support blog post


• What’s new in Azure AI Search?


• Feedback: Share thoughts in this blog post.