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