How to propagate credential in Azure Foundry agent?

Question

How to propagate credential in Azure Foundry agent?

Thipok Th 0

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

Anonymous
Connection
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

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
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?

0 comments

2 answers

Your answer

Answer 1

Yes, there is now a cleaner option for the authentication side of this architecture: OAuth identity passthrough for the MCP connection.

For your scenario, I would separate two concerns that are related but not identical:

Who is invoking the MCP tool?
How do I attribute and enforce the total cost generated by that user, including nested calls?

For #1, Microsoft Foundry Agent Service supports OAuth identity passthrough for MCP servers. Unlike a key-based connection, agent identity, or project managed identity, OAuth identity passthrough preserves the individual user's context. This avoids creating one agent or static API key per user.

With a custom MCP server, you can configure custom OAuth using your own Microsoft Entra app registration. The user authenticates and consents, and the MCP server receives authentication associated with that user's session. For an Azure Functions-hosted MCP server, Microsoft also documents OAuth identity passthrough as the production-oriented option when each user must authenticate individually and user context must persist.

For #2, I would not treat identity passthrough by itself as a complete cost-accounting solution.

If your flow is roughly:

User → Foundry Agent → MCP/Azure Function → LiteLLM → image/model endpoint

then propagate a stable user/correlation identity into your own metering layer after authentication. At the LiteLLM/gateway layer, record usage against that authenticated principal or an internal opaque user ID. This gives you a place to enforce per-user quotas/budgets for the downstream calls.

I would also keep authorization and accounting separate. The identity/token proves who the caller is and what they are allowed to access. Your gateway/metering system should decide how much of a resource or budget that identity may consume. Avoid using a user-supplied ID/header as the authoritative accounting identity unless it is validated against the authenticated principal.

There is one remaining boundary to be careful about: the Foundry agent's own base-model consumption and downstream MCP/LiteLLM consumption are generated at different layers. OAuth passthrough gives you user context at the MCP boundary, but I would not assume that this automatically provides a single native per-user budget covering both layers. If you require one hard budget across the entire chain, correlate telemetry from both layers using a request/user correlation ID and enforce the combined policy in your own control/metering plane.

So architecturally I would prefer:

User

→ Foundry Agent

→ OAuth identity passthrough

→ authenticated MCP/Azure Function

→ validated user/correlation identity

→ LiteLLM/API gateway

→ per-user quota + usage ledger

→ downstream model/tool

That scales much better than duplicating an agent per user, while keeping authentication, authorization, observability, and cost governance as explicit concerns.

Microsoft's documentation on MCP authentication is here:

https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication

For a deeper treatment of the identity/RBAC side, Microsoft Learn also has an intermediate learning path covering authentication, authorization, managed identity, and RBAC for Azure AI workloads:

https://learn.microsoft.com/en-us/training/paths/manage-iam-for-ai-workloads-on-azure/?wt.mc_id=studentamb_521824

One additional security note: Microsoft documents tenant and trust restrictions around OAuth identity passthrough, including same-tenant requirements for the Foundry project and restrictions on sending Microsoft-audience tokens to custom/third-party MCP endpoints. For a custom MCP server, use an audience/app registration that you control rather than designing around forwarding a Microsoft service token downstream.

Answer 2

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:

API Key / Connection → static credential, no individual user context.
Agent/Project Managed Identity → better security and secret management, but the downstream service sees the agent/project identity, not the individual user.
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:

MCP authentication: Microsoft Foundry – MCP server authentication
Agent identity & OBO: Microsoft Foundry – Agent identity concepts
AI Gateway governance: Microsoft Foundry – Govern MCP tools using an AI Gateway

Pls check and let me know if any further ques

Thanks
Deepanshu

Thipok Th 0 Reputation points

2026-09-15T11:49:53.06+00:00

Thanks, this is helpful. OAuth identity passthrough sounds like it could address the user identity part

My MCP server is hosted on Azure Functions. One of its tools generates images by calling LiteLLM, where each user already has their own API key and budget

If I understand correctly, I could use OAuth passthrough to identify the user in my function, then have the function look up that user’s LiteLLM key and use it for the image request. Is that the intended approach, or is there a built-in way to handle this mapping?

The part I’m still unsure about is the agent’s own model usage. For example, if a user asks the agent to generate an image, I want both the agent’s text-model calls and the image generation call to count toward that user’s same budget

Can Foundry pass the user identity to the gateway for its base-model calls too? If so, is there an example showing both parts working together? Do I need to set some settings explicitly, or I steer them through skills, and instructions?

Also, the MCP gateway documentation says tools using managed OAuth aren’t routed through the integrated gateway. Should I use custom OAuth for this setup?

A small end-to-end example would really help