Over the past year I've seen most Microsoft 365 tenants quietly pile up a surprising number of Copilot agents. Users and business teams have taken to Copilot Studio and the Copilot agent builder with real enthusiasm, but admin visibility and governance usually trail well behind. So at the start of the year I recommend a Copilot agent inventory. You want to know which agents exist, where they are shared, who owns them and which ones are outdated or no longer used.

Admins find Copilot agents in two places

Visibility is the first hurdle. Microsoft has improved the admin tooling for agents, but a complete Copilot agent inventory still means checking two portals. In the Microsoft 365 admin center, the Copilot blade now has an “Agents” section that lists all agents published across the organisation, along with owner, status and visibility (for example "shared org-wide"). The Power Platform admin center shows Copilot Studio agents per environment, including ownership and sharing status. When I go through these lists with customers, we regularly come across half-forgotten experiments or agents that are shared much more widely than they should be.

Review both portals on a regular basis, particularly after a year in which champions, business units or innovation teams have been building agents freely. The count is almost always higher than anyone in the room expected.

Org-wide sharing and unclear ownership make the inventory critical

The situation becomes serious once agents are shared "organisation-wide". Anyone in the tenant can then use them, including automations that are experimental or were never reviewed. In larger tenants I've found dozens of these, and many had never been through any formal review.

Ownership needs a close look too. Agents are often owned by individual users (sometimes people who have already left the company) or by project teams where nobody really feels responsible. Without a named owner, maintenance and eventual decommissioning tend to get forgotten.

The diagram below shows where Copilot Studio and agent builder agents show up for admins and how oversight fits in:

flowchart TD
  User["User creates agent"] --> Studio["Copilot Studio environment"]
  Studio --> PPAdmin["Power Platform Admin Center"]
  Studio --> OrgShare["Agent shared org-wide"]
  OrgShare --> M365Admin["M365 Admin Center Agents overview"]
  PPAdmin --> Admin["Admin reviews agents"]
  M365Admin --> Admin

Figure: Where Copilot agents become visible to admins and can be managed in a tenant.

Every agent that is shared org-wide should be reviewed regularly. If the owner is unclear or hardly anyone uses it, deactivating or removing it is a reasonable next step.

Unused and orphaned agents are your cleanup candidates

In practice, most tenants collect agents that see little use after the first few weeks. The Power Platform admin center gives you basic usage stats per environment, but according to the current announcement there is still no tenant-wide usage dashboard. Even so, sorting by recently used or recently modified agents gives admins a decent idea of what is active and what has probably been abandoned.

I prefer an annual review with the agent owners, where we go through which agents are still needed and which can be retired. These sessions often turn into useful conversations about automation, data risk and process improvement, especially when agents are connected to sensitive data or webhooks.

Practical tip: Always look for orphaned agents, meaning agents whose owner account is no longer active. Assign them to a new owner or remove them quickly so they don't become an unmanaged risk.

For the actual cleanup, the filter and export options in the Power Platform admin center are usually sufficient (you need the Power Platform or Copilot Studio Admin role). A spreadsheet listing each agent with its owner and sharing status is the most useful place to start.

Admins can block and remove agents, but they also need an approval process

A question I hear a lot is how to keep badly built or unapproved agents from spreading. The answer combines technical controls with process. In the Power Platform admin center you can disable or remove agents, and org-wide shared agents can be blocked centrally (see Microsoft’s documentation).

What makes the biggest difference, though, is a documented approval workflow that agents go through before they are shared org-wide. In several projects I've worked with a short checklist:

  • Who owns the agent?
  • Which data sources does it use?
  • Has usage been documented and tested?
  • Has IT or data privacy reviewed it?
  • Is there a lifecycle plan (annual review, decommissioning)?

If you want more concrete controls, have a look at my posts on Copilot Studio governance and the AI agent governance checklist.

A Copilot agent inventory is not optional

After a year of people building Copilot agents, I'm convinced that a regular Copilot agent inventory is necessary. Without it you have no real view of your tenant, and shadow IT or outdated automations can cause genuine problems. The admin tooling now offers enough transparency, yet the process around it still counts for more.

If you clean up now, you'll spare yourself a lot of stress later in the year, and you'll have a solid base for introducing AI in your tenant in a safe, managed way.