For about a year, “who governs the AI agents in our tenant?” had no first-party answer. That’s over. Microsoft now ships two overlapping answers: the Copilot Control System, a framework of controls for Copilot and agents across the admin centers, and Microsoft Agent 365, a dedicated agent control plane that went generally available on May 1, 2026, licensed per user.
If you run governance for an M365 estate, the right first question isn’t “what should we buy?” It’s “what does the platform now do for us?” The honest answer is: genuinely a lot — and the edges of that coverage are worth knowing precisely, because Microsoft documents most of them itself. Here’s the practitioner map.
What the Copilot Control System covers
The Copilot Control System is a framework, not a product — three pillars of controls that already exist across the Microsoft 365 admin center, the Power Platform admin center, and Copilot Studio:
- Security and governance — data security, AI security, compliance and privacy for what Copilot and agents create or reference.
- Management controls — licensing and metering, agent lifecycle, customization.
- Measurement and reporting — adoption, productivity impact, ROI, via Copilot Analytics.
Concretely, the Microsoft 365 admin center now manages agents through an Agent Registry: shared agents are listed with their name, creator, creation date, host products, and availability status; agents published to the organization go through an admin approval flow; and admins can block agents deemed unsafe or noncompliant. On the Power Platform side, Copilot Studio’s security and governance controls add data policies over knowledge sources, connectors, and triggers, maker audit logs in Purview, environment routing, and a pre-publish security scan for makers.
That is a real governance surface. Two years ago none of it existed.
What Agent 365 adds
Agent 365 organizes its pitch into three verbs: observe, govern, secure. The centerpiece is a unified registry — one view of agent adoption, activity, and health — wired into the identity and security stack: Microsoft Entra for risk-based access control over agents, Purview for information protection and DLP, Defender for runtime threat detection.
The Agent overview in the admin center is where this becomes tangible, and it’s more opinionated than a phone book:
- The registry counts Microsoft-built, partner-built, and line-of-business agents across platforms including Copilot Studio, Agent Builder, SharePoint agents, the Agents Toolkit, and Microsoft Foundry — plus, via registry sync, agents from connected non-Microsoft platforms.
- Four governance cards sit at the top of the dashboard: pending agent requests, agents without owners, agents at risk (aggregated high-severity signals from Entra, Defender, and Purview), and agents with exceptions.
- Rules-based management can “automatically enforce lifecycle policies, such as flagging ownerless agents, or blocking risky agents.”
Microsoft shipping an ownerless agents card and an agents at risk card tells you what it expects to find in real tenants. This is the platform absorbing the inventory-and-identity layer of agent governance — and doing it credibly.
Where it stops — mostly in Microsoft’s own words
None of what follows is a criticism. Most of it comes straight from the documentation, which is commendably honest. It’s simply the part you need to know before you treat the dashboard number as the whole truth.
1. The registry’s coverage is enumerated, not universal. The Agent overview doc states that draft agents are currently only visible from Copilot Studio — “support for draft agents from other platforms, such Agent Builder, Foundry, and SharePoint, aren’t currently available” — and that analytics currently support only Microsoft Foundry V2 agents. The overview card shows the top five platforms, not all of them; the full list lives a click deeper in the Registry tab. And metrics begin accruing when you activate Agent 365 licenses — there is no retroactive view of what your agents did before the meter started. Each caveat is documented. Each is also a blind spot if nobody in your org has read that page.
2. The Azure plane is still its own world. Pro-code agents in Foundry Agent Service live under Azure subscriptions and Azure RBAC, and can be published outward into Microsoft 365, Teams, and the Entra Agent Registry — meaning their reach crosses into the M365 estate even when your governance team’s visibility doesn’t. The registry’s Foundry coverage is real but qualified (see point 1). If nobody has granted your governance process read access to the Azure side, the fleet’s most capable agents are governed by whoever happens to hold subscription RBAC. We’ve written about what that looks like in practice in Your Microsoft 365 tenant has AI agents you can’t see.
3. Existence is not posture. The registry answers what agents exist, who owns them, and which ones are flagged. That’s the identity layer, and it’s necessary. The questions that decide whether an agent would survive an audit live a layer deeper: has its configuration drifted since someone approved it? What tools and connections can it actually call, and what’s the blast radius of that combination? What content is it grounded on, and is that content itself overshared? That last one matters most: an agent inherits the exact state of the estate underneath it — a well-governed agent grounded on an ungoverned site is an ungoverned agent. That story is the whole Governance Debt series, and no agent registry, Microsoft’s or anyone’s, fixes it at the registry layer.
4. The tooling follows the license. Agent 365 is licensed per user, works best with E5 as a base, and is bundled in Microsoft 365 E7 (per the licensing sections of the admin docs). For organizations on that track, this is the sanctioned path and the registry becomes part of your substrate. For the rest of the market — and for MSPs managing fleets of small tenants — the native control plane simply isn’t part of the licensed estate, and the governance question doesn’t go away because the tooling isn’t there.
How to use this, whichever tools you run
Treat the native stack as your substrate, not your verdict. If you’re licensed for it, turn it on: the registry, the ownerless-agent flags, the approval flow, the Purview audit trail — that’s infrastructure you’d otherwise have to build. Then hold the output to the same standard you’d hold any governance tool:
- Reconcile the number. Count agents independently across the planes you actually operate — Power Platform environments, M365 surfaces, Azure subscriptions — and compare against the registry. Where the counts differ, you’ve found either a documented coverage caveat or a blind spot; both are worth knowing.
- Ask what the dashboard couldn’t see. Unconnected platforms, draft agents outside Copilot Studio, pre-activation history, subscriptions nobody granted read access to. A registry that can’t see a plane doesn’t show an error — it shows a smaller number.
- Push past existence. Ownership and risk flags are the start. Drift since approval, tool-and-connection blast radius, and grounding-content reach are where audit findings actually come from.
Microsoft building the registry is the best thing that’s happened to this category: it standardizes the substrate and settles the argument about whether agent governance is real. What it doesn’t settle is the question every registry eventually faces — whether the number on the dashboard is the number in the tenant.
Polaris Governance Hub runs inside your own Microsoft 365 tenant and inventories agents across Copilot Studio, M365 surfaces, and Azure AI Foundry — with configuration drift, tool-and-connection risk, and coverage stated honestly, including what we couldn’t see. We’re taking a small number of design partners. See what’s actually in your estate.