What it does

Lets admins control which Copilot agents users can install, build and share, managed through Integrated Apps in the Microsoft 365 admin center alongside the wider Copilot agent settings.

Key facts

• Agents are treated much like integrated/third-party apps — you allow, block or deploy them centrally.
• You can control who may create agents (via Copilot Studio) and who may share them, tenant-wide or by group.
• Sharing scope matters: an agent shared broadly inherits the underlying data permissions of whoever runs it, so a poorly-scoped agent can surface content users shouldn't see.
• Metered/pay-as-you-go agents carry cost, so build and publish rights are also a budget control.
• Line-of-business and Microsoft-published agents can be managed and deployed the same way.

When to use / skip

Set agent controls before you open Copilot Studio to the business. If you skip this, expect a sprawl of half-built agents and no idea who owns them.

Configuration decisions

• Who can build agents, and whether that's role- or group-gated.
• Default sharing posture: locked down and requested, or open with review.
• Which third-party and store agents are allowed into the tenant.

Gotchas

• "Share with everyone" on an agent over-broad data connections is an oversharing incident waiting to happen — permissions flow through the agent.
• Blocking an agent after users depend on it causes noise; decide policy before adoption, not after.

Consultant notes

• Treat agent governance as an extension of app governance — same review discipline, same owners.
• Cap build rights during early rollout; widen once you've a review process and a cost model that works.
• Watch metered agents closely — an enthusiastic maker can run up real spend before anyone notices.
• Keep a register of who owns each published agent; orphaned agents are a support and security headache.

---

Revisit when agent controls move or Agent 365 governance changes the model.