Implement generative AI and agentic solutions 2.2 Build agents by using Foundry

A Foundry agent calls an MCP server that reads blobs from Azure Storage, authenticating…

Study guide skill: Integrate agent tools, including APIs, knowledge stores, search, content understanding, and custom functions

Question B2-018

A Foundry agent calls an MCP server that reads blobs from Azure Storage, authenticating with its agent identity. The agent identity has the correct RBAC role on the storage account, yet every tool call fails authentication. The connection's audience is set to the MCP server's URL. What should you change?

Select one answer.

  • A Grant the agent identity the Owner role on the subscription
  • B Set the audience to the downstream service's resource identifier, https://storage.azure.com ✓ Correct answer
  • C Set the audience to the Foundry project endpoint
  • D Replace the agent identity with a storage account key stored in the agent's instructions

Answer: B

When an agent calls a tool, Agent Service exchanges the agent identity token for an access token scoped to the audience of the downstream service. An incorrect audience causes authentication failures even when RBAC roles are correct, and it must be the downstream resource identifier (https://storage.azure.com for Azure Storage), not the MCP server URL. More privilege or embedded keys don't fix the token audience and break least privilege.

Deep dive

How it works

When a Foundry agent calls a tool with its agent identity, Agent Service performs a token exchange on each call:

  1. It requests a new access token from Microsoft Entra ID, scoped to the audience of the downstream service.
  2. It passes that token to the MCP server or A2A endpoint.
  3. The downstream resource validates the token and checks the agent identity's RBAC role assignments before it grants or denies access.

The audience is the OAuth resource identifier of the service that ultimately enforces access, such as https://storage.azure.com for Azure Storage or https://vault.azure.net for Key Vault. This MCP server reads blobs, so Storage is the service that validates the token.

The agent identity docs warn about this exact failure: an incorrect audience causes authentication failures even when RBAC roles are correctly assigned. The audience must match the downstream service's resource identifier, not the MCP server's URL. With the MCP URL as the audience, Storage receives a token issued for someone else and rejects it.

The other options, and when you'd use them

  • Owner on the subscription: RBAC is already correct. The failure is the token's audience, and extra privilege doesn't change that.
  • Audience = Foundry project endpoint: That's still not the downstream service. The audience must be the resource identifier of the service being called, here Storage.
  • Storage key in the instructions: The downstream resource authorizes through the agent identity's RBAC role assignments. A key in the instructions bypasses that model; the fix is the audience.

Exam tip

Agent identity tool call fails auth but roles are right = check the audience: the downstream resource ID (for example https://storage.azure.com), never the MCP server URL.

References

Last reviewed:

Ready to test yourself? The quiz asks this and every other AI-103 question, with instant feedback. Practice this in a quiz →

All Generative AI & agents questions · AI-103 study guide

Thanks for your feedback!