Tool routing changes what AI agents can do with MCP

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: Tool routing, not model choice, is what gives AI agents real-world capabilities through MCP, skills, and API calls.

Why it matters: For IAM and NHI teams, the shift means governance has to focus on tool invocation scope, credential boundaries, and delegated capability control, not only model selection.

Context

Model routing changes which LLM makes decisions, but tool routing changes what an AI agent is allowed to do. That distinction matters because once an agent can call external tools through MCP, the governance problem moves from model selection to identity scope, capability boundaries, and the controls around invocation.

In practical terms, the article describes a pattern where a text-oriented agent can reach image generation, transcription, search, publishing, and code execution through connected tools. That is an autonomy-adjacent control problem even when the agent is not fully autonomous, because the risk sits in what it can invoke at runtime and how broadly those tools are exposed.

Key questions

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Why does tool routing increase risk more than model routing?

A: Model routing changes which LLM thinks, but tool routing changes what the agent can actually do. Once the agent can invoke search, generation, code, or publishing tools, the permission surface expands into operational workflows. That means the risk comes from delegated capability, not from model choice alone.

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Should organisations separate content creation tools from publishing tools for agents?

A: Yes, when the workflow permits it. Separating content creation from publishing reduces the chance that a single agent session can both generate and release material without an independent control point. That separation also improves review, because the system can inspect output before it becomes externally visible.

Technical breakdown

Model routing vs tool routing in AI agents

Model routing chooses which LLM handles a task, which affects quality, cost, and speed. Tool routing is different: it determines which external capabilities the agent can invoke through MCP servers, skills, and API calls. In this pattern, the model reasons about the task while the tools execute specialized work such as search, transcription, publishing, or image generation. That separation creates a broader capability surface than model choice alone, because the agent's functional reach is defined by connected tools, not the model's native output format.

Practical implication: Treat model choice as a performance decision and tool routing as an access-governance decision.

MCP servers and skills as capability boundaries

MCP servers and skills act as structured capability boundaries that tell an agent what it can call, what parameters it needs, and how to reach the underlying service. That is not the same as a generic plugin. It is a delegated identity surface where the agent can invoke bounded functions across multiple tools without the model itself being multimodal. The security issue is not only whether the tool exists, but whether the tool boundary is narrowly scoped, auditable, and tied to the right identity context.

Practical implication: Review each MCP-connected capability as if it were a delegated workload privilege.

Why tool routing multiplies identity risk

Every additional tool expands the combinations an agent can execute, which means the attack and misuse surface grows non-linearly. Search plus code execution, or image generation plus CMS publishing, creates workflows that are more powerful than any single integration. From an identity perspective, this shifts the question from whether a tool is individually approved to whether the agent's aggregate permission set matches its task boundary. That is the core NHI governance problem in agentic systems: the capability graph becomes more important than the model choice.

Practical implication: Map agent capabilities as a permission graph and constrain the combinations that can be chained in one session.

Threat narrative

Attacker objective: The objective is to turn a conversational agent into a high-reach execution layer that can act across multiple tools with minimal friction.

1. Entry begins when an AI agent is connected to external tools through MCP servers, skills, or API keys, giving it active runtime reach beyond text generation.
2. Escalation occurs when the agent is allowed to chain tools together, such as search, publishing, code execution, or content generation, without tightly bounded task scope.
3. Impact follows when those combined capabilities can create, modify, or publish content and code faster than traditional human approval loops can review them.

NHI Mgmt Group analysis

Tool routing is the real identity boundary for AI agents: the model is only the decision layer, while MCP-connected tools define what the system can actually do. That means governance failures will appear first as overbroad capability exposure, not as poor model selection. Practitioners should treat each tool path as a delegated entitlement with its own risk profile.

Capability chaining creates identity blast radius: once search, generation, code execution, and publishing are all available to the same agent, permission scope compounds across workflows. The risk is not any one integration in isolation, but the way they combine into a broader execution path. That makes least privilege a session design problem, not just a provisioning problem.

Model routing can improve efficiency without changing governance posture: swapping between cheaper and stronger models affects judgment, but it does not constrain what the agent can invoke. The control point is the tool layer, where identity, authorization, and auditability must be explicit. Teams that focus only on the brain will miss the body of the system.

MCP makes agent governance more operationally concrete: the protocol turns tool access into a visible integration surface that can be inventoried, reviewed, and bounded. That is useful because it exposes where capability is actually granted, rather than assuming the model is the whole system. The practitioner lesson is to govern the invocation layer as first-class identity infrastructure.

Autonomy is not required for the risk to exist: even semi-autonomous agents that follow user prompts can still assemble harmful or excessive actions if their tool inventory is too broad. The governance question is therefore not whether the agent is fully autonomous, but whether its delegated tools match the task and remain auditable. Practitioners should close the gap between conversational intent and executable reach.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Tool routing is the next governance layer: model choice affects reasoning quality, but the real control problem begins when agents can invoke external capabilities through MCP. Security teams should therefore map the tool layer as part of identity architecture, not as a sidecar to the model stack.

Agent setups that combine search, generation, and publishing create a capability graph that can outgrow human review processes quickly. The practical signal is simple: if an agent can chain actions across tools, governance has to move from prompt oversight to entitlement design.

For practitioners

• Inventory every tool route Document each MCP server, skill, and API connection an agent can reach, then classify it by the business action it enables and the identity context it inherits.
• Scope tools by task boundary Limit each agent to the smallest viable tool set for the workflow it is supposed to perform, and separate publishing, retrieval, and execution paths where possible.
• Review chained capabilities Test whether two tools combined create a materially broader action path than either one alone, especially when search, code execution, and publishing are linked.
• Add audit points at the tool layer Log tool invocation, parameter scope, and downstream effects so that agent actions are attributable even when the model remains the same across sessions.

Key takeaways

• AI agents become materially more capable when tool routing gives them access to external services through MCP, skills, and API calls.
• The main governance issue is not the model selection layer but the scope, chaining, and auditability of delegated tools.
• Identity teams should treat each connected tool as an entitlement and govern the combinations an agent can execute in one session.

Key terms

• Tool Routing: Tool routing is the practice of letting an AI agent invoke external capabilities such as search, image generation, transcription, publishing, or code execution. It shifts the governance problem from model selection to delegated action, because the agent now reaches other systems through credentials and connectors.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Capability Boundary: A capability boundary is the control line around what a non-human actor can do through a specific tool, workflow, or service. For AI agents, it is the practical unit of governance because the boundary determines what action the system can trigger, not just what the model can describe.
• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.