Foundry agent: OBO auth error when authenticating using API key

Question

Hi,

Was there a recent service-side change that enforces OBO for knowledge base tools, regardless of the connection's authentication type?

What is the supported way to use a Foundry IQ knowledge base tool when calling the agent with an API key? Is a key-based (Custom Keys) connection supposed to work, or is project managed identity the only option?

Thanks!

Answer 1

We are observing the same issue and wanted to provide an additional data point.

Our Azure AI Foundry setup has been working successfully for an extended period using the Responses API together with a Foundry Project API Key. No code changes, configuration changes, or deployment updates were made on our side prior to the failure.

Starting recently, all requests began failing with the following error:

{

  "error": {

    "code": "bad_request",

    "message": "Tools configured with OBO auth are not supported with API key authentication. Please use a different authentication method."

  }

}

Our observations are:

• Requests reach Foundry successfully.
• The failure is returned immediately as an HTTP 400 response.
• The same agents previously worked with API key authentication.
• The issue appeared without any intentional changes on our side.
• The error specifically references OBO authentication although our application is authenticating with a project API key.
• Based on reports from other customers, this appears to have started around the beginning of October 2026.
• Multiple users are now reporting nearly identical behavior in different environments.
• We have reproduced the issue in multiple Azure regions, including Sweden, Germany, and France, which suggests that the problem is not limited to a single regional deployment.

This raises the question whether there has been a backend change in the way Foundry validates agent tools, Knowledge Bases, Azure AI Search integrations, MCP tools, or project connections.

Could Microsoft please clarify:

1. Has there been any recent service-side change regarding OBO authentication enforcement?
2. Can a Knowledge Base / Azure AI Search integration now automatically require OBO authentication even when previously working with API key authentication?
3. Is API key authentication still officially supported for agent scenarios that use Knowledge Bases or connected tools?
4. Is there any ongoing incident, deployment, regression, or regional issue related to this behavior?

At the moment, the symptoms strongly suggest a service-side change because the failure appeared without corresponding application changes and several independent customers seem to be experiencing the same issue simultaneously.

As an additional observation, removing the knowledge-related configuration appears to eliminate the problem. When the affected tool or knowledge integration is removed, API-key-based requests start working again. This strongly suggests that the issue is related to tool authentication handling, Knowledge Base integration, MCP tool processing, or Azure AI Search connectivity rather than the agent invocation itself.

We have also verified the behavior across multiple Foundry projects and regions. The same error can be reproduced in Sweden, Germany, and France, which makes a local configuration issue less likely and raises concerns about a broader platform-level change.

We would appreciate confirmation from the product team whether this behavior is expected, whether a recent platform change has been deployed, or whether this could be an active service incident affecting multiple regions and configurations.

Thank you.

Answer 2

The fact that API-key requests succeed when the knowledge-base or MCP tool is removed is an important diagnostic clue. It suggests that the failure is associated with tool authentication or validation, rather than a general inability to invoke the Foundry agent.

However, I would not conclude that Microsoft has intentionally changed API-key support without confirmation from the product team.

I would isolate this in four steps:

1. Separate inbound authentication from downstream tool authentication.

These are distinct security boundaries:

• The application authenticates to the Foundry project or agent endpoint.
• The agent's configured tool connection authenticates to Azure AI Search, an MCP server, or another downstream service.

Microsoft Foundry supports several downstream connection authentication methods, including "custom-keys", "project-managed-identity", "agentic-identity", and OAuth-based user delegation.

An API key used by the application does not establish which authentication method the tool connection uses.

2. Compare controlled test cases.

Using a nonproduction copy of the affected agent, test:

• API-key invocation without tools.
• API-key invocation with one affected tool.
• Microsoft Entra-authenticated invocation with that same tool.
• The same configuration in another available region, if practical.

Record the HTTP status, error code, region, project endpoint, SDK/API version, and UTC timestamp for each test.

The comparison can help determine whether the failure depends on the inbound credential, a specific tool connection, or a regional service behavior.

3. Inspect the actual connection configuration.

Check the authentication type recorded on the affected Foundry project connection, rather than relying only on the authentication setting displayed for the downstream service.

For MCP connections, Microsoft documents key-based authentication, managed identities, OAuth identity passthrough, and unauthenticated access as distinct options.

If the connection reports "custom-keys" or "none" but the service rejects it as OBO, preserve that discrepancy as evidence.

Do not change production authentication settings merely to make the error disappear. Switching to an identity-based connection can change access permissions and execution behavior.

4. Escalate with a reproducible comparison.

Given the reports across multiple regions and environments, I would open an Azure technical support request and include:

• The first observed failure time.
• Affected regions and project resource IDs.
• Sanitized connection authentication configuration.
• Results with and without the affected tool.
• Results using API-key versus Entra authentication.
• Request IDs or correlation IDs, if returned.

Ask Microsoft specifically whether this is an intended authentication-policy change, a deployment regression, or an incorrectly classified tool connection.

Relevant Microsoft documentation:

• "MCP authentication methods" (https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication?wt.mc_id=studentamb_521824)
• "Foundry toolbox authentication" (https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/tool-authentication?wt.mc_id=studentamb_521824)
• "Agent identity concepts" (https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/agent-identity?wt.mc_id=studentamb_521824)

Bottom line: The available evidence warrants investigating a service-side regression, but the precise cause and supported workaround still need confirmation from Microsoft. The controlled comparison above should help support distinguish an authentication mismatch from a platform change.

Prepared with AI assistance and reviewed against Microsoft documentation.