x-ms-query-source-authorization - Behavior difference

[abhilash-uniper]

Hi Team,

We are seeing a difference in functionality with AI search when the index has permission filters enabled.

Earlier (I think even before 3-4 days)

1. We have an index with permission filter fields enabled
2. We have loaded in data which are open to all and also restricted to users and groups

When querying this is where things have changed now (we are not sure why)

When we query the index using AI search key authentication and without x-ms-query-source-authorization header, AI search used to return all data, without applying any permission filter. This was the case on the portal as well when we looked at records we can see everything.

However, starting from today we are noticing change in this behavior. Now what is happening is if we query using the access key auth only (without x-ms-query-source-authorization header) only records which are marked as available to all is returned. Any records scoped to users are not returned.

This is problematic for us, as we have background processes which adds and removed entries from the AI search. Now querying for existing reocrds in AI search is not working at all as it does not return any results.

Using REST API -> THE CALL

indexes/{INDEX}/docs?search=*&$count=true&api-version=2025-05-01-preview
with api-key header (admin key) is not returning any data when the docs have permission filter applied.

Our understanding was that the permission filters only applies if the request has x-ms-query-source-authorization header.

Could you kindly check it and let me know if anything is changed in this area. This is very important for us, as we may not able to do lot of background maintenance activities if this is the case.

[gmndrg]

Why the behavior changed and why it matters
The previous behavior—returning all documents when using only the admin API key—was identified as a potential security gap because it bypassed ACL enforcement. This meant sensitive, user-scoped content could be exposed without identity context, which is not aligned with zero-trust principles.

What’s new in the preview API
This change is part of a fix for the older preview version 2025-05-01-preview and REST API 2025-11-01-preview has the capability to add the proper role to see all results for debugging and reflects an increase in security controls for query-time access enforcement. Starting with this preview, permission filters apply even when using admin keys unless you explicitly provide identity via the x-ms-query-source-authorization header or the elevated read as per the document provided below. This allows that:

• Background processes and admin operations remain more secure.
• ACL data is never returned without explicit proper authorization.

How to view all data for troubleshooting
If you need to investigate or debug scenarios where ACL filtering affects results, you can use the new elevated read access feature in preview. This requires an explicit opt-in and is documented here: https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement#elevated-permissions-for-investigating-incorrect-results. You should enable RBAC for your search service (since you're using API keys, both).

I hope this helps

[abhilash-uniper]

Hi @gmndrg ,

Thank you for the reply. We were surprised with this change in behavior.

One question though - is the behavior like before if we use 2025-05-01-preview api-version ?

[gmndrg]

@abhilash-uniper Thank you for following up. We will get back to you in a few days accordingly with the response.

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @kuanlu95 @mattgotteiner.

[gmndrg]

Hi @abhilash-uniper to ensure secure debugging and prevent unintended data exposure, the latest preview version (2025-11-01-preview) require using the elevated read capability. This change was introduced as a security improvement across all preview including ACL functionality support (2025-05-01-preview and 2025-08-01-preview) to avoid scenarios where an application without the dev introducing token verification could inadvertently return results to end users. Using the updated version ensures administrators can view results safely while maintaining compliance with security best practices. We usually are able to communicate all changes in documentation and communications, however, for public preview, security improvements would be prioritized when not utilizing best practices to guard rail the solutions as possible. Thank you for your understading.