The distinction matters for planning. The updated Microsoft 365 Roadmap entry says Agent 365 is available worldwide in standard multi-tenant tenants and describes a web-based control plane for observing, governing, and securing AI agents across Microsoft 365 and connected platforms. Microsoft’s roadmap definitions say “Launched” means a feature is fully released for applicable customers. In this case, the August 28 status update appears to be the roadmap catching up to a product that Microsoft had already declared generally available nearly four months earlier.
Microsoft Security’s May 1 announcement and the current Microsoft Learn overview both corroborate the timing. They also put firmer boundaries around the product than the sparse roadmap entry does: Agent 365 is aimed at commercial customers, is licensed per user, and requires at least one qualifying Agent 365 license in the tenant to turn on the service. The standalone list price is $15 per user per month with annual commitment, while Microsoft 365 E7 includes Agent 365 at a $99 per-user monthly list price.
A tenant-wide inventory, not an agent runtime
The phrase control plane can make Agent 365 sound like a replacement for Copilot Studio, Microsoft Foundry, or an agent-hosting service. It is not. Microsoft’s own Foundry Control Plane documentation draws a line between the two: Foundry Control Plane is intended for developers and AI engineers who need evaluation, runtime controls, detailed observability, and fleet operations from build through production. Agent 365 is aimed at IT and security teams handling registry, access control, identity governance, lifecycle management, and policies across agents in the tenant.
That means Agent 365 does not supply the model, business logic, workflow orchestration, or hosting environment that makes an agent useful. Microsoft’s developer documentation says those remain the builder’s responsibility, whether the agent is made in Copilot Studio, Foundry, the Microsoft Agent Framework, or another stack. Agent 365 adds an Entra Agent ID, policy-aware tool calls, audit and logging integration, notifications, and management hooks around that agent.
For admins, this is a much more familiar proposition than a new AI-authoring environment. The product is effectively an attempt to apply the controls organizations already use for people, applications, and endpoints to software that can invoke tools and act on data. The operational question is no longer only “Which users can install this Copilot?” It becomes “Which agent owns this action, under which identity, with which access policy, and who is accountable when its creator leaves?”
Microsoft has built the experience into the Microsoft 365 admin center rather than introducing yet another standalone administration portal. Under the Agents area, administrators can see an overview dashboard and a registry of Microsoft-built agents, partner agents, organization-published agents, and agents shared by individual creators. Microsoft Learn describes the registry as a centralized view, but it also exposes a meaningful limitation: agents outside Agent 365 can be listed as unmanaged, without its risk protection and observability.
A registry is valuable, but it is not magical discovery. Visibility depends on agents being known to Microsoft through native integration, registration, or a supported external connection. An agent that never appears in the tenant’s records cannot be brought under governance merely because Agent 365 has been purchased.
The most useful controls are lifecycle controls
The product’s practical value is strongest in agent lifecycle administration rather than abstract “AI governance.” Microsoft’s current getting-started guide documents concrete functions that can help an IT team get control over a fast-growing collection of internal and third-party agents.
Administrators can review agent requests, publish approved agents to specified groups or all users, inspect permissions before publication, and apply a security template during the publishing process. They can also filter the registry by status, publisher type, channel, platform, and data source. That lets an admin distinguish a Microsoft agent from a line-of-business agent developed internally or a partner agent installed through a connected service.
The emphasis on ownerless agents is particularly telling. Microsoft’s guide lets administrators identify agents without a valid owner, review their publisher, platform, status, and last-update details, and take follow-up action. For agents created with Microsoft 365 Copilot Agent Builder, Agent 365 can use a bulk rule to transfer ownership to the former owner’s manager based on the Microsoft Entra ID hierarchy.
That is a necessary administrative feature, but it is narrowly scoped. Microsoft explicitly limits the reassignment rule to agents created with Microsoft 365 Copilot Agent Builder. An organization that has built agents in Foundry, AWS, Google Cloud, Salesforce, Databricks, or a custom framework should not assume that a departed employee’s agents will be automatically reassigned through the same workflow. Those agents need ownership and offboarding procedures that match the platform where they actually run.
Similarly, the currently documented bulk management rules cover installing Microsoft agents and reassigning eligible ownerless Agent Builder agents. The product is not yet a general-purpose engine for automatically retiring every inactive, risky, or unapproved agent across every connected provider. The distinction between inventory and enforcement should shape how organizations write their control requirements.
Third-party visibility arrives with a preview caveat
Microsoft’s stated ambition is wider than Microsoft 365. Its Agent 365 guide identifies Amazon Bedrock and Google Vertex AI as external platforms that can be connected to the Agent Registry. Microsoft Learn now documents registry synchronization for Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, and Databricks Genie.
That capability matters because many enterprises are already building agents outside Microsoft’s own toolchain. A Microsoft 365-only inventory would leave security teams with the same fragmentation problem they had before: one view for Copilot Studio, another for cloud-native agents, another for SaaS automation, and spreadsheets for the rest.
But registry synchronization remains marked preview in Microsoft’s documentation. It requires an administrator to set up a connection using the provider’s credentials and supported APIs. Microsoft also says that future scheduled synchronization is planned for a later release, which means customers should verify how frequently their inventory updates today rather than assume continuous discovery.
There is an additional boundary hidden in the word “synchronize.” Microsoft can import visibility and perform supported management actions through the connected platform’s API, but the external service still owns many enforcement decisions. An AWS Bedrock agent, for example, does not become a Microsoft-hosted agent simply because it appears in the Microsoft 365 admin center. Administrators need to establish which controls are applied in Agent 365, which remain in the originating platform, and which actions require two separate teams.
Microsoft’s developer materials promise support for agents built with third-party and open-source frameworks through the Agent 365 SDK. That is a promising route for organizations standardizing on a Microsoft security layer while retaining development choice. It also imposes work on developers: they must integrate the SDK, implement the observability schema, establish an agent identity and permissions, and use governed tools. An existing agent does not acquire full Agent 365 controls by being added to a registry.
Entra, Defender, and Purview are the real product boundary
Microsoft is packaging Agent 365 as a control plane, but its security claims rely on services customers may already recognize: Microsoft Entra, Microsoft Defender, Microsoft Purview, and, for some device compliance scenarios, Microsoft Intune. Microsoft’s service description spells out how capabilities are distributed.
The Agent Registry is presented through the Microsoft 365 admin center. Entra provides agent identity, identity governance, and Conditional Access controls. Purview is used for functions such as sensitivity-label inheritance, data-loss prevention, compliance assessments, data-security posture management, and insider-risk-related detections. Defender supplies security posture, threat detection, alerts, tool-invocation blocking, and investigation or hunting capabilities using Agent 365 observability logs.
This architecture changes the deployment calculation. Agent 365 is not a substitute for an organization’s security foundation; it is a way to extend that foundation to agents. Microsoft Learn says the product works best with Microsoft 365 E5 as a prerequisite, while the service description divides features across plan tiers. A tenant considering the $15 standalone license should therefore map the precise security outcome it expects—DLP, risky-agent detection, Conditional Access, device compliance, or audit investigation—against its existing Entra, Defender, Purview, and Intune entitlements.
The other operational implication is that access policies must be designed for nonhuman identities. Microsoft says each enabled agent receives an Entra Agent ID and can be given tenant-scoped identity, sponsorship, lifecycle workflows, least-privilege permissions, and risk-based Conditional Access. In practice, that means an agent needs an accountable sponsor, narrowly defined tool access, reviewable data scopes, and a documented shutdown path before it is exposed to users.
What administrators should do with the launched status
The August 28 roadmap update confirms that Agent 365 is no longer a future planning item for applicable worldwide commercial tenants. It does not announce a fresh capability, a new rollout ring, expanded external-platform support, or changed licensing. Organizations that postponed evaluation because Roadmap ID 558448 was previously shown as in development can now treat availability as settled—but should not mistake the status change for proof that every advertised integration or security control is generally available.
A sensible first deployment is to use the registry as an inventory and accountability exercise. Identify who owns each agent, classify whether it is Microsoft-built, partner-built, internally published, or creator-shared, and isolate agents that lack ownership or a clear business purpose. Then pilot publication controls and security templates with a limited group before granting broad access to agents that can send mail, schedule meetings, retrieve SharePoint documents, or call external tools.
Microsoft Agent 365’s real contribution is not that it makes agents autonomous. It gives enterprises a place to decide which agents are allowed to act, what they may touch, and who answers for them when they do. The road map now says that control plane has launched; the harder work is making the tenant’s agent inventory worthy of the controls Microsoft has put around it.