Teams Bot calling Foundry Prompt agent with user credentials

Hello @Teodora

Yes. This aligns with the documented per-user authentication model, provided your bot invokes the Entra-authorized Foundry endpoint using the appropriate user context and authentication flow.

Currently, the bot calls Foundry using its service principal. Foundry therefore receives the bot as the authenticated caller, which does not establish a distinct authenticated Foundry identity for each Teams user.

For your scenario, the intended flow is:

1. Authenticate the Teams user and request a Microsoft Entra access token using the https://ai.azure.com/.default scope for the Foundry endpoint.
2. Invoke the prompt agent through the Foundry Responses API using that authenticated user context rather than a shared service-principal identity.
3. Keep the MCP connection configured with OAuth identity passthrough and your custom OAuth application.
4. When the user first invokes the MCP tool, Agent Service can return an oauth_consent_request containing a consent link. Surface that link to the user.
5. After consent is completed, continue the response using the previous response ID as previous_response_id.

Microsoft documents OAuth identity passthrough as the authentication method for preserving each user's identity and permissions when accessing an MCP server. Agent Service securely stores the user's credentials and uses them within the context of the agent communicating with the MCP server. Each user is prompted for consent when they first authorize a particular MCP connection, and subsequent calls can use that user's stored credentials.

The resulting flow is:

Teams user → Custom Teams bot → Foundry Responses API with the authenticated user context → Prompt agent → MCP tool using OAuth identity passthrough → user-specific OAuth credentials

Each user must have at least the Foundry Agent Consumer role on the Foundry project, and the user's Microsoft Entra tenant must match the tenant of the Foundry project. Cross-tenant token exchange isn't supported. Microsoft also recommends including offline_access in the OAuth scopes to allow automatic token refresh.

Regarding x-ms-user-identity, Microsoft documents this header for a trusted middle-tier service to provide a stable end-user identifier for session, conversation, and stored-data isolation. It does not replace the caller’s authentication token or grant access to downstream APIs. Using the header also requires the following permission, which is not included in any built-in role:

Microsoft.CognitiveServices/accounts/AIServices/agents/endpoints/UserIdentityImpersonation/action

Therefore, x-ms-user-identity should not be treated as the mechanism for selecting the user's MCP OAuth credentials in this prompt-agent scenario.

References :

• Set up authentication for MCP tools in Microsoft Foundry
• Configure and share your Microsoft Foundry agent
• Isolate hosted agent sessions per user

Hi @Teodora

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!

Hi @Teodora

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thank You!

Hi @Sai Kiran Mudavath , thank you for the detailed response.

We are attempting to do something similar with a Foundry hosted agent, a customer managed CosmosDB and a VNet injected Foundry Account.

Here is the full flow:
Teams user → Custom Teams bot → Foundry Responses API with the authenticated user context → Hosted agent → Search tool using OAuth identity passthrough → user-specific OAuth credentials

Is it possible to have user credential passthrough for any tool in this way? How can we configure these connections to use credential passthrough when we are configuring them via code instead of the Prompt Agent UI? We are also curious if user credentials can be passed through for A2A flows for access control / auditing.

Thank you!
James

Hi @Sterling, James (CW) ,

Thank you for clarifying the hosted-agent scenario.

For a Microsoft Foundry hosted agent, the documented and recommended managed approach for per-user tool authorization is to connect the tool through a Foundry toolbox and configure authentication on the referenced project connection.

The expected flow is:

Teams user → Custom Teams bot → Foundry hosted agent → Foundry toolbox → Downstream tool or service

The hosted agent authenticates to the toolbox endpoint using its Microsoft Entra agent identity and the https://ai.azure.com/.default scope. The authentication configuration of each toolbox connection then determines which identity or credential is presented to the downstream service.

For tools that must preserve each signed-in user’s permissions, configure a supported connection with OAuth identity passthrough. Foundry then manages the per-user token exchange, consent, refresh, and credential isolation. Downstream OAuth tokens or API keys should not be stored or injected directly into the hosted-agent code.

However, OAuth identity passthrough is not automatically available for every tool implemented directly in hosted-agent code. Support depends on the specific tool, connection type, and downstream service. When configuring the agent through code, add the configured toolbox to the hosted agent using the supported Agent Framework integration.

For the customer-managed Cosmos DB scenario, choose the identity model based on the required authorization boundary:

• If every user should access the same Cosmos DB data, use the agent or managed identity and assign the minimum required Cosmos DB RBAC role.
• If Cosmos DB access must be restricted according to each user’s permissions, route the operation through a supported delegated tool, such as an Entra-protected MCP service configured with OAuth identity passthrough.

VNet injection provides network isolation and connectivity. It does not, by itself, propagate the Teams user’s identity to Cosmos DB or another downstream service.

For auditing, correlate the initiating user identifier with the Foundry trace, session, or operation ID in the application telemetry. Do not log access tokens. When a downstream call uses the agent identity, the downstream service records the agent or workload identity, so application-level correlation is required to associate the operation with the initiating user.

For A2A scenarios, Foundry supports shared authentication and individual user authentication. Configure OAuth identity passthrough on the A2A connection when the target agent must operate within the initiating user’s permissions. Each A2A connection and endpoint must support and be configured for the selected authentication method.

If you can share the specific tool or connection type used to access Cosmos DB, along with the SDK and configuration approach, we can confirm whether OAuth identity passthrough is supported for that implementation.

References:

• Toolbox authentication in Microsoft Foundry
• Use a toolbox with a hosted agent
• Agent2Agent authentication

Thank You!