Notifications
Clear all
Topic starter
06/06/2026 11:27 am
TL;DR: Tool routing, not just model routing, is what lets AI agents generate images, transcribe audio, search the web, and publish content through MCP servers, skills, and API calls, according to WorkOS. The governance problem is no longer model choice alone, but whether agents can invoke capabilities safely and within bounded identity scope.
NHIMG editorial — based on content published by WorkOS: Model Routing vs Tool Routing: How to give your AI agents superpowers
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern tool routing for AI agents?
A: Start by treating tool routing as an entitlement problem, not a prompt-engineering problem.
Q: Why do AI agents with MCP access create more risk than model routing alone?
A: Because model routing only changes which brain reasons over the task, while MCP access changes what the agent can actually do.
Q: What breaks when every agent in a team can call the same tools?
A: Shared tool access creates a compound delegation chain where one agent's output can trigger another agent's action without a fresh governance check.
Practitioner guidance
- Separate model choice from tool entitlement Maintain distinct approvals for model routing and tool routing.
- Scope every MCP server as a privileged connector Document each MCP server, the actions it can perform, and the credentials it uses.
- Review tool combinations, not just individual permissions Assess how image generation, retrieval, publishing, and code execution compose when combined in one agent workflow.
What's in the full article
WorkOS's full post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step setup for model routing with OpenRouter and Claude Code Router.
- Practical examples of skills, MCP servers, and API calls used to give agents image, voice, search, and publishing capabilities.
- How agent teams are currently triggered in Claude Code and what the shared-model limitation means in practice.
- The specific environment variables and configuration changes involved in the routing setup.
👉 Read WorkOS's analysis of model routing vs tool routing for AI agents →
Tool routing with MCP: what it means for agent governance?
Explore further
06/06/2026 12:16 pm
Tool routing is the new identity control plane for AI agents. Once an agent can call image, voice, search, publishing, or code tools, the security question shifts from model quality to delegated authority. That moves the problem into NHI governance because the agent is acting through credentials, tokens, and connectors rather than only generating output. Practitioners should stop treating tool enablement as a feature toggle and start treating it as an entitlement boundary.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations reduce the identity blast radius of AI tool routing?
A: Limit each workflow to the smallest set of tools that can complete the task, and separate high-risk functions like publishing, code execution, and external retrieval. Then review connector scopes, token lifetimes, and team-level inheritance together. The goal is to prevent a single agent from accumulating broad delegated power through composition.
👉 Read our full editorial: Tool routing changes what AI agents can do with MCP
