MS Foundry ToolBoxes Auth Error

Question

MS Foundry ToolBoxes Auth Error

Marco117 85

I’ve been using toolboxes with a client called Open WebUI for a while, connecting to them as an MCP server with Bearer authentication (using my Foundry project’s API key).

Since yesterday, the MCP connection hasn’t been working. I tried connecting to the toolbox from Postman to check whether the issue was with Open WebUI, and I got this error: “Couldn't run the request: Authentication failed while connecting to the MCP server.”

Did something change between yesterday and today? Is anyone else having the same problems?

User's image

Pavan Kumar Purilla 430 Reputation points Microsoft External Staff Moderator

2026-10-25T00:53:49.7666667+00:00

Hi Marco117,

Welcome to the Microsoft Q&A.

We are currently investigating the issue you reported. We kindly request that you allow us some additional time to complete our investigation.

We will provide you with an update as soon as we have further information.

Thank you for your continued patience and understanding.

Marco117 85

Thanks @Alex Burlachenko for the suggestion. I hit the same issue (direct MCP clients such as Open WebUI started failing with 401 around Oct 24). We connect the Foundry Toolbox endpoint (https://<account>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox>/mcp?api-version=v1) directly from MCP clients, so we need a static credential. Tests on Oct 26, 2026, sending initialize followed by tools/list:

Auth sent	Result
`Authorization: Bearer <project API key>`	401: "Unauthorized. Access token is missing, invalid, audience is incorrect (https://ai.azure.com), or have expired."
`api-key: <project API key>` header, no `Authorization` header	200, `tools/list` returns the toolbox tools

This confirms the gateway now validates the Bearer value as an Entra token with audience https://ai.azure.com, so a project API key no longer passes that way.

Workaround that worked for us: sending the same project API key in an api-key header instead of Authorization: Bearer works from curl, Postman and Open WebUI (auth type "None" plus a custom api-key header). Open WebUI is back to working as before.

Caveat: the only documented option I found for this endpoint is Entra (Authorization: Bearer with the https://ai.azure.com/.default scope, e.g. in "Create and manage a toolbox" and "Use a toolbox with a hosted agent"). I couldn't find the api-key header documented for toolboxes, nor an announcement of the Oct 24 change, so I wouldn't rely on it long term.

@Microsoft Teams could you confirm whether the project API key is still a supported way to authenticate directly against the toolbox MCP endpoint, and if so, through which header? Also, is there a supported static-credential option for MCP clients that can't obtain Entra tokens? Was the Bearer validation change intentional?

Using api-key: <project API key> header, no Authorization header , the result is 200:
User's image

1 answer

Your answer

Pavan Kumar Purilla 430 Reputation points Microsoft External Staff Moderator

2026-10-25T00:53:49.7666667+00:00

Hi Marco117,

Welcome to the Microsoft Q&A.

We are currently investigating the issue you reported. We kindly request that you allow us some additional time to complete our investigation.

We will provide you with an update as soon as we have further information.

Thank you for your continued patience and understanding.
Marco117 85 Reputation points

2026-10-26T14:05:52.4966667+00:00

Thanks @Alex Burlachenko for the suggestion. I hit the same issue (direct MCP clients such as Open WebUI started failing with 401 around Oct 24). We connect the Foundry Toolbox endpoint (https://<account>.services.ai.azure.com/api/projects/<project>/toolboxes/<toolbox>/mcp?api-version=v1) directly from MCP clients, so we need a static credential. Tests on Oct 26, 2026, sending initialize followed by tools/list:

Auth sent Result

Authorization: Bearer <project API key> 401: "Unauthorized. Access token is missing, invalid, audience is incorrect (https://ai.azure.com), or have expired."

api-key: <project API key> header, no Authorization header 200, tools/list returns the toolbox tools

This confirms the gateway now validates the Bearer value as an Entra token with audience https://ai.azure.com, so a project API key no longer passes that way.

Workaround that worked for us: sending the same project API key in an api-key header instead of Authorization: Bearer works from curl, Postman and Open WebUI (auth type "None" plus a custom api-key header). Open WebUI is back to working as before.

Caveat: the only documented option I found for this endpoint is Entra (Authorization: Bearer with the https://ai.azure.com/.default scope, e.g. in "Create and manage a toolbox" and "Use a toolbox with a hosted agent"). I couldn't find the api-key header documented for toolboxes, nor an announcement of the Oct 24 change, so I wouldn't rely on it long term.

@Microsoft Teams could you confirm whether the project API key is still a supported way to authenticate directly against the toolbox MCP endpoint, and if so, through which header? Also, is there a supported static-credential option for MCP clients that can't obtain Entra tokens? Was the Bearer validation change intentional?

Using api-key: <project API key> header, no Authorization header , the result is 200:

Answer 1

Hi Marco117 & thx for join me at Q&A platform,

that both Open WebUI and Postman are failing, which makes this less likely to be an Open WebUI-specific issue. But I wouldn't conclude there's a Foundry service outage just yet.

One thing stands out: you're using your Foundry project's API key as a Bearer token to authenticate to the Toolbox MCP endpoint.

Microsoft's current Toolbox documentation shows a different authentication pattern for direct MCP clients: a Microsoft Entra access token scoped to https://ai.azure.com/.default, sent in the Authorization: Bearer header.

That's an important distinction. A Foundry project API key isn't the same thing as an Entra OAuth access token, even if both can be used to authenticate to certain Foundry APIs.

I'd test the same Toolbox endpoint from Postman using a freshly acquired Entra token instead of the project API key. You can obtain one after signing in with Azure CLI:

az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv

Make sure the signed-in identity has the appropriate Foundry project permissions, such as the Foundry User role. Use the exact Toolbox MCP endpoint, including ?api-version=v1.

If that works, we've narrowed the problem down to the authentication method rather than the Toolbox itself. It would also suggest that the previous API-key-based behavior shouldn't be relied on without confirmation from Microsoft.

If Entra authentication fails too, check the actual HTTP response status and headers. A 401 suggests token validation, expiration, or audience issues, while a 403 points more toward authorization. The generic Postman message doesn't tell us which one occurred.

Regarding whether something changed yesterday, I couldn't confirm a Microsoft-announced authentication change or service incident affecting Toolboxes on October 24. So I wouldn't claim this is a confirmed regression.

If the same configuration worked until October 24 and now fails across multiple clients, I'd raise a Foundry support case with the UTC timestamps, project region, Toolbox endpoint (without credentials), HTTP status, and request correlation IDs. Ask engineering whether the Toolbox gateway's authentication requirements or token validation behavior changed. Does your existing project API key still work for normal Foundry model inference requests, and have you tried connecting to the Toolbox using an Entra access token instead?

That comparison should tell us quite a lot.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Alex Burlachenko 26,035 Reputation points MVP Volunteer Moderator

2026-10-26T15:46:49.6866667+00:00

Hi Marco,

Thanks for the detailed testing and confirmation. This is really useful, especially the fact that tools/list and tools/call work with the api-key header.

The 401 response strongly suggests that the gateway now interprets Authorization: Bearer as an Entra access token rather than accepting a project API key in that header.

However, a working api-key header doesn't necessarily mean it's officially supported for Toolbox MCP endpoints. I wouldn't rely on it as a permanent authentication method until Microsoft confirms that.

For production use, Entra authentication with automatic token renewal is the safer documented approach. Clients without native Entra support could use an authentication proxy.

I'd also like to see Microsoft clarify whether the October 24 behavior change was intentional and whether API-key authentication will remain supported. Your findings provide good evidence for that investigation.

rgds,

Alex
p.s. if my answer is help - pls mark it as an answer