Microsoft Foundry agent works in the playground but is silent in Teams

Question

Microsoft Foundry agent works in the playground but is silent in Teams

Viktoriia 20 Microsoft Employee

I'm trying to publish a Microsoft Foundry agent to Microsoft Teams in another tenant using the built-in Publish -> "Teams and Microsoft 365 Copilot" feature. The publishing process fails with an HTTP 400 error: "Underlying error while obtaining user token". However, the Azure Bot with Teams channel is still created. I manually installed the app into Teams in another tenant, but the bot never responds to any messages.
Auto-created resources (created by Foundry)

Azure Bot - msaAppType: SingleTenant, msaAppId = the agent's instance identity.
The blueprint app registration contains a federated identity credential trusting the agent identity.
Blueprint app registration and Agent identity both have the Foundry User role.
Agent endpoint supports: protocols: [activity, responses]
authorization_schemes: [Entra, BotServiceRbac]

What works
The agent works correctly in the Foundry Playground.
All tools and model calls work as expected.
No firewall or Private Link restrictions.

What doesn't work
In Teams, the bot is completely silent, no response and no visible error.
No new run appears in Foundry Traces after sending a message from Teams, which makes me think the request is being rejected before it reaches the agent.
The Publish to Teams flow consistently fails with HTTP 400: "Underlying error while obtaining user token", which appears to be a token exchange failure.

I'm particularly wondering:
Is cross-tenant sideloading expected to work for a SingleTenant bot created by Foundry, or is it unsupported?
Are there additional Entra ID or Teams permissions steps that the Foundry publishing flow does not configure automatically? Is there a way to enable more detailed diagnostics for the token exchange or Teams and Foundry authentication flow?
Any suggestions or guidance would be greatly appreciated.

0 comments

Answer accepted by question author

Thanmayi Godithi 11,905 Microsoft External Staff Moderator

Hi Viktoriia,

Both things you're seeing — the publish-time HTTP 400 "obtaining user token" and the silent bot with no Foundry trace — come from a single root cause: the Foundry publish flow provisions a SingleTenant Azure Bot whose MicrosoftAppTenantId is your home tenant, and a SingleTenant bot's token validation is bound to that one tenant.

