You ask, we answer · 28 September 2026
How do we stop agents using the wrong MCP tools?
Makers want Model Context Protocol servers and ‘tools’ wired into agents. Security asks whether we can approve or block those tools tenant-wide the way we approve apps — or is every agent a free-for-all?
Grounded with: Microsoft Learn — Manage tools for agents in Microsoft 365 admin center; Work IQ MCP overview; Microsoft Agent 365 service description
DIGITAL SKILL WORKS LTD / 12 PANES
You’re right to worry that “tools” sound harmless until an agent can call them. Connectors were yesterday’s blast radius; MCP servers are today’s.
Here’s what’s going on. In the Microsoft 365 admin centre, Agents → Tools gives a central Registry of AI tools and MCP servers, plus a Requests tab for approvals. Admins can Block or Unblock tools so agents and workflows can’t invoke them; blocked MCP servers are enforced at runtime across client surfaces. Bring Your Own (BYO) MCP (preview) lets developers register a remote server via the Agent 365 CLI; AI Admin or Global Admin reviews declared tools, approves or rejects, then grants Microsoft Entra consent — only then does the server appear in builder surfaces (propagation into Copilot Studio environments can take up to about 30 minutes). You can also view Power Platform connector usage under Tools (visibility first; policy still lands in Power Platform admin centre) and manage uploaded plugins/skills with install, block, and delete. Learn’s Agent 365 service description still draws a licensing line: richer tenant-wide tool/MCP controls sit with Agent 365 / Microsoft 365 E7, while base M365 plans cover registry inventory and basic agent lifecycle — verify what your SKU actually unlocks before you promise a board pack.
This is Third Law for agent capability: the easier it is for an agent to reach a tool, the easier a poorly scoped or compromised agent reaches it too. Steady before scale means Pane 04 Security owns the tool allow-list before makers treat MCP as an open app store.
Options that actually work:
- Registry hygiene first. Inventory Tools → Registry; block anything with no business owner; approve BYO only with named sponsor, purpose, and declared tool snapshot. Best Steady default.
- Pilot allow-list. Approve one MCP server for a Wave 0 environment and security group; watch Defender advanced hunting (
ExecuteToolByGatewayand friends) before widening. Moderate effort; real observability. - Approve everything makers request “so innovation isn’t blocked.” Fast politically. You’re importing ungoverned tool surface into every agent that can see the registry.
- Ignore Tools and only govern agents. Incomplete — an approved agent with a risky tool is still a risky agent.
12 Panes action / comms: Tell makers: register → Requests tab → wait for consent; don’t paste secrets into a personal MCP and call it enterprise. Tell Security: Block is runtime, not theatre — use it; connectors still need Power Platform DLP. Leadership: tools are a second inventory beside agents; both need owners.
Benefits / risks: Central approve/block stops silent BYO sprawl; over-blocking first-party MCP (Teams, Dataverse, admin tools) breaks useful agents; BYO is preview with client-surface limits; deleting a BYO server isn’t supported yet per Learn — treat registration as sticky; SKU packing moves.
I’d suggest this week: open Agents → Tools → Registry, export or screenshot what’s Available vs Blocked, clear the Requests queue with Approve only where there’s a named owner, and add “MCP/tool allow-list” to your AI operating cadence next to the agent register. You’ll sleep better when agents can only call tools you’ve already said yes to.
DIGITAL SKILL WORKS LTD / 12 PANES · You ask, we answer