Federated Agent Factory: Microsoft's Reference Architecture for AI Agents Across Entra Tenants
Microsoft's reference architecture for multi-tenant AI agent governance uses a federated agent factory, keeping agent identities and data within business-unit tenants while a governing tenant sets standards and operational views. It specifies runtime enforcement via Azure API Management for pro-code agents and Agent 365/Purview for Copilot Studio agents, with policy-as-code for per-action authorization. Several components remain in preview, including the dedicated AI Gateway tier and multitenant agent management.

Listen to this dispatch
Narrated by an AI-generated voice.
Microsoft has published a reference architecture for operating AI agents across multiple Entra tenants while preserving tenant boundaries. It targets enterprises where subsidiaries run separate tenants, data stores, and regulatory obligations, including cases where those subsidiaries compete.
The architecture introduces a "federated agent factory." A governing tenant owns shared standards, templates, and consolidated operational views, while each business unit maintains its own agent identities, production agents, business data, and runtime policy enforcement. The design rationale is that copying data and agent state into a central tenant would undermine the boundaries the organization intentionally created.
Governance is split by runtime model. Pro-code agents built on Microsoft Foundry are routed through an Azure API Management AI gateway, which serves as the runtime enforcement point: it authenticates callers, enforces token and rate limits, applies content safety, and routes to models. The platform requires each Foundry agent's model and tool endpoints to point to this gateway and blocks direct network egress, so agents cannot bypass it. Agents built in Copilot Studio or Microsoft 365 Copilot run on Microsoft-managed runtime and fall under Agent 365 and Microsoft Purview controls.
For identity, the design uses Microsoft Entra Agent ID, which gives each agent a first-class identity as a specialized service principal without holding credentials itself. These agent identities are tenant-local; a multitenant blueprint creates a matching identity in each business-unit tenant. The design also prescribes narrow, typed tool contracts served through Model Context Protocol (MCP)—capabilities like invoice.lookup or approval.request, versioned and registered in a catalog—rather than broad database access.
There is currently no single Microsoft product for per-action agent authorization. The design compensates by using a declarative policy-as-code engine such as Open Policy Agent running on Azure compute as the policy decision point. Every in-scope sensitive action must pass through a policy enforcement point. Cached decisions expire after a defined time-to-live, and the highest-risk actions always require a fresh decision. Denials generate audit events; requests that cannot obtain an applicable decision fail closed.
Governance extends beyond design-time review. The design describes a stage-gated promotion workflow, evaluation against golden test sets, and shadow-mode runs as a release gate. Production deployments are pinned to immutable artifacts, so rollback is a pointer change. Telemetry is OpenTelemetry-compatible, with tamper-evident audit storage.
Several components remain in preview: Microsoft Entra Tenant Governance, multitenant agent management, and the dedicated AI Gateway tier in Azure API Management. Agent 365 itself is generally available and licensed per user. The capability registry described in the architecture—storing approved specifications, tool contracts, and evaluation evidence—is a platform extension built on Dataverse or SharePoint, not a native Agent 365 feature. That distinction matters when estimating what this stack provides out of the box.
Read the original at techcommunity.microsoft.com →