When Microsoft shipped Agent Framework 1.0 in April 2026 and the Agent Governance Toolkit the week after, the missing piece was the operations layer — a single place where IT could see every agent deployed in the enterprise, enforce policy, and tie each one to a verified identity. That gap closed on May 1, 2026, when Microsoft Agent 365 reached general availability.
This guide explains what Agent 365 does, how it fits into the Copilot Wave 3 architecture, what developers can build on top of it, and what the Entra Agent ID blueprint model looks like in practice.
Why Agent 365 Exists
Enterprise AI adoption has created an agent sprawl problem. Teams build agents in Copilot Studio, Microsoft Foundry, Azure AI Foundry, LangChain, or third-party platforms. IT has no inventory. Security has no policy hooks. Compliance has no audit trail. Each agent runs with whatever permissions it was given at build time.
Agent 365 is Microsoft's answer to that problem: a governance control plane that sits above every agent, regardless of which tool created it or which cloud runs it. The key design principle is separation of concerns:
- Build layer (Copilot Studio, Microsoft Foundry, Agent Builder, custom frameworks): where developers create agents.
- Govern layer (Agent 365): where IT registers, policies, and monitors them.
Developers still write agent logic. Agent 365 is what IT uses to decide whether that agent is allowed to run, what it can access, and how it identifies itself to downstream services.
What Went GA on May 1, 2026
The Agent 365 GA release included four main capabilities:
Agent Registry — a central inventory of all agents in the tenant. Agents built in Copilot Studio and Microsoft Foundry sync automatically. Third-party agents can be registered via the admin center API. The registry surfaces metadata: agent name, build platform, assigned identity, permission scope, and last-seen timestamp.
Entra Agent ID — every registered agent gets an identity backed by Microsoft Entra. This is separate from user identities and separate from the standard app registration model. Each agent identity traces back to a blueprint (more on this below).
Local agent management on Windows — Defender and Intune can now surface unmanaged local agents running on Windows endpoints and block them. At GA, the enforcement coverage includes agents running on the OpenClaw platform across Windows. This is relevant for developers distributing desktop AI tools internally.
Multicloud registry sync (public preview) — Agent 365 can discover and import agents running on AWS Bedrock and Google Cloud Gemini Enterprise into the same registry. Once synced, admins can perform basic lifecycle operations (start, stop, delete) and apply governance policies across providers.
Copilot Wave 3: The Architecture Agent 365 Governs
Agent 365 doesn't exist in isolation. It's the management plane for Copilot Wave 3, Microsoft's March 2026 expansion of Microsoft 365 Copilot from a chat assistant into an autonomous agent platform.
Wave 3 introduced two architectural shifts that matter for developers:
Trigger-based execution. Wave 3 agents don't wait for a user prompt. They monitor conditions — a new email matching a filter, a calendar event starting, a file landing in SharePoint — and execute multi-step workflows autonomously. This is what Microsoft calls "agents that execute, not just assist."
Copilot Cowork. Wave 3 shipped a Claude integration built in collaboration with Anthropic, allowing Copilot to orchestrate long-running tasks that operate in the background. From an Agent 365 perspective, Cowork tasks are governed agents: they have Entra identities, they appear in the registry, and they're subject to the same policy rules as custom agents.
Agent 365 is what keeps all of this auditable. Every Wave 3 workflow that touches M365 data generates an audit trail tied to an agent identity — not a generic service principal, but a specific blueprint-derived identity with full lineage.
Entra Agent ID: Blueprints, Identities, and Tokens
The identity model in Agent 365 is the part developers are most likely to interact with when building agents that need to act on behalf of users or access M365 data.
Agent Identity Blueprints
A blueprint is an Entra ID object that serves as a template for creating agent identities. Think of it as a class definition: the blueprint holds the credentials, OAuth permission grants, and configuration; individual agent instances are the objects created from that class.
Key properties of a blueprint:
- Credentials: how the agent authenticates to Entra (federated identity credentials using managed identities are recommended for production — no credential rotation needed).
-
OAuth permissions: permissions granted to the blueprint apply to all agent identities derived from it. If the blueprint has
Mail.Read, every agent created from it inheritsMail.Read. - Audit binding: every action taken by any agent identity traces back to the blueprint principal in the Entra audit log.
Creating a blueprint through the Microsoft admin center or via the Entra API registers an agentIdentityBlueprint object. From that point, the registered agent appears in the Agent 365 registry with a verified identity.
Token Flow
When an agent needs to call a downstream API, the blueprint credentials are used to request an access token from Entra:
Blueprint credentials → POST /oauth2/v2.0/token
→ Access token issued
→ token.oid = blueprint principal object ID
The oid claim in the token points to the blueprint principal, so any call made with that token is attributable to the specific agent blueprint — not to a generic application registration.
For user-delegated scenarios, agents use the On-Behalf-Of (OBO) flow. The user authenticates to the agent, the agent exchanges that token for a new one via OBO, and downstream calls run under the user's identity while the agent identity remains visible in the audit trail:
User authenticates → Agent receives user token
Agent calls /oauth2/v2.0/token with:
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
requested_token_use=on_behalf_of
assertion=<user_token>
→ New token issued with user identity + agent blueprint lineage
This pattern is what Microsoft calls the OBO control plane, and it reached GA on May 1. It maps onto existing enterprise IAM patterns (delegated access) and is the recommended path for agents that need to read user mailboxes, calendars, or SharePoint content.
Agentic user mode — where agents acquire tokens as fully autonomous service identities without any user delegation — remains in Frontier preview. It's a harder governance problem (how do you audit an autonomous agent that acts independently of any human request?) and Microsoft is keeping it behind a controlled access gate for now.
Copilot APIs: What Developers Can Call
Agents that are registered in Agent 365 and have an Entra identity can call the Microsoft 365 Copilot APIs. These are REST APIs under the Microsoft Graph namespace:
https://graph.microsoft.com/v1.0/copilot/...
https://graph.microsoft.com/beta/copilot/...
Authentication uses the same MSAL-based flow as all Graph APIs. Delegated permissions (OBO) or application permissions, depending on whether the agent acts on behalf of a user or as a service.
The Copilot APIs provide access to:
- User context and work signals (Work IQ) — organizational graph, collaboration patterns, document relevance scoring.
- Agent-to-Copilot surface — registered agents can be surfaced inside the Copilot chat experience across M365 applications, so end users can invoke custom agents from within Teams, Outlook, or Word.
- Policy settings — the Copilot Policy Settings API (preview) reads and updates Copilot governance settings across Cloud Policy Service and Intune, useful for agents that need to adjust their own policy scope or report compliance status.
The full API reference lives at learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/copilot-apis-overview.
Deploying a Foundry Agent to Agent 365
The most documented path from code to governed agent today runs through Microsoft Foundry. The flow is:
- Build the agent in Foundry — define tools, model selection, system prompt, and tool permissions.
- Push as an AI teammate — from the Foundry portal, submit the agent to Agent 365 as a "teammate" object.
- IT approves in admin center — the agent appears in the Agent 365 registry with a draft status. An admin reviews permissions and approves deployment.
- Hire by end users — once approved, users can "hire" the agent from the Copilot interface. The agent runs under its blueprint-derived identity, with all actions audit-logged.
Microsoft publishes a sample repository (microsoft/FoundryA365) that walks through this with Azure Developer CLI (azd) commands. The repository covers sign-in, resource creation, agent registration, and the approval workflow.
For agents built outside Foundry (LangChain, custom FastAPI services, etc.), registration is done via the Agent Registry API in the admin center. You supply the agent's metadata and request an Entra agent identity — the blueprint is created on the tenant's behalf. Third-party agents don't get the Foundry-style auto-sync; registration is manual or CI-driven via API.
Multicloud Governance
The multicloud registry sync feature addresses a real enterprise pain point: most large organizations run AI workloads on at least two clouds. Agent 365's sync with AWS Bedrock and Google Cloud Gemini Enterprise (both in public preview at GA) works through Arc-enabled connectors:
- Install a lightweight Arc agent on AWS EC2, Google Cloud VMs, or on-premises Kubernetes clusters.
- The Arc agent discovers running AI agents and projects them into the Agent 365 registry.
- Once in the registry, standard Agent 365 governance applies: policy rules, lifecycle operations, audit logging.
Discovered third-party agents don't get Entra identities automatically — that step still requires a manual registration. But the inventory and lifecycle management (start/stop/delete) works across providers, which is the first step toward CISO-level visibility into the full agent estate.
Pricing and Licensing
| Option | What's included | Price/user/month |
|---|---|---|
| Agent 365 standalone | Agent registry, Entra Agent ID, governance policies | $15 |
| Microsoft 365 E5 + Copilot | E5 productivity + Copilot chat | ~$57 + $30 = ~$87 |
| Microsoft 365 E7 Frontier Suite | E5 + Copilot + Agent 365 + Entra Suite | $99 (vs ~$105 à la carte) |
For teams that already pay for E5 and Copilot and are adding Agent 365, the standalone $15/user is the relevant number. The E7 bundle makes economic sense if you're also procuring Entra Suite separately — the $6/user/month saving isn't dramatic, but the single contract is.
Microsoft hasn't published a detailed consumption model for agent usage beyond the base license, except that the first 10,000 managed agents per tenant are included with no per-agent charge.
Common Mistakes
Registering agents before scoping permissions. Blueprint permissions propagate to all agent identities derived from that blueprint. Over-permissioning a blueprint early means every agent created from it inherits more access than it needs. Scope permissions tightly at blueprint creation; you can always expand later.
Expecting Foundry-style auto-sync for custom agents. Only Foundry and Copilot Studio agents sync automatically. Custom agents (LangChain, FastAPI, any non-Microsoft framework) require manual or API-driven registration. Build this into your CI/CD pipeline if you're deploying frequently.
Conflating Agent 365 with the Agent Governance Toolkit. These are different products. The Agent Governance Toolkit is an open-source library developers embed in their agent code for runtime policy enforcement. Agent 365 is the IT management plane above that. They complement each other; neither replaces the other.
Assuming agentic user mode is available. The fully autonomous service-principal mode for agents (not delegated from a user) is still in Frontier preview. If your design requires agents that act without any user context, plan for this to remain restricted for the near term.
FAQ
Q: Does Agent 365 work with agents not built on Microsoft tools?
Yes. Third-party agents — OpenAI Assistants, Anthropic Claude deployments, LangChain agents, ServiceNow AI agents — can be registered in the Agent 365 registry via the admin center API. Once registered, they get an Entra identity and appear in the governance dashboard. The multicloud sync for AWS Bedrock and Google Cloud (public preview) extends discovery to agents running outside Azure.
Q: What's the difference between an agent identity blueprint and a standard app registration?
App registrations are for applications (web apps, APIs, background services). Agent identity blueprints are specifically designed for AI agents: they carry semantics about agent lineage (which blueprint created which identity), they propagate OAuth grants to derived identities in bulk, and they generate audit log entries that distinguish agent actions from user and application actions. The token oid claim behavior is different — it points to the blueprint principal, not an application object.
Q: Is Wave 3 Copilot the same as Agent 365?
No. Copilot Wave 3 describes the capability expansion in Microsoft 365 Copilot (trigger-based workflows, autonomous tasks, Cowork with Claude). Agent 365 is the management infrastructure that governs those capabilities and any other agent in the tenant. Copilot Wave 3 features appear in Agent 365's registry like any other governed agent.
Q: Can developers test Agent 365 without a paid license?
A full Agent 365 tenant requires a license. Microsoft's developer sandbox (available to Microsoft 365 developer program members) gives access to an M365 E5 tenant, but Agent 365 is not included in the free developer tier as of GA. Testing requires either a standalone $15/user license or an E7 trial.
Q: When will agentic user mode (fully autonomous service identity) reach GA?
Microsoft has not published a date. At GA on May 1, the OBO control plane (delegated agent access) reached GA; agentic user mode for fully autonomous service principals remains in Frontier preview. The deliberate phasing reflects the harder governance and audit questions around agents that act without user delegation.
Key Takeaways
Agent 365 flips the enterprise AI agent problem from "how do we build agents" to "how do we govern the agents we've already built." The architecture is clear: develop agents in Copilot Studio, Foundry, or any framework; register them with an Entra Agent ID blueprint; let IT govern through the Agent 365 control plane.
For developers, the immediate practical items are:
- Register agents through the admin center API as part of your deployment pipeline.
- Use blueprint-derived Entra identities instead of ad hoc service principals.
- Prefer OBO flows for user-delegated scenarios — they're GA, well-documented, and preserve audit clarity.
- Track the multicloud sync preview if you're deploying on AWS or GCP alongside Azure.
The Frontier preview items (agentic user mode, full developer SDK) are the next wave. When they reach GA, Agent 365 becomes the unified governance layer for every autonomous agent in the enterprise stack, regardless of origin or cloud.
Bottom Line
Agent 365 is the enterprise control plane that was missing when Microsoft shipped Agent Framework 1.0 and the Governance Toolkit. Developers don't build in it — they build for it. Register your agents, scope your blueprints tightly, and use OBO for delegated access. The governance problem is Microsoft's to solve at the platform level; the compliance upside belongs to every team that registers before their IT department asks them to.
Top comments (0)