Copilot extensions from Build 2024 give admins new governance work

Copilot for Microsoft 365 is no longer just a helpful sidebar. It is turning into a platform you can extend. In many of the organizations I work with, Copilot pilots are still controlled experiments, but today's Build 2024 announcements about Copilot extensions, plugins and connectors will add noticeably to the admin workload. The conversation shifts from "Can Copilot help users?" to "Who's building what, where, and with which permissions?"

Copilot extensions cover several ways to extend Copilot

"Copilot extensions" is an umbrella term for the growing number of ways to extend Copilot. There are plugins and connectors built with Teams Toolkit or Copilot Studio (Microsoft's extensibility docs), and there are Microsoft Graph connectors that bring external data into the Copilot and Microsoft 365 search index. Build 2024 also introduced Team Copilot, an entirely new category coming later this year, with agents that can work on tasks autonomously. For admins, that means a quickly growing set of integrations to track, approve and secure. I've seen for myself how fast app sprawl sets in once business users and citizen developers get their hands on extension mechanisms like these.

Plugins, connectors and Graph connectors form the new building blocks

In practice, Copilot extensions come in three main categories:

• Plugins: Usually task automations or data access features, built with Teams Toolkit or Copilot Studio and exposed as REST APIs.
• Connectors: Often built by business users with low-code tools in Copilot Studio. They connect Copilot to other data or actions.
• Graph connectors: They bring structured data from third-party apps such as Salesforce or ServiceNow into the Microsoft 365 graph and the Copilot experience.

That flexibility is useful, and it carries real risk. Before anyone enables Copilot extensions, admins should map out which data gets exposed and where. I've watched a Graph connector make sensitive internal data discoverable through Copilot and Microsoft Search overnight, sometimes to far more people than intended. I wrote about a related problem earlier in my post on restricted SharePoint search and Copilot oversharing.

Power Platform environments decide who can build extensions

The first thing I always want to know as an admin is who in the organization can actually create these things. Plugins and connectors are usually developed in dedicated Power Platform environments, and those environments, together with their DLP policies, determine how controlled development really is. Business teams often move fast and spin up their own low-code prototypes. That's good for innovation, but the old risks come right along with it: shadow IT, data leakage and missing documentation. Once Team Copilot arrives (in preview later this year), we'll see how much of this ends up self-service and how much stays centrally managed.

My tip: Create dedicated environments for Copilot Studio projects, back them with strict DLP policies, and keep an up-to-date inventory, ideally automated through the Power Platform admin APIs, so extensions don't get out of hand.

The admin center shows installed extensions and connectors

The Microsoft 365 admin center keeps changing, and you can already view and control installed Copilot extensions and Graph connectors under integrated apps. People often overlook that many of these extensions request broad API permissions with compliance and security implications. Linking Power Platform DLP policies to these environments goes a long way toward keeping data flows in check.

Graph connectors bring their own challenge. Their permissions are explicit, so the configuration decides who can access the indexed data. I've seen misconfigured connectors make CRM or support data searchable by more users than intended. I recommend exporting the connector configuration regularly and keeping a documented inventory of connected sources. This is the short PowerShell snippet I use to list Graph connectors:

Get-SearchConnector | Select-Object Name, ConnectorType, Status, CreatedBy

Every Copilot extension follows the same path from development to users

Admins regularly ask me how a Copilot extension gets from development into actual use. The diagram below shows the basic flow, starting in development, moving through Power Platform and into the admin center for visibility and control, and ending with the user. Governance depends on keeping this lifecycle transparent.

flowchart TD
  dev["Dev (Copilot Studio/Toolkit)"] --> powerplatform["Power Platform environment"]
  powerplatform --> admincenter["M365 Admin Center"]
  admincenter --> user["User with Copilot"]
  admincenter --> inventory["App inventory"]

Figure: The Copilot extension lifecycle, from development to user access and inventory.

I recommend proactive governance for Copilot extensions

The Build 2024 announcements show that Copilot extensions bring plenty of value and plenty of governance work for admins. Start now with dedicated Power Platform environments, strict DLP policies and regular reviews of Graph connector permissions and scope. The admin center is getting better at integrated management, but it doesn't replace basic rules and oversight. With Team Copilot and autonomous agents on the way, governance will only matter more. If you lay the groundwork now, you'll have fewer surprises later. For more practical planning advice, have a look at my post on Copilot for Microsoft 365 tenant readiness and the official Build 2024 Book of News.