Governing agent sprawl: what the Microsoft 365 admin center actually shows you
Copilot Studio and Agent Builder make it trivial for anyone to publish an agent. Here is what the Agent Registry, Activity tab, Security tab and the new unified app/agent management actually give admins to keep that sprawl under control.
Six months ago the governance question in most tenants was “who installed the Copilot app.” Now it’s “how many agents does Marketing have running against SharePoint, and does anyone know what they can read.” Agent Builder and Copilot Studio have made publishing an agent about as hard as building a Power Automate flow, which means the population of agents in a tenant grows a lot faster than the population of admins who understand what each one is allowed to touch.
The Microsoft 365 admin center has been catching up to that problem. What’s actually useful today lives in the Agent Registry, and it’s worth knowing exactly what it gives you before you promise a security team “we have this under control.”
The Agent Registry is the inventory, not just a list
Under Agents > All agents, every agent your tenant knows about shows up in a Registry list. Selecting one opens a details fly-out with a set of tabs — but which tabs appear depends on what the agent actually does, so don’t expect a uniform view across your inventory:
- Details — description, instructions, publish status, publisher, deployment, channel, platform, version.
- Users — who has the agent pre-installed versus who can merely discover and install it. These are two independent controls: you can make an agent available to one group while pre-installing it for a different one, and installing an agent org-wide overrides its availability scope by design.
- Data & tools — a read-only summary of what the agent can read (public sites, tenant files, email, calendar), which knowledge sources it draws from (SharePoint sites, specific URLs, Graph connectors), and which tools it can invoke (Microsoft 365 connectors, MCP servers, custom actions). This is the tab worth reading before you approve anything — a tool that writes data or reaches an external service deserves more scrutiny than one that only reads a SharePoint library.
- Permissions — application permissions (no signed-in user required, tenant-wide reach, admin consent needed) versus delegated permissions (scoped to the signed-in user). The same permission name can mean very different blast radius depending on which type it is.
- Certification — publisher attestation plus Microsoft 365 Certification status where it exists, valid for 12 months. Useful as one input into an approve/block decision, not a substitute for reading Data & tools yourself.
None of this requires a special license — it’s the baseline inventory every admin should already be checking before an agent gets pinned in front of users.
Activity and Security are where the E7/Agent 365 line sits
Two tabs need a Microsoft E7 or Agent 365 license to actually show detail:
Activity gives a 30-day (adjustable) window on a single agent:
- Active users — unique users with at least one interaction in range.
- Sessions — conversations, where a new session starts after 30 minutes of inactivity.
- Exceptions — sessions that errored out, your signal for reliability problems.
- Agent run-time — total hours the agent spent working, from first user turn to completed tool calls and response.
Activity metrics currently cover Microsoft 365 Copilot Agent Builder, SharePoint, and Microsoft 365 Agents Toolkit agent types — not every agent type reports here yet, so absence of data isn’t the same as absence of usage.
Security ties the agent into Microsoft Purview: Activity explorer for sensitive-content interactions, AI observability for a tenant-wide view of agent activity, and Compliance Manager for AI baseline assessments where one exists. This is the tab that turns “an agent exists” into “here is what it touched and whether that was sensitive.”
Budget for this explicitly. If your governance story depends on Activity or Security data and nobody in the tenant is licensed for E7 or Agent 365, you have a registry, not observability.
Fixing the split-brain between Teams and Microsoft 365 admin centers
The other piece worth planning for is unified agent and app availability management across the Teams admin center (TAC) and Microsoft 365 admin center (MAC) — tracked under Roadmap ID 485712 and Message Center post MC796790. Today, app/agent availability set in MAC only reaches Outlook and Microsoft 365; settings set in TAC only reach Teams — so the same rollout has to be configured twice, and it’s easy for the two to quietly drift apart.
Once a tenant moves to the unified model, org-wide defaults and per-app availability changes made in either admin center sync automatically to the other. Tenants that never touched their defaults unify with no action needed. Tenants with existing customizations go through an explicit reconciliation flow in Teams apps > Manage apps: align org-wide defaults, then resolve any per-app availability differences individually, in bulk, or via a CSV export for review — and only a Global admin can give the final consent to complete the move.
Practical implication: before you build a governance runbook that references “the app availability policy,” check with whoever owns Teams admin whether your tenant is already unified. If it isn’t, two people can each be confidently wrong about what’s actually enforced.
A rollout order that holds up
- Inventory first. Pull the Agent Registry and separate agents by platform/type, since Activity reporting doesn’t cover all of them yet.
- License Activity/Security deliberately for whoever owns agent governance — don’t assume E7 coverage exists just because some users have it.
- Read Data & tools before approving, not after a complaint. It’s the only tab that tells you what an agent can actually do, independent of what its description claims.
- Reconcile TAC/MAC before you rely on either one alone — check unification status, and if you have drift, resolve it through the guided flow rather than ad hoc changes in one console.
- Treat Certification as one signal, not a gate. A certified agent with broad application permissions and an unreviewed tool list is still a risk decision, not a green light.
Agent sprawl isn’t a future problem to plan for — Agent Builder already shipped it. The admin center gives you enough to govern it, but only if you go looking for the Activity and Security tabs before someone else finds them for you during an incident review.
Sources & further reading: Understand agent details in Microsoft 365 admin center, Manage agents in the Microsoft 365 admin center, Unified agent and app availability management across Microsoft 365 and Teams Admin Centers, Agents admin guide for Microsoft 365.