AI Foundry Agent Authorization Error - Teams Deployment Fails for External Users Despite Correct Azure RBAC Permissions

This scenario matches a permissions/identity mismatch between the project and the published agent, not a requirement for direct project-level UI assignments.

Key points from the documented behavior:

1. Publishing changes the identity
   • During development in the Foundry project, the agent uses the project’s shared agent identity.
   • After publishing (for example, to Teams via Bot Service), the agent uses a distinct Entra agent identity associated with the Agent Application resource, not the project identity.
   • Permissions granted to the project identity do not transfer to the published agent identity.
2. Required action after publishing
   • After publishing, RBAC must be reassigned to the new agent identity on any resources the agent calls.
   • If this step is skipped, tool calls and downstream operations that worked in the playground fail with authorization errors once the agent is invoked from Teams.
3. What the error is really indicating
   • The error message mentions Microsoft.CognitiveServices/accounts/AIServices/agents/write and suggests assigning Azure AI User on the project.
   • In the published scenario, the relevant scope for invocation is the Agent Application resource, which has its own RBAC boundary and identity.
   • The fact that the agent works in the Foundry playground but fails in Teams for everyone except the deployer is consistent with:
     • The deployer having sufficient rights on both the project and the new Agent Application, and/or
     • The published agent identity not having the necessary RBAC on the underlying resources.
4. Why the “Add user” button is greyed out
   • The project is a shared development workspace; publishing is the supported way to separate development from production.
   • The documented model is to control who can invoke the published agent by assigning roles (for example, Azure AI User) on the Agent Application resource, not by adding direct project-level entries.
   • A greyed-out “Add user” button with only inherited access visible is consistent with a design where project-level direct assignments are restricted, while RBAC is expected to be managed at the resource (Agent Application) scope.
5. How to unblock Teams usage Follow these steps aligned with the documented model:
   1. Identify the published Agent Application resource
      • Locate the Agent Application that was created when the agent was published. This is the production resource that fronts the agent version and has its own RBAC scope and Entra agent identity.
   2. Grant users access to invoke the agent
      • On the Agent Application resource, assign an appropriate role (for example, Azure AI User) to the users or groups that must use the agent in Teams.
      • This controls who can call the published agent endpoint, independent of the project.
   3. Grant the published agent identity access to downstream resources
      • Determine which tools/resources the agent calls (for example, storage, Log Analytics, other Azure services via MCP/A2A, etc.).
      • On each target resource, assign the required RBAC roles to the published agent’s Entra agent identity, not the project identity.
      • Common issues documented include:
        • Roles assigned to the wrong identity (project identity instead of published agent identity).
        • Missing role assignments for the agent identity on the target resource.
        • Incorrect audience configuration when using Entra ID–based auth.
   4. Re-test from Teams
      • After RBAC updates propagate, invoke the agent from Teams again.
      • The agent should now be able to:
        • Authorize the calling user via roles on the Agent Application resource.
        • Successfully call downstream tools using the published agent identity.
6. About CLI/API for direct project permissions
   • The documented model emphasizes:
     • Project = shared dev space using a shared identity.
     • Published Agent Application = production resource with its own identity and RBAC scope.
   • The documentation provided focuses on assigning roles via standard Azure RBAC (for example, Azure portal or az role assignment create) at the Agent Application and downstream resource scopes, not on adding direct project-level entries via CLI when the UI is disabled.
   • The supported and recommended way to resolve this scenario is to:
     • Use RBAC on the Agent Application for user invocation permissions.
     • Use RBAC on downstream resources for the published agent identity.
7. Summary for this case
   • This is not resolved by enabling project-level “Add user” in the UI.
   • The effective fix is to:
     • Reassign necessary RBAC roles to the published agent’s Entra identity on all resources it accesses.
     • Assign appropriate roles (for example, Azure AI User) to end users on the Agent Application resource so they can invoke it from Teams.
   • Once those assignments are in place, inherited permissions at the project level no longer block Teams usage, because authorization is enforced at the Agent Application and downstream resource scopes.

References:

• Publish agents to Microsoft 365 Copilot and Microsoft Teams
• Agent identity concepts in Microsoft Foundry
• Publish and share agents in Microsoft Foundry
• Agent2Agent (A2A) authentication