How to propagate credential in Azure Foundry agent?

Thipok Th 0 Reputation points
2026-09-10T07:40:39.5466667+00:00

Microsoft Foundry support multiple model deployment, along with agent creation, which include tool uses from first-party like Microsoft Foundry IQ, or third-party like Open API specs. However, supposed that the agent need to access tools / MCP with authorization. Current method only support 3 modes, which are

  1. Anonymous
  2. Connection
  3. Managed Identity

Connection allows for custom API key to be set, and use. However, it is a static key. So supposed that I use cost control frontend like AI Gateway, or LiteLLM - I can only use a designated key to authenticate. There are no alternatives to track / cost control throughout the nested calls.

I can think of 2 solutions

  1. Setup similar agent, but designate each one to individual user. This limit the authentication key to only one user, thus can be isolate. However, if the number of user grows - this will not scale
  2. Bypass foundry agent altogether, and develop my own agent flow / harness. They can use the open ai endpoint directly

But both are band-aid fix at best. So are there alternative ways to keep track?

Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Deepanshu katara 18,230 Reputation points MVP Volunteer Moderator
    2026-09-10T08:56:55.3933333+00:00

    Hello , Welcome to MS Q&A

    I checked the latest Microsoft Foundry documentation, and there is actually a more scalable option than creating one agent/API key per user or completely bypassing Foundry.

    Microsoft Foundry Agent Service now supports OAuth Identity Passthrough (OBO) for MCP servers. This allows the agent to operate on behalf of the signed-in user, rather than using a single static API key for everyone. Microsoft explicitly states that with OAuth identity passthrough, user context persists and the MCP server can receive the user's delegated identity/permissions.

    So the options are:

    1. API Key / Connection → static credential, no individual user context.
    2. Agent/Project Managed Identity → better security and secret management, but the downstream service sees the agent/project identity, not the individual user.
    3. OAuth Identity Passthrough (OBO) → recommended when we need per-user authorization and identity propagation. The user authenticates/consents, and Foundry uses that user's credentials when calling the MCP server.

    For the cost-control scenario, we can still place an AI Gateway / Azure API Management layer in front of the MCP/API. Microsoft now has Foundry documentation specifically for governing MCP tools through an AI Gateway, including authentication, rate limiting, audit logging, and centralized observability.

    Therefore, I would suggest the architecture as:

    User → Foundry Agent → OAuth/OBO → AI Gateway/APIM → MCP/API

    This avoids creating a separate agent or static key for every user and gives us a path to enforce per-user authorization, throttling and usage tracking at the gateway layer.

    Microsoft documentation:

    Pls check and let me know if any further ques

    Thanks
    Deepanshu

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.