You ask, we answer · 25 September 2026
Do Copilot Studio agents always need admin approval?
Learn says agents published from Copilot Studio show under Requests in the Microsoft 365 admin centre — but our makers publish and nothing appears until they target Teams or Microsoft Copilot. Is every Studio publish gated by IT, or only the organisational catalog path?
Grounded with: Microsoft Learn — Manage requested Copilot Studio agents; Manage agent requests in Microsoft 365 admin center; Agents admin guide for Microsoft 365; Manage agents in the Microsoft 365 admin center
DIGITAL SKILL WORKS LTD / 12 PANES
You’re right to check — plenty of admins assume “Publish in Studio” always queues an IT review. It doesn’t, and that gap is where false comfort lives.
Here’s what’s going on. Microsoft documents that when makers publish a Copilot Studio agent to your organisation using the Microsoft Teams and Microsoft Copilot channel, the agent lands under Agents → All agents → Requests in the Microsoft 365 admin centre. From there admins review metadata (description, owner, Data & tools, permissions), then Publish to store or Reject submission. On publish you can scope who may install and optionally who gets it preinstalled, apply a policy template, and grant consent. Requests also cover Pending update (previous version stays live until you approve) and Pending activate. Agents from Microsoft Foundry or the Microsoft 365 Agents Toolkit can appear the same way when submitted for tenant approval. What Studio does not do is force that Requests gate for every channel: websites, custom apps, and other messaging surfaces can still be published under Power Platform environment, DLP, and channel controls without ever showing as an org-catalog request. So if your makers “publish and nothing appears,” they may simply not have targeted Teams/Copilot — or a filter on the Requests list (state/channel) is hiding them.
Steady before scale here is Pane 04 Security & Compliance plus an honest environment strategy: catalog approval is the front door for Copilot/Teams discovery; it is not a substitute for locking connectors, channels, and makers in non-default environments. Schofield’s Third Law (historically attributed) still applies — the easier the agent is to reach in the store, the more people will invoke whatever knowledge and tools it already has.
Options that actually work:
- Treat Requests as the catalog control plane. Brief makers: Teams + Microsoft Copilot publish = IT review. Run a weekly Requests triage; reject stale submissions; publish only owned agents with reviewed Data & tools. Best Steady default for Wave 0 org agents.
- Pair catalog approval with environment ALM. Dev environments for makers; promote to production only after review; DLP and channel blocks so “publish elsewhere” can’t quietly expose the same agent on a public site. Complements, doesn’t replace, Requests.
- Assume every Studio Publish button creates an admin ticket. You’ll get confused tickets and a false sense that nothing escaped governance.
- Leave Requests empty and rely on hope. Catalog sprawl arrives the week after someone finds the Teams channel checkbox.
12 Panes action / comms: Tell makers: org discoverability in Copilot/Teams is an approval, not a publish alone. Tell Security: Requests ≠ all Studio surfaces — still own environments, DLP, and channels. Tell leadership: catalog gate is deliberate rollout, not a magic freeze on every agent.
Benefits / risks: Clear mental model stops “IT blocked everything” theatre; Pending update means users keep the old version until you act — don’t assume reject-then-ghost; filters can hide real backlog; non-catalog channels remain a parallel risk if environments are wide open.
I’d suggest this week: open Agents → Requests, clear filters, reconcile against known Studio publishes to Teams/Copilot, then write one maker FAQ line — catalog path needs approval; other channels need environment rules. You’ll have Steady governance without pretending the UI is one switch.
DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer