OAuth Identity Passthrough Not Supported for Foundry Agents Published to M365 Copilot

Question

Hello Microsoft Support,

We are encountering a critical limitation when publishing Foundry agents to Microsoft 365 Copilot. Our scenario requires per-user identity enforcement via OAuth identity passthrough (OBO) for MCP Server tool authorization. While this works as expected in the Foundry playground (Responses API protocol), publishing the agent to M365 Copilot switches to the Activity Protocol (Bot Service), which does not forward the user's OAuth token. As a result, the MCP Server receives only the project managed identity, breaking per-user authorization and resulting in a generic error ("Sorry, I wasn't able to respond to that") in Copilot.

The documentation at https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol?pivots=csharp#known-limitations describes this as a known limitation, but it is not clear whether this applies only to Teams or also to M365 Copilot. We require explicit confirmation from Microsoft:

• Is OAuth identity passthrough (OBO) supported for Foundry agents published to M365 Copilot?
• If not, is there a roadmap or recommended workaround for enabling per-user identity propagation in this scenario?
• Is this limitation documented anywhere specific to M365 Copilot, or only for Teams?

This limitation is blocking our deployment, as our MCP Server enforces role-based authorization per user and cannot operate with a generic project identity.

Thank you for your assistance and clarification.

Answer 1

OAuth identity passthrough (OBO) for MCP tools is only supported when invoking agents via the Responses protocol with OAuth identity passthrough configured on the MCP server connection. When an agent is published as an Agent Application to Microsoft 365 Copilot or Teams, it uses the Activity Protocol through Azure Bot Service with Channels authentication, not the Responses protocol with OAuth passthrough.

In this published M365/Teams scenario, the inbound authentication to the Agent Application is handled by Bot Service channels, and the documentation only describes two options for application invocation:

1. Default (RBAC) – for direct invocation via the Responses protocol using Azure RBAC.
2. Channels (Azure Bot Service) – automatically selected when publishing to M365/Teams.

There is no documented support for forwarding the end-user’s OAuth token (OBO) from M365 Copilot/Teams through the Activity Protocol into the MCP server. As a result, MCP tools invoked from a published agent in M365/Teams will not receive per-user OAuth tokens and instead operate under the application/agent identity (for example, project or agent managed identity), which matches the behavior described in the question.

The available documentation in the provided context does not expose:

• Any mechanism to enable OAuth identity passthrough for agents published to Microsoft 365 Copilot via Activity Protocol.
• Any roadmap commitment or preview feature to support per-user identity propagation (OBO) from M365 Copilot/Teams to MCP servers.
• Any M365-Copilot-specific page that documents this limitation separately from the general MCP or Teams guidance.

Given the constraints in the context, the only supported patterns are:

• Use Responses protocol + OAuth identity passthrough for scenarios that require per-user OAuth tokens to MCP servers (for example, when calling the agent via the OpenAI-compatible /responses endpoint and not via M365/Teams).
• Use Channels (Azure Bot Service) when publishing to M365/Teams, accepting that per-user OAuth tokens are not forwarded to MCP tools and that the agent identity (application/managed identity) is what downstream services see.

No documented workaround in the context enables full per-user OBO propagation from M365 Copilot to MCP servers today. Any per-user authorization would need to be implemented using what the downstream service can infer from the agent/application identity and its own internal logic, rather than from a user OAuth token forwarded by Copilot.

---

References:

• Set up authentication for Model Context Protocol (MCP) tools
• Publish agents to Microsoft 365 Copilot and Microsoft Teams
• Publish and share agents in Microsoft Foundry
• Agent2Agent (A2A) authentication

Answer 2

Hello Cristopher Coronado,

Welcome to Microsoft Q&A and Thanks for reaching out,

When you run your agent inside Azure AI Foundry (playground using the Responses API), the platform supports on-behalf-of (OBO). That’s why your MCP server receives the actual user’s OAuth token and your per-user RBAC works.

When you publish the same agent to Microsoft 365 Copilot, the execution path changes. Copilot uses the Bot Framework Activity protocol, and in that pipeline:

• The user’s OAuth token is not forwarded
• The call to your tool (MCP server) is made using the project’s managed identity
• So from your backend’s perspective, every request looks like it’s coming from a single app identity instead of individual users

That difference in protocol is the root cause of the behavior you’re seeing. Answers to your questions

Is OAuth identity passthrough (OBO) supported in M365 Copilot?

No, today OBO is only supported in Responses API–based flows (like the Foundry playground).

Once you move to Copilot (or any Bot Framework–based channel), the system switches to managed identity and drops the user token.

Does this limitation apply only to Teams?

No, it’s not Teams-specific.

Even though the documentation calls out Teams, the limitation is tied to the Activity protocol itself, not the surface. That means it applies to:

• Teams
• M365 Copilot
• Any channel built on Bot Framework

Is this documented for Copilot?

Right now it’s mentioned under Model Context Protocol → Known limitations, but mostly in the context of Teams.

There isn’t a Copilot-specific note yet, but technically the same constraint applies because Copilot uses the same underlying protocol. So your scenario is fully consistent with the current design.

Is there a roadmap or workaround?

There’s no public ETA yet for bringing OBO into the Activity protocol / Copilot flow.

In terms of workarounds, customers typically go with one of these patterns depending on how strict their authorization model is:

1. Handle identity at the application layer

Instead of relying on OBO, pass user context (like user ID, email, or claims) from the agent and enforce RBAC inside your MCP server.

This isn’t as strong as token-based delegation, but it works if you control both ends and can validate the context properly.

2. Implement a custom token exchange

Some teams pass a short-lived token or identity hint in the request (for example via activity payload), then:

• Validate it in a backend service
• Exchange it for a real access token
• Call the MCP server with that token

This gives you back a per-user model, but requires extra plumbing.

3. Introduce a middleware layer

Place a custom service or bot endpoint between Copilot and your MCP server that:

• Intercepts the request
• Resolves the user identity
• Injects a usable token before forwarding

This is closer to OBO behavior, but adds complexity.

4. Stay on Responses API for strict OBO scenarios

If your requirement is true per-user OAuth enforcement with no compromise, then today the only place that fully supports it is the Responses API path (Foundry playground / direct integration).

Your setup is working as designed in the playground

The break happens only after moving to Copilot because of the protocol switch

OBO is not supported yet in that channel

And there’s no native way today to propagate user identity end-to-end in Copilot tool calls.

Please refer this

• Model-Context Protocol Known Limitations https://learn.microsoft.com/azure/foundry/agents/how-to/tools/model-context-protocol?pivots=csharp#known-limitations

• Agent2Agent (A2A) Authentication / OAuth Identity Passthrough https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication#oauth-identity-passthrough

• Agents Self Help (enterprise-deployment checklist) https://learn.microsoft.com/azure/ai-foundry/agents/faq

I Hope this helps. Do let me know if you have any further queries.

---

If this answers your query, please do click Accept Answer and Yes for was this answer helpful.

Thank you!