Series: Governing AI Agents in Microsoft 365 — Part 3 of 5. This post covers Microsoft Agent 365 — a central governance and management layer for the agent estate. Part 2 covers Microsoft Purview.
Microsoft Agent 365 went generally available on 1 May 2026. It's already generating confusion — partly because the name suggests it might be an agent builder or a new Copilot experience, and partly because it overlaps in description with capabilities that already existed across the Microsoft 365 admin centre, Purview, and Entra.
Microsoft Agent 365 isn't an agent builder or runtime. It is a central governance and management layer for observing, governing, and securing agents across the organisation. Understanding where it fits, and where it doesn't, is the foundation for using it effectively.
The Three-Plane Mental Model
Without a central governance layer, organisations often end up managing agents through disconnected admin experiences with limited estate-wide visibility. A useful way to think about this is through a three-plane model — this is an architecture abstraction, not official Microsoft terminology, but it helps clarify where Agent 365 sits relative to the other products in the ecosystem:
Build
Where agents are authored. This is Microsoft Copilot Studio, Microsoft 365 declarative and custom agents, and Microsoft Foundry Agent Service. Nothing about Agent 365 changes how agents are built or where they run.
Run
Where agents execute. Microsoft 365 surfaces (Copilot Chat, Teams, Outlook, SharePoint) and runtimes such as Foundry Agent Service. Again, Agent 365 doesn't change this.
Govern
Where IT and security manage the agent estate. This is where Agent 365 sits, alongside the Copilot Control System.
The practical implication: Agent 365 is not a replacement for Copilot Studio and it doesn't change the runtime behaviour of agents. If an agent is built in Copilot Studio, Copilot Studio remains the builder, the runtime, and the consumption billing engine. What Agent 365 adds is the governance and observability layer over the top of that.
What Agent 365 Actually Provides
Microsoft organises Agent 365 capabilities around three pillars. As the Microsoft Learn documentation puts it, organisations can move from agent experimentation to enterprise-scale operations through: Observe, Govern, and Secure.
Observe
"Observe is the first step as you can't control what you can't see."
Agent 365 provides a complete view of all agents in your organisation, including their activity, usage patterns, connections, and impact. This covers:
- A tenant-wide inventory of agents, with visibility into ownership, activity, and governance metadata — including Microsoft-built agents, manually registered agents, and supported ecosystem integrations. This addresses a gap the Power Platform admin centre's agent inventory doesn't fully close
- Measuring agent effectiveness — tracking adoption, quality, performance, speed of task completion, and business impact to support more informed decisions about which agents are delivering value and which aren't
- Visualising the agent ecosystem — how agents connect with other agents and perform over time, which simplifies monitoring and helps identify issues before they escalate
- Role-specific oversight surfaces for AI administrators, security leaders, and business leaders — agent oversight shouldn't be the exclusive domain of IT, and the different views reflect that
- Ownerless agent identification — one of the more practically useful signals, flagging agents that have lost their accountable owner before they become a governance liability
Govern
Govern establishes guardrails for agents and users. It supports onboarding agents with IT oversight and governing agent access to resources and data. In practice this covers:
- Onboarding and approving agents through an IT-controlled flow, applying policy templates to every agent for governance and compliance from day one
- Agent identity capabilities via Entra Agent ID, which introduces dedicated identity constructs that support clearer ownership, accountability, and execution models. An agent identity can have a named sponsor for human accountability, supporting both user-delegated and autonomous execution patterns
- Least-privilege access controls — enforcing which users, data, and tools agents can use, and limiting access to only the resources they need
- Automated lifecycle governance — rules-based agent management that can automatically enforce lifecycle policies, such as expiring inactive agents, flagging ownerless agents, or blocking risky agents. This is a meaningful development: some of what previously required manual process decisions is increasingly automatable through the tooling
- Built-in audit trail support — traceability of who approved an agent, what it accessed, and how it behaved, supporting compliance and investigation requirements
- Agent governance capabilities are increasingly incorporating controls around external tools, MCP integrations, and governed access to enterprise data sources — the direction of travel mirrors the DLP connector model from Part 1
The automated lifecycle capabilities are worth pausing on. When this series was first drafted, flagging ownerless agents and retiring inactive ones were described as process decisions requiring human governance frameworks. The tooling is closing that gap — but the policy decisions that drive the automation (what counts as inactive, what triggers a flag, who reviews a blocked agent) still require organisational definition. Part 4 covers that process layer.
Secure
"Securing agents just as any other asset in your environment is critical."
Agent 365 integrates with enterprise security solutions to protect agents regardless of where they were built or acquired:
- Entra for agent identity protection and risk-based access control
- Purview for information protection, DLP, and preventing data oversharing
- Defender for threat detection and security monitoring against threats and vulnerabilities
The security coverage applies across the organisation's agent estate — not just agents built in Copilot Studio, but agents acquired or built on other platforms too.
Agent 365 vs. the Copilot Control System
These two are frequently confused and worth distinguishing clearly.
The Copilot Control System (CCS) is Microsoft's broader governance framework around Copilot and agent management capabilities. It spans security and governance, management controls, and measurement and reporting for Microsoft 365 Copilot, Copilot Chat, Microsoft 365 prebuilt agents, and Copilot Studio agents published to Microsoft 365 channels. It's a framework, not a product you buy.
Microsoft Agent 365 is a specific product — a SKU with a price — that provides a central governance and management layer for the agent fleet. It gives you the centralised registry, lifecycle management, agent identity, and role-specific oversight described above.
The practical distinction: CCS is Microsoft's broader governance framework for Copilot and agent management. Agent 365 is the specific product that extends and formalises that governance for organisations that need it.
What Changes and What Doesn't When You Add Agent 365
What changes
Your organisation gets a centralised governance layer with a unified agent registry, lifecycle management, and role-specific oversight. The security and governance posture around agents becomes more explicit — agent identity, least privilege boundaries, DLP, and threat detection are all documented and managed with greater consolidation.
What doesn't change
Agents are still built and run where they were built and run. Copilot Studio remains the builder, runtime, and billing engine for Copilot Studio agents. Foundry remains the runtime for Foundry agents. The agent objects themselves don't change.
Runtime consumption mechanics remain in place. Copilot Studio still uses its message-based billing model. Agent 365 doesn't affect how agent interactions are metered or billed.
Base data access rules don't become looser. Access remains bounded by Entra, Purview, and least-privilege controls. Agent 365 doesn't let agents or users bypass those controls.
The value proposition is consolidation: a tenant-wide view of the agent estate across surfaces that would otherwise require navigating Power Platform admin centre, Purview, Entra, and Defender independently. If your organisation already has strong governance practices across those surfaces, Agent 365 reduces the operational overhead of maintaining them in parallel.
Agent 365 licensing is user-based rather than agent-based — for full details see the Microsoft Copilot Studio licensing documentation.
A Note on the Mixed-Licence Scenario
There is one scenario where public guidance remains limited: what happens when a shared agent is used by a mix of users with and without Agent 365 licences.
The agent itself doesn't change — Agent 365 is the governance layer around the agent, not the agent object. Whether a user can invoke the agent depends on their underlying Copilot or Copilot Chat licence, not on Agent 365. But the exact scope of what Agent 365 telemetry and observability shows for mixed-user scenarios — which interactions are visible, to what granularity — is an area where public documentation remains limited.
This is worth being direct about rather than assuming the answer.
What's Currently Available and What's Still Evolving
Current generally available capabilities are centred around the core governance layer: centralised registry, agent identity via Entra Agent ID, lifecycle management, security integration with Purview and Defender, and role-specific oversight.
Still evolving: observability and governance for agents operating autonomously with their own credentials, discovery of shadow AI via Defender and Intune for local and cloud agents, and expanded SaaS ecosystem coverage. The identity architecture for fully autonomous agents is visible in Entra Agent ID documentation, but the full governance story for independently credentialed agents continues to develop.
Where Agent 365 Sits in the Governance Series
Agent 365 provides the central governance layer, and that layer is maturing quickly. Capabilities that were absent at launch — automated lifecycle enforcement, ownerless agent detection, rules-based expiry — are now part of the product. The process governance gap described in Part 4 of this series is narrowing as the tooling catches up.
What the tooling doesn't replace is the policy layer: the organisational decisions about what counts as inactive, what triggers a review, who approves an agent, and what the accountability framework looks like. Agent 365 can automate the enforcement once those decisions are made. It can't make them for you. That's the territory Part 4 covers.