Over the past year, the number of Copilot agents in the Microsoft 365 environments I work with has grown enormously. Next to the familiar agents from Microsoft, I now see tenants filling up with partner solutions, custom bots built in Copilot Studio and, more recently, SharePoint agents that appear directly on sites. For admins, managing Copilot agents has turned into a governance question and a cost question at the same time. Allowing or blocking is only part of it. You also need to know where an agent comes from, how it gets shared and who can actually use it. Since Microsoft released Microsoft 365 Copilot Chat and the new Copilot app in January 2025, agents are more visible and more widely used, and in some tenants that has also caused confusion.

Copilot agents reach a tenant through several channels

There are a few separate ways an agent can be created. Microsoft ships its own agents to every tenant, and partners can now publish theirs too, some vetted and some not. Inside the organisation, anyone with the right permissions can build agents with the Copilot Studio Agent Builder, which works well for quick internal bots and Q&A helpers. The full Copilot Studio experience goes further: those agents can connect to data sources and even trigger actions across Microsoft 365. The newest channel is SharePoint agents. Site owners create them, they show up right inside SharePoint, and they are often shared with everyone who uses the site. During pilots, agent sprawl rarely caused problems. In enterprise production it can get out of hand quickly if nobody keeps track.

The flow diagram below shows the usual lifecycle of an agent, from creation through admin intervention to the point where users can see it:

flowchart TD
    AgentBuilder["Agent Builder (Copilot Studio)"] --> AgentCreated["Agent created"]
    CopilotStudio["Copilot Studio (full)"] --> AgentCreated
    SharePoint["SharePoint Site"] --> AgentCreated
    PartnerMarketplace["Partner/Marketplace"] --> AgentCreated
    AgentCreated --> Share["Share with users"]
    Share --> AdminReview["Admin approval/block"]
    AdminReview --> UserAvailable["Agent visible to users"]

Figure: How an agent moves from creation to user availability, and where the admin steps in.

The admin center is where you manage every Copilot agent

Agent management now sits entirely in the Microsoft 365 admin center, under Settings → Integrated apps, in the Copilot section for agents. Every agent shows up there, whether Microsoft, a partner or someone in-house built it. I'd make a habit of checking this section regularly. In many tenants, new agents appear there quietly because Copilot Studio or SharePoint permissions are too loose. For each agent you can see the publisher, the description and, most importantly, its data sources and actions. The "Data sources" section tells you whether the agent reads corporate data, SharePoint content, external databases or only public web information. The publisher details help you decide whether you trust the source, and you can block anything that looks suspicious or unauthorised straight away.

These are the warning signs I look for before I approve a Copilot agent:

  • Access to sensitive M365 or SharePoint data
  • Use of actions (e.g., sending email, modifying content)
  • Unknown or unverified publisher
  • Built in Copilot Studio and shared widely
  • Vague description or several similar agents appearing

Tight creation and sharing permissions keep agent sprawl in check

If permissions aren't handled carefully, creating and sharing agents can get out of control fast. In Copilot Studio you can limit both the Agent Builder and the full Studio to specific groups or people. The relevant settings are split between the Microsoft 365 admin center and the Copilot Studio admin area. That's where you decide who can create, test and publish agents, and whether those agents can be shared with groups or with everyone. SharePoint agents need a closer look, because any site owner can roll one out to all users of a site. If governance matters to you, set up Copilot Studio governance early on and restrict agent publishing to a handful of trusted groups. I go into governance in more detail in /blog/copilot-studio-governance-power-platform-dlp and /blog/copilot-studio-autonomous-agents-governance.

Pro tip: Put a recurring review of the Copilot agents section in the admin center on the calendar so you spot new or changed agents early. A monthly check saves you from unpleasant surprises.

Unlicensed users trigger pay-as-you-go charges for agents

One thing that catches people out again and again: when users without a full Copilot licence use Copilot agents, that usage is billed pay-as-you-go. It usually happens when an agent is shared broadly, for example with "all employees" or a large group. Billing is tracked across the whole tenant and appears in the admin center under Billing → Usage-based services. Admins and the finance team both need to keep an eye on it, otherwise the end-of-month invoice can come as a shock. What I recommend is to restrict agent sharing, keep users informed on a regular basis and watch the Copilot section for unexpected cost drivers. Microsoft covers agent billing and the admin controls in full in its official documentation.

I check three things before I approve an agent

Every time someone asks me to approve a new agent, I look at the publisher, the data sources and any actions, and I'm particularly careful with Copilot Studio and partner-built agents. The admin center shows all of this on the first screen. If something doesn't look right, I block the agent and ask the owner to explain. A "simple" FAQ agent turns out to have much wider data access more often than you'd think. SharePoint agents come with their own pitfalls, which I describe in /blog/agents-in-sharepoint-governance-permissions, along with the main control points.

You can restrict or remove an approved agent in the admin center at any time. There's no PowerShell support yet, so everything happens in the portal.

# Blocking an agent in the admin center:
# Prerequisite: Global admin or App admin role
# Location: Microsoft 365 admin center → Settings → Integrated apps → Copilot agents
# (Select agent, then 'Block' in the portal interface)

Fewer agents and early ownership save a lot of cleanup

I learned this the hard way: define clear processes and owners for agent management from the start. Begin with a small number of agents you have reviewed properly, keep permissions tight and track usage and cost closely. SharePoint agents and autonomous Copilot Studio agents keep multiplying, and staying alert as an admin is always easier than cleaning up afterwards.