Why it's silent in Teams: a message from the other tenant arrives with a token issued by that tenant. The bot's auth layer validates the JWT issuer/audience against its home tenant, so the activity is rejected before it reaches your agent endpoint — which is exactly why no new run shows up in Foundry Traces and you see no error.
Why publish 400s: the publish pipeline's user-token exchange is operating against the home-tenant SingleTenant identity while you're targeting a different tenant, so obtaining the user token fails. The Bot/channel resources still get created (that's just ARM), but the cross-tenant auth wiring never gets established.

So, to answer your questions directly:

Cross-tenant sideloading of a Foundry-created SingleTenant bot isn't a supported scenario. The one-click Publish-to-Teams flow assumes the agent, project, Azure Bot, and Teams usage all live in the same tenant (the publish scopes "Just you" / "People in your organization" are tenant-scoped). There's no documented cross-tenant distribution path. It's also worth noting new multi-tenant bot creation was deprecated after July 31, 2025, which is why the flow builds SingleTenant bots and why cross-tenant is genuinely hard here.
Extra steps exist but are manual, partial, and unsupported. The only real levers are at the app-registration level (not the bot's msaAppType): set Supported account types → "Accounts in any organizational directory," grant admin consent in the target tenant via the adminconsent URL (client_id=bot app id, redirect_uri=https://token.botframework.com/.auth/web/redirect), and sideload/approve the Teams app in that tenant. A closely matching community case got cross-tenant working this way — but their final fix required correct CloudAdapter initialization in their own bot code, which the Foundry-hosted relay abstracts away from you. So steps above are worth trying, but the hosted relay may still not validate cross-tenant tokens.
Diagnostics are limited: enable Application Insights on the Azure Bot and look for inbound Teams activities and 401/Unauthorized at the auth layer. If you see no inbound activity at all, that confirms the rejection is happening at the token/channel layer (matching the missing Foundry trace). Detailed token-exchange diagnostics beyond that are a known gap today.

My recommendation: if the agent needs to serve users in another org, the supported approach is to provision the Foundry project + agent + Azure Bot in that tenant (same-tenant publish), rather than cross-tenant sideloading the home-tenant bot. If cross-tenant is a hard requirement, treat the app-registration + admin-consent steps as best-effort and validate via App Insights — but as of today, first-class cross-tenant distribution of a Foundry agent to Teams isn't a shipped capability.

Kindly let us know if the above helps or you need further assistance on this issue.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-07-09T15:18:31.5433333+00:00

Hi Viktoriia ,

If the answer is helpful, please click "Accept Answer" and kindly upvote it as it would help others in the community.

1 additional answer

Your answer

Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-07-09T15:18:31.5433333+00:00

Hi Viktoriia ,

If the answer is helpful, please click "Accept Answer" and kindly upvote it as it would help others in the community.

Answer 1

Cross-tenant sideloading of a SingleTenant bot created by Foundry is not covered or enabled by the documented Foundry publishing flows. The documented guidance and troubleshooting assume publishing and usage within the same Microsoft 365 tenant.

From the available documentation:

Supported publish model and scopes
- The standard flow is: Foundry agent → Publish to Teams and Microsoft 365 Copilot → Azure Bot Service resource → Teams/M365 in the same tenant.
- When using Direct publish, the supported scopes are:
  - Just you: available immediately for the publisher; appears under Your agents in the agent store, no admin approval required.
  - People in your organization: submitted for admin approval; once approved, appears under Built by your org for all users in the tenant.
- These scopes are explicitly tenant-scoped; there is no documented cross-tenant distribution path for a SingleTenant bot created by Foundry.
What the Foundry publish flow configures
- The publish flow automatically creates or uses an Azure Bot Service resource and configures the agent with the Activity protocol and BotService/BotServiceRbac authorization schemes for Teams/M365 channel traffic.
- Prerequisites include:
  - Foundry RBAC roles (such as Foundry User) on the project.
  - Permission and provider registration to create Azure Bot Service (Microsoft.BotService).
- For virtual-network scenarios, the documented steps show that the publish flow (or its API equivalent) assumes the same-tenant environment and then relies on network/firewall configuration, not cross-tenant auth changes.
Behavior when publishing fails / agent is silent
- Documented troubleshooting focuses on:
  - Invalid metadata or version, missing agent identity, or Bot Service creation permission issues.
  - Admin approval pending for organization-scope agents.
  - Agent identity missing RBAC permissions to downstream Azure resources.
- For agents published to M365/Teams, if messages never reach the agent, the guidance is to check:
  - That the agent appears in the store under the expected scope (Your agents or Built by your org).
  - That the channel adapter can reach the agent (DNS, firewall, TLS).
  - That token validation and BotService/BotServiceRbac configuration are correct.
- There is no documented path for cross-tenant token exchange or diagnostics for a SingleTenant bot; the flows and troubleshooting are framed around same-tenant routing and Entra/Bot Service auth.
Diagnostics and limitations
- For standard (same-tenant) publishing, diagnostics are primarily:
  - Foundry portal publish errors (for example, identity or provider issues).
  - Microsoft 365 admin center for approval and visibility of organization-scope agents.
  - Network-level checks (DNS, DNAT, TLS, outbound access) and JWT validation configuration when using the API-based publish flow.
- Documented limitations for published agents include:
  - No streaming or citations.
  - Private Link not supported for Teams or Azure Bot Service integrations.
- There is no documented mechanism to enable additional, fine-grained diagnostics specifically for cross-tenant token exchange between Teams and a Foundry-created SingleTenant bot.

Given the documentation, the supported and tested scenario is publishing and using the Foundry agent in the same tenant (either personal scope or organization scope after admin approval). Cross-tenant sideloading of a SingleTenant bot and the associated token exchange behavior are not described as supported scenarios, and there are no additional Entra ID or Teams configuration steps documented to make that work.

For a production scenario, the recommended path is to align with the documented publish scopes ("Just you" or "People in your organization") and keep the Teams usage in the same tenant where the Foundry project, agent, and Azure Bot Service resource are provisioned.

References: