Foundry Agent Service: Azure AI Search tool returns "Access denied" with keyless (Entra ID) connection, despite documented RBAC

Question

Foundry Agent Service: Azure AI Search tool returns "Access denied" with keyless (Entra ID) connection, despite documented RBAC

Abisola Adebiyi 20

Hi all,

We're trying to use the built-in Azure AI Search tool on a Foundry prompt agent with keyless (Microsoft Entra ID) auth. Every tool call fails with:

400 tool_user_error: "Access denied. Check your permissions or managed identity access to the search service."

Setup

Foundry account (new Foundry, Canada East), one project, gpt-4o deployment
Account identity: system-assigned + user-assigned (the system-assigned one was added specifically for this)
Azure AI Search: Basic, Canada Central, public network access, no private endpoint, no IP rules, auth mode "Role-based access control and API keys"
Project connection: category CognitiveSearch, authType AAD, created via ARM REST
Agent: prompt agent with a single azure_ai_search tool
SDK: azure-ai-projects 2.4.0 (Python)

The index is populated, and we can query it directly with our own Entra ID token, so the search service and index themselves are fine.

What we've tried

Account system-assigned identity: Search Index Data Contributor + Search Service Contributor on the search service (as the "Connect an Azure AI Search index to Foundry agents" doc describes): Access denied
Project managed identity: Search Index Data Reader at index scope, then at service scope, then with Search Service Contributor added: Access denied
Agent instance identity: Search Index Data Reader at index scope: Access denied
Account user-assigned identity: Search Index Data Reader (index scope) + Search Service Contributor: worked exactly once (returned results with url_citation annotations), then failed with Access denied ever since, including after recreating the connection and the agent version

Questions

Which identity does the Azure AI Search tool use when the project connection's authType is AAD: the project managed identity, the account's system-assigned identity, the account's user-assigned identity, or the agent identity? The docs say "account system-assigned" in the setup steps and "project managed identity" in the troubleshooting table.
What are the minimum roles, and at which scope (service or index)?
Is a user-assigned identity on the Foundry account supported for this tool? If both are supported, is there any material difference between using the account's system-assigned identity and a user-assigned one here (behaviour, supported scenarios, or roadmap)?
Is authType "AAD" the right value for a keyless CognitiveSearch connection, or does the tool expect a different value (e.g. a project-managed-identity type)?

Thanks!

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Abisola Adebiyi

Thanks for the thorough testing. To your first question: the "Connect an Azure AI Search index to Foundry agents" page isn't fully consistent here. The prerequisites name the system-assigned managed identity of the Foundry account, while the troubleshooting table says the "project's managed identity". Both places list the same two roles at service scope: Search Index Data Contributor and Search Service Contributor.

What stands out in your results is that the only success came with the user-assigned identity, and your account has both a system-assigned and a user-assigned identity. When both exist, it isn't documented which one the tool picks for the token, and that ambiguity fits the "worked once, then denied" behaviour. Here's how I'd remove the guesswork:

Give every candidate identity the same two roles at the search service scope (not index scope): the account system-assigned identity, the account user-assigned identity, and the project managed identity.
Wait about 10 minutes for the role assignments to propagate before testing. Testing right after a change often still returns 403.
Test with a brand-new agent version and a new conversation.
Once it works consistently, remove the roles from one identity at a time and retest. That tells you which one the tool actually uses, so you can tighten permissions again.
If you don't need the user-assigned identity on the Foundry account for anything else, removing it is the other clean option. The doc's documented path is the system-assigned one.

If it still fails with all three identities holding both roles at service scope, that's worth a support case. Include the request ID from the tool_user_error, but share it only in the ticket.

When it worked that one time, had you just assigned the roles to the user-assigned identity, or were they in place for a while?

If this resolved your issue, please consider accepting it as the answer. If the 403 persists with all identities granted, let me know and I'll be happy to keep helping.

Reference:

https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/ai-search

Abisola Adebiyi 20 Reputation points

2026-10-23T12:30:07.89+00:00

Thanks so much, your suggestion did the trick! Here's what we ended up finding, in case it helps anyone else:

It's the project's managed identity that the search tool uses. We stripped all the roles off the account identities and it still worked.

You don't need a system-assigned identity on the account. We added one to test, then removed it, and nothing broke.

The roles that worked (both at the search service level, not the index): Search Index Data Reader + Search Service Contributor. Reader was enough since the tool only reads.

Thanks again!