Managing Copilot Agents in the Microsoft 365 Admin Center - What Actually Matters

Six months after an organisation turns on Microsoft 365 Copilot, a pattern shows up. There are now agents. Not one agent that someone carefully built and rolled out, but a scatter of them: a couple built by the IT team, a few that came bundled with third-party apps, one that a keen person in finance made in Copilot Studio on a Friday afternoon, and a handful that appeared because a vendor's Teams app quietly ships an agent alongside it. Nobody has a full list. Nobody is quite sure who can use what. And the person who owns the Microsoft 365 admin center is starting to get nervous.

That is the moment the admin center stops being a place you visit once and becomes the thing you actually run. Managing agents is not glamorous work. It is the difference between Copilot being a capability your organisation controls and Copilot being a sprawl you are perpetually cleaning up after. Microsoft's documentation on managing agents as integrated apps covers the buttons. This post is about the judgement, the stuff we have picked up helping Australian organisations keep their Copilot estate sane.

Agents are apps, and that is the whole trick

The single most useful thing to understand is that Copilot agents are governed as apps. In the Microsoft 365 admin center, under Integrated apps, agents sit alongside the other apps flowing into Microsoft 365 and Teams. An admin manages them with the same controls: deploy, block, assign to users, review permissions.

Why does this matter? Because it means you already have a governance model. You do not need a whole new discipline for agents. The habits you built for controlling Teams apps and add-ins apply directly. The admin who is good at deciding which apps get into the tenant is the admin who will be good at deciding which agents do. That is reassuring, and it is also the point people miss when they treat "AI agents" as some exotic new category needing its own committee.

The Integrated apps view is where the whole thing lives. You see what is available, what is deployed, who it is assigned to, and what permissions it wants. For an admin trying to answer "what agents are running in my tenant and who can use them", this is the one screen that gives you an honest answer. And an honest answer is more than a lot of organisations currently have.

Approve, block, and the space in between

The core decisions are simpler than people fear. For any given agent you can allow it, block it, or control who gets it.

Blocking is the blunt instrument, and it has its place. If an agent turns up that you do not trust, that wants permissions you are not comfortable with, or that simply has no business being in your tenant, you block it. Done. It is not available to anyone. In regulated industries this is the control that lets a security team sleep, because it means an agent cannot reach users just by existing in the store.

Allowing an agent makes it available, but the more interesting control is assignment. You do not have to choose between "nobody" and "everybody". You can deploy an agent to specific users or groups. This is where good Copilot governance actually happens, because it lets you run an agent for the finance team without exposing it to the whole company, or pilot something with twenty people before you widen it. We lean on this constantly. A staged rollout by group is nearly always better than flicking a tenant-wide switch and hoping.

The honest bit: the granularity is good but not infinite, and the interface rewards people who have already organised their users into sensible groups. If your Microsoft 365 groups are a mess, your agent assignment will be a mess too, because you are targeting the same groups. The admin center will not fix your underlying group hygiene. It just exposes how good or bad it already was. That is a recurring theme with Copilot generally: it surfaces the state of the house you already built.

The agents you did not build are the ones to watch

Here is where I want to be blunt, because the docs will not say it this plainly. The agents most likely to cause you a problem are not the ones your team deliberately created. They are the ones that arrived.

Third-party Teams apps increasingly ship agents. A vendor app that your organisation approved eighteen months ago for one purpose may now include a Copilot agent that reaches into content and conversations. Copilot Studio makes it genuinely easy for non-developers to build and share agents, which is wonderful for adoption and slightly terrifying for governance. The result is that agents appear in your tenant through paths that never went past a formal review.

The Integrated apps view is your defence against this, but only if someone actually looks at it. My strong advice to every client is to make agent review a scheduled thing, not a reactive one. Once a month, someone with the admin role opens the Integrated apps list, checks what is new, and asks the boring questions: what is this, who added it, what can it see, does it need to be here. That half-hour is the cheapest governance you will ever buy. The organisations that get burnt are the ones where nobody looked until an auditor or an incident forced them to.

This is exactly the kind of ongoing discipline our business AI managed services team runs for clients who do not want a full-time person watching the Copilot estate but absolutely need someone to. The tooling is there in the admin center. What is usually missing is the habit and the owner.

Permissions are the question everyone forgets to ask

When you review an agent in the admin center, you can see the permissions it requests. This is the part I wish more people slowed down on.

An agent that only reads and reasons over what a user can already see is a low-risk proposition. An agent that requests broad permissions, that can reach across sites or read organisation-wide data, is a different conversation entirely. The admin center shows you which you are dealing with, but it will not make the decision for you. Someone has to look at a permission set and judge whether the value the agent delivers justifies the reach it wants.

In healthcare and financial services work, this is often where we spend the most time, and rightly so. An agent that speeds up policy lookups is great, right up until you realise the permissions it needs also let it see things it should not. The review process forces that question into the open before the agent is live, not after. Treat the permission review as the actual decision point, because it is. Everything else is plumbing.

Where the admin center is still a bit rough

I will not pretend this is all smooth. A few honest gripes from the field.

The naming and categorisation of agents versus apps versus plugins has shifted over time, and if you have not been following closely you can find the terminology confusing. What is an agent, what is a connected app, what is a Copilot extension. The lines have moved as Microsoft has evolved the platform, and the admin center still carries some of that history in its labels.

Visibility across a large, messy tenant can also be harder than it should be. If you have hundreds of apps, finding and reasoning about the agents specifically takes more clicking than I would like. It is workable, but it is not yet the clean single pane of glass that the marketing implies.

And the split between the Microsoft 365 admin center, the Teams admin center, and Copilot Studio's own management surfaces means an admin sometimes has to know which tool owns which decision. It is getting better, and the Integrated apps model is genuinely the right direction, but do not expect every question to be answerable from one screen just yet.

None of this is a reason to avoid the work. It is a reason to have someone who knows the platform doing it, rather than assuming it is self-explanatory. This is the sort of practical Microsoft platform knowledge our Microsoft AI consultants bring to a Copilot rollout, because the gap between "we turned Copilot on" and "we govern Copilot well" is mostly experience.

What good looks like

If I had to compress it: know what agents exist, control who gets them, review permissions before you say yes, and check the list on a schedule rather than in a panic.

Concretely, for an Australian organisation running Copilot at any real scale, that means a named owner for the Integrated apps view, a monthly review baked into someone's calendar, sensible groups so that assignment is precise rather than all-or-nothing, and a default posture of blocking agents you have not deliberately approved rather than letting everything through. It is not complicated. It is just easy to not do until it bites.

The admin center gives you everything you need to run agents responsibly. What it does not give you is the discipline to use it, and that is the part organisations have to supply themselves. Get the governance habit right early, while you have five agents instead of fifty, and Copilot stays a capability you control rather than one that quietly controls you.

If you are rolling out Copilot and want the governance side handled properly rather than bolted on after something goes wrong, that is very much what we do. Have a look at our Copilot Studio consultants work, or get in touch and we will help you get your Copilot estate under control.