Copilot keeps shipping new agents and makers keep sharing their own. We want everything blocked until IT leadership signs off — without checking the agent list every morning. Is there a real ‘deny by default’ setting, or only per-agent blocks?

Agent settings, allowed types, user access, and the requests queue — Steady GRC before the Agent Store fills itself.

Can we block Copilot agents by default until IT approves?

You’re right to want a gate, not a daily scavenger hunt. The fear is legitimate: one morning the Agent Store looks fine, the next week users are installing Microsoft, partner, and home-grown agents you never reviewed.

Here’s what’s going on. There isn’t a single magic switch labelled “block every new agent forever and only open one after a ticket.” Microsoft’s model is policy plus inventory, not a perpetual global freeze that auto-blocks every future SKU. In the Microsoft 365 admin center, Agents → Settings is where you set the posture: Allowed agent types (Microsoft / your organisation / external publishers), User access (all users / no users / specific groups), Sharing (who can broadcast Agent Builder agents), and Agent management rules for bulk lifecycle actions. Separately, Agents → All agents lets you block or unblock named agents, and organisational agents published from Copilot Studio show up under Requests for publish / reject.

So “deny by default” is assembled, not gifted. Practical options:

Tighten the store, not just one agent. Set User access to a pilot security group, and under Allowed agent types leave only what Wave 0 needs (often Microsoft first-party on, organisation off until a review path exists, external off). Best default for most tenants mid-adoption.
Use the approval path for org-built agents. Treat Requests as the change board: review metadata, data sources, and actions before Publish. Pair with a rule that rejects stale publish requests older than N days so the queue doesn’t rot. Moderate effort; matches how Learn describes admin approval before broad availability.
Block loudly after the fact. Inventory → Block on anything unsafe. Works for known bad actors; fails as a strategy because you’re always late.
Set User access to No users and hope. Stops agent install broadly — and also stops the useful pilots you promised leadership. Use only as a short circuit-breaker.

The caution: Researcher and Analyst sit in the core Copilot chat experience and do not fall under agent-related settings the same way store agents do — Learn is explicit. Blocking “agents” doesn’t remove every AI tool users see. SharePoint-created agents may still behave differently when blocked (availability in Copilot Chat vs site surfaces). And “Sharing = No users” still allows direct person-to-person shares for Agent Builder agents; it is not a hard stop on all distribution.

I’d suggest a one-page Wave 0 note: allowed types, pilot group for User access, who owns the Requests queue, and which management rules you’ll run (ownerless reassign / block unused ownerless / reject old requests — roadmap item 481518 landed lifecycle automation for risky, inactive, and ownerless cases). That is Steady GRC before the catalogue fills itself.

You’re asking the right question. Steady before scale means the Agent Store earns trust; it doesn’t inherit it.