Why do Researcher and Analyst ignore our agent settings?

You’re not imagining it — and you’re not alone. Plenty of admins assume “disable agents for this group” will tidy away everything that looks like an agent. Researcher and Analyst don’t play by that rule.

Here’s what’s going on. Microsoft documents Researcher and Analyst as first-party experiences built on the same foundation as Microsoft Copilot, inside the Microsoft 365 commercial data processing boundary. They sit in Copilot Chat under Tools, and Learn is explicit: while they coexist with agents and inherit Copilot’s security/privacy commitments, they are part of the core Copilot chat experience and will not fall under any agent-related settings. So if you disable Copilot agents for some or all users, Researcher can still remain accessible under Tools. Users also cannot disable, remove, or unpin Researcher themselves. There is no dedicated admin report or dashboard today that tracks Researcher/Analyst usage the way you might expect for custom agents. Per-user assignment is limited too: for Researcher and Analyst the Edit users panel is disabled — availability is managed with the tenant-wide Block (or Unblock) action under Agents → All agents. Blocking is the blunt instrument; it isn’t a Wave 0 security-group pin. Researcher still respects the tenant web search toggle (no granular allow/block list of sites), follows the same DLP posture as Copilot, and currently has a documented usage ceiling of 25 queries per user per month. Admins can also manage Connected Agents for Researcher (up to ten) if you want it to call other agents — that’s an expansion of surface area, not a substitute for Block.

Steady before scale here is Pane 04 Security & Compliance plus honest adoption messaging. Schofield’s Third Law (historically attributed) still applies: the easier the tool is to reach, the more people will use it against whatever Graph and web scope they already have — so treat Researcher as promoted by default, not as optional catalogue fluff.

Options that actually work:

1. Leave Researcher/Analyst on for Copilot-licensed users, govern the edges. Keep web search policy intentional, review Connected Agents, and brief pilots that Tools ≠ the agent inventory you just trimmed. Best Steady default for most Wave 0 programmes.
2. Block Researcher and/or Analyst tenant-wide via Agents → All agents → Block if the risk or change story genuinely requires it — then document that this is all-or-nothing, not group-scoped.
3. Assume agent-settings toggles or “disable agents for Group X” hide Researcher. They don’t; you’ll get confused tickets and a false sense of control.
4. Promise Finance a Researcher usage dashboard that doesn’t exist yet. You’ll invent metrics; Learn says there isn’t an existing reporting tool for these agents.

12 Panes action / comms: Tell Security: core Tools experiences ≠ block-by-agent-setting — use Block only when you mean the whole tenant. Tell adoption: users can’t unpin Researcher; don’t train “just remove it.” Tell leadership: auto-on deep research is a change-management fact, not a catalogue opt-in.

Benefits / risks: Clearer mental model stops false lockdown theatre; tenant-wide Block is coarse and may surprise executives who expected Researcher in demos; no usage report means you can’t prove shelfware or overuse from the product alone; Connected Agents can quietly widen what Researcher can reach if you connect first and govern later.

I’d suggest this week: decide deliberately — keep and brief, or Block and explain — then write one paragraph into the Copilot pilot FAQ so nobody thinks agent settings already did the job. You’ll have Steady governance without pretending the UI is finer-grained than Microsoft shipped.

DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer