A fully managed platform in Microsoft Foundry for hosting, scaling, and securing AI agents built with any supported framework or model
Hello Supakrit (Tan) Aphonmaeklong,
Thanks for sharing the detailed broker-pattern implementation this is a well-thought-out and practical solution to a real platform limitation.
1) Broker Pattern vs Native Cross-Tenant Support
Today, the Teams integration generated from Azure AI Foundry (via the manifest package) is strictly single-tenant by design. It assumes that identity, bot registration, and user context all exist within the same tenant boundary. Because of this, cross-tenant personal bot scenarios like your 1:1 helpdesk assistant aren’t natively supported.
That limitation is exactly why you encountered the OAuth loop and /activityprotocol failures when trying to use the out-of-the-box deployment across tenants.
Given that constraint, your broker (middleware) pattern is effectively the de-facto architecture today for enabling cross-tenant communication. By introducing a controlled intermediary layer, you’ve:
- Decoupled identity boundaries
- Taken control of token acquisition and message routing
- Preserved conversation state across systems
- Bypassed the assumptions baked into the default deployment
This isn’t a workaround in a negative sense it’s a forward-compatible integration pattern given current platform gaps.
If your use case allowed channel-based (team scope) bots instead of personal chats, you could deploy the Teams app separately into each tenant and rely on the standard Bot Framework flow. However, that model does not satisfy personal 1:1 chat requirements, which is why your current approach is justified.
No native cross-tenant Foundry - Teams personal chat capability exists today
Your broker pattern is valid, practical, and aligned with how advanced customers are solving this
2) Identity & Access Management
Your current IAM setup is functional, but for production readiness, there are a few important upgrades worth implementing.
Credential Strategy
Move away from client secrets and adopt:
- Certificate-based authentication where possible
- Store credentials securely in Azure Key Vault with strict access policies
This reduces exposure risk and improves rotation practices.
Permission Scoping
Right now, using broad .default scopes works, but it’s not ideal.
Instead Scope your app registration to only required permissions
- Bot Framework (e.g., send/reply capabilities)
- Minimal Microsoft Graph permissions if used
Avoid over-permissioning, especially in multi-tenant scenarios
Conditional Access & Governance
Since this is a cross-tenant integration, tightening access control is important:
Apply Conditional Access policies in Microsoft Entra ID
- Restrict by location/IP
- Enforce stronger controls for sensitive operations
Use Privileged Identity Management (PIM) for any elevated access scenarios
Regularly rotate credentials and audit usage
Token Validation
Your middleware should explicitly validate incoming Bot Framework requests:
- Validate JWT signature, issuer, and audience
- Ensure requests genuinely originate from trusted Bot Framework endpoints
This prevents spoofing and unauthorized message injection—especially important since your API is now exposed as a cross-tenant bridge.
3) Raw REST vs BotBuilder SDK
Your current implementation using raw HTTP calls to the Bot Framework APIs is fully supported and valid. There’s nothing inherently wrong with continuing this approach.
However, from a production engineering perspective, there are trade-offs.
Raw REST
Full control over request/response handling
Lightweight and flexible
But requires you to manually handle:
- Token caching and refresh
- Retry logic
- Activity schema validation
- Error handling consistency
SDK Approach
Using the official Python SDK botbuilder-core gives you:
- Built-in authentication handling
- Automatic token management
- Retry and resiliency mechanisms
- Standardized activity processing
- Easier telemetry integration
Recommendation
- For PoC - your REST approach is perfectly fine
- For production - strongly recommend moving to the SDK to reduce operational overhead and improve maintainability
Please refer this
• Baseline Microsoft Foundry chat reference architecture – https://dotnet.territoriali.olinfo.it/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-chat
• Basic Microsoft Foundry chat reference architecture – https://dotnet.territoriali.olinfo.it/azure/architecture/ai-ml/architecture/basic-microsoft-foundry-chat
• Baseline Foundry chat in a landing zone – https://dotnet.territoriali.olinfo.it/azure/architecture/ai-ml/architecture/baseline-microsoft-foundry-landing-zone
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!