What it does

This is Microsoft's comparison of the governance controls for Copilot plugins and agents, organised by what you're actually controlling: a plugin package, an agent, a skill or MCP server, a connector package, a connector connection, or an external service. It answers "where do I click" once you know the object, and it's deliberately blunt that no single surface governs a whole plugin.

Key facts

• Six object types, each with its own typical controls: plugin package (availability, assignment, blocking, removal), agent (review, approval, sharing, assignment, ownership), skill or MCP server (installation, availability, blocking, runtime control), connector package (app availability and assignment), connector connection (authentication, users, content, schema, sync, health) and external service (account access, consent, credentials, revocation).
• Agents distributed as Microsoft 365 apps are managed in the Copilot section of the Microsoft 365 admin center: access and assignment, agent requests for review and approval, the agent registry for inventory and ownership, and agent settings for allowed agent types, policy templates and sharing limits.
• Tools (plugins, skills, MCP servers, connectors) can be controlled independently of the agents that reference them, via the manage-tools-for-agent page in the admin center.
• Agents built with SharePoint are governed by item-level permissions on the .agent file in Site Assets, not by the admin center agent controls. Copilot Cowork plugin packages have their own deployment, sharing, blocking and user-enablement page.
• Org-wide sharing for Agent Builder agents can be set to everyone, selected users or groups, or nobody. Changing it only affects new sharing actions; agents already shared stay accessible until someone changes their sharing settings.
• An agent can sit in more than one distribution path at once. An Agent Builder agent tracks its shared version and its Agent Store version separately, so changing one doesn't change the other.
• Copilot connectors span the Entra admin center (app registrations and consent), the Microsoft 365 admin center (connection configuration) and the Teams admin center. AI Administrators can be delegated connector registration and consent without Global Administrator.

When to use / skip

Use it when a request arrives and you need to work out which admin surface applies, or when you're writing the governance section of a rollout plan. Start from the object, not the product name.

Skip it as an end-to-end lifecycle guide. For the sequence of review, assignment and retirement, use the availability and lifecycle docs; this one is a lookup table.

Configuration decisions

• Object-first policy. Write your governance standard per object type, not per plugin. Otherwise the connector connection and the MCP server get missed.
• Org-wide sharing. Pick everyone, a named group of makers, or nobody for Agent Builder sharing before enabling the entry point.
• Delegation. Decide whether AI Administrators handle connector consent, or whether it stays with Global Administrators.
• Who watches the registry. Name an owner for agent registry inventory reviews; nothing reminds anyone.

Gotchas

• Blocking a package or agent doesn't revoke an external account, credential or consent grant. The dependency stays usable by anything else holding it.
• Package-level availability and connection-level configuration are different operations. Removing an app package that contains a connector doesn't tidy the connection, its synced content or its schedule.
• Reports, audit detail and dependency impact vary by object and by Microsoft 365 experience, so there's no one view that tells you everything a plugin touches.
• A per-user connection isn't the same as organisation-level deployment. "It works for me" after connecting is not evidence it's been rolled out.
• Interface labels are still moving during rollout. Treat screenshots in older runbooks with suspicion.

Consultant notes

• Build the governance matrix as a spreadsheet: object type down the side, control surface across the top, named owner in each cell. Blank cells are your findings.
• Clients routinely assume blocking an agent kills its connector sync. Prove it in a test tenant before the first incident forces the question.
• Org-wide sharing changes look instant and aren't. Tell the security team that already-shared agents carry on until someone edits them, or you'll get an awkward call after the policy "didn't work".
• Check the SharePoint agent route separately. It slips past admin center reviews because the control is file permissions, and site owners will happily create agents you've never seen.

---

Admin surfaces for agents are still being consolidated — worth revisiting after the next admin center agent-management update.