Tool routing changes what AI agents can do with MCP

At a glance

What this is: This analysis shows that routing tools through MCP, skills, and APIs expands AI agent capability far beyond model selection.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern what agents can invoke, not just which model they use or how they authenticate.

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.

👉 Read WorkOS's analysis of model routing vs tool routing for AI agents

Context

Tool routing is the practice of letting an AI system call specialised capabilities through connectors, skills, or MCP servers instead of relying on the base model alone. In identity terms, that shifts the control point from text generation to delegated action, which is where NHI governance becomes operationally relevant.

The key security question is not whether the model is smart enough. It is whether the agent can reach search, publishing, voice, image, or code tools without the identity controls that would normally gate those actions for service accounts, workloads, or autonomous systems.

Key questions

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. Define which tools an agent can call, which credentials back those calls, and whether each connector is scoped to a single task or a broader workflow. If you do not separate those controls, the agent inherits a larger action space than the business intended.

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. Once an agent can search, publish, transcribe, or execute code, the governance problem becomes delegated action and credential scope. That is why tool access expands blast radius even when the model is unchanged.

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. That makes overreach harder to spot and harder to contain. The control failure is not the existence of multiple agents, but the absence of role-specific tool boundaries across them.

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.

Technical breakdown

Model routing vs tool routing in agent identity

Model routing chooses which LLM performs reasoning, so the control problem is cost, speed, and answer quality. Tool routing governs which external capabilities the agent can invoke, such as search, image generation, transcription, or publishing. That second layer is where identity risk expands, because the agent is no longer only producing text. It is initiating actions through MCP servers, API keys, and skills that carry their own trust boundaries. Once tools are available, the practical security boundary becomes delegated capability, not model selection.

Practical implication: Treat model choice as a performance decision and tool access as an identity decision, with separate approval and review paths.

MCP servers and skills as capability boundaries

MCP servers and skills define what an agent is allowed to do, what parameters it can supply, and how the underlying API is reached. That makes them more than convenience layers. They are capability boundaries that translate intent into action. If those boundaries are broad, loosely scoped, or poorly inventoried, an agent can combine tools in ways the operator did not intend. The risk is not just misuse of one tool. It is composability, where each allowed tool increases the reachable action space of the agent.

Practical implication: Inventory every tool boundary and require least-privilege scoping at the connector level, not just at the model prompt level.

Agent teams and compounded access paths

Agent teams extend tool routing by distributing work across multiple coordinated agents. That improves task separation, but it also multiplies the identity surface because each agent can inherit access to the same tool stack. If model selection remains fixed while tools remain broad, the orchestration layer becomes the real locus of governance. The current limitation described in the article, where team agents share the same model, shows that capability growth can outpace policy granularity. Governance must therefore focus on how delegated access is composed across the team, not just on the lead agent.

Practical implication: Review agent-team access as a compound delegation chain and cap shared tool reach before adding more sub-agents.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

MCP creates capability composition, which is where most governance assumptions fail. Each allowed tool expands the reachable action space of the agent, and the combination matters more than any single integration. This is why a narrow model with broad tools can be riskier than a strong model with no tools. The implication is that access reviews must examine tool combinations, not just individual permissions, because blast radius is created by composition.

Ephemeral capability does not equal safe capability. Tool routing often looks temporary because the agent invokes a tool only when needed, but the permission path behind that invocation can still be standing and broadly reusable. That is a classic NHI governance blind spot with a new runtime wrapper. The named concept here is identity blast radius: the cumulative scope an agent can reach through its connected tools, even when each step appears narrow in isolation. Practitioners need to measure that radius, not just the model.

Agent teams turn delegated access into a coordination problem. When multiple agents share the same capability stack, the governance challenge is no longer a single subject calling a tool. It is a chain of execution where one agent's output becomes another agent's trigger. That increases the chance of overreach, especially when the same model or the same connector set is reused across roles. Security teams should evaluate team-level delegation as a control surface in its own right.

Least privilege for AI agents has to be defined at the tool layer. The article makes clear that the model is only the orchestrator. The real power sits in the services behind MCP servers and skills, which means the decisive governance question is who or what can call them, under what context, and with what persistence. Practitioners should align NHI policy to tool reach, because that is where operational authority actually lives.

From our research:

• 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.
• This matters because tool routing is expanding faster than governance, which is why the OWASP Agentic Applications Top 10 is the right next lens for control design.

What this signals

Identity blast radius: AI agents are now accumulating capability through the composition of tools, not just through model selection. That means security programmes need to understand how search, publishing, image generation, and code execution combine in a single delegated path, not just how each integration behaves on its own.

With 80% of organisations already reporting AI agents acting beyond intended scope, per AI Agents: The New Attack Surface, the operational lesson is clear: access review cycles designed for static entitlements will miss runtime tool chaining.

Tool routing should now be reviewed alongside the OWASP Agentic AI Top 10, because connector abuse, tool misuse, and agent overreach are no longer edge cases. Practitioners should prepare for governance models that can track delegated action, not just authentication events.

For practitioners

• Separate model choice from tool entitlement Maintain distinct approvals for model routing and tool routing. Allow teams to change LLM providers or task models without automatically widening access to search, publishing, code, or media tools.
• Scope every MCP server as a privileged connector Document each MCP server, the actions it can perform, and the credentials it uses. Apply least privilege at the connector level so an agent can only invoke the exact tool functions needed.
• Review tool combinations, not just individual permissions Assess how image generation, retrieval, publishing, and code execution compose when combined in one agent workflow. The main risk often appears when allowed tools are chained together.
• Bound agent-team delegation before scaling workflows If you use multiple agents, define which teammate can call which tool and under what conditions. Do not let every agent inherit the full tool suite by default.
• Map the identity blast radius of each workflow Trace the full path from agent trigger to final action, including tokens, APIs, and downstream services. Use that map to decide where access should be narrowed or separated.

Key takeaways

• Tool routing expands AI agent risk far beyond model selection because it governs what the agent can invoke, not just how it reasons.
• MCP servers and skills create capability boundaries, and weak scoping at that layer turns delegation into overreach.
• Security teams should separate model approvals from tool entitlements and measure the identity blast radius created by chained agent workflows.

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 Model Context Protocol endpoint that exposes tools, data, or actions to an AI agent in a structured way. In governance terms, it is a capability boundary that can widen identity blast radius if the exposed actions are not tightly scoped and monitored.
• Identity Blast Radius: Identity blast radius is the total scope of systems, data, and actions an identity can reach through its granted tools and credentials. For AI agents, it is not determined by one permission alone. It emerges from how tools, tokens, and delegation chains compose at runtime.
• Agent Team: An agent team is a coordinated set of AI agents that split work across roles such as research, drafting, or publishing. The governance issue is that access can be inherited across teammates, so one workflow may carry the full privilege set of several agents at once.

Deepen your knowledge

Tool routing, MCP scoping, and delegated capability boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing AI agents that can call external tools, it is worth exploring.

This post draws on content published by WorkOS: Model Routing vs Tool Routing: How to give your AI agents superpowers. Read the original.