Model routing and agent policy are separate control layers

At a glance

What this is: This is an analysis of why a model router and an agent security gateway must be treated as separate layers, with different scopes, state, and failure modes.

Why it matters: It matters because IAM and NHI teams cannot treat cost optimisation as a substitute for tool authorisation, context control, or auditability in agentic systems.

Context

The core governance gap is assuming that cost-aware model selection also controls what an agent is allowed to do. In practice, the router decides which model to call, while the security layer decides who the caller is, what tools are in scope, and what the agent may see or invoke.

That separation matters because agentic systems create a new identity boundary around the turn itself, not just around the model request. A router optimises inference spend; it does not enforce per-user tool entitlements, quarantine untrusted tool output, or broker MCP access.

Key questions

Q: How should teams separate model routing from agent access control?

A: Treat model routing as a cost and performance function, and treat agent access control as an identity and policy function. The router should choose a model, but it should not decide which tools the caller may use or what context the agent may see. Keeping those decisions separate reduces the risk of policy drift and makes audit evidence easier to interpret.

Q: Why does cheaper model selection not solve agent security risk?

A: Cheaper model selection only affects inference spend and model fit. It does not address who is authorised to call the agent, which tools are exposed, or whether tool output can poison the next step in the conversation. Those risks sit at the agent boundary, so a router cannot eliminate them by design.

Q: What breaks when a router is treated as the only gateway for tools?

A: The tool surface becomes effectively ungoverned because the routing layer lacks per-user entitlement, sandboxing, and turn-level policy enforcement. That means the organisation may still have a clean model-cost log while the agent is allowed to see or invoke tools it should not touch.

Q: What should security teams audit in an agent stack with a model router?

A: Audit the identity of the caller, the tool list exposed on that turn, the tools actually invoked, and the model chosen for the request. Those records show whether a failure happened in routing, authorisation, or context handling, which are separate control problems.

Technical breakdown

Why model routing and tool authorisation are different control planes

A model router solves an economic and performance problem: choose the cheapest capable model for a prompt, often with fallback logic and cost-aware scoring. Tool authorisation solves an identity problem: determine which tools a specific caller can invoke, which context the agent may see, and what downstream actions are permitted. These are different planes because the state, policy inputs, and failure modes differ. A router can know prompt cost and model quality, but it has no native concept of per-user entitlement, MCP scoping, or turn-level trust. Conflating them turns a routing decision into a weak access control decision. Practical implication: keep model selection and agent authorisation in separate control paths. See the Identity Security Programme Guide.

Practical implication: Do not let cost optimisation logic decide access scope for agent actions.

Why MCP gateways belong at the agent boundary, not the model router

MCP introduces a tool layer that sits beyond model selection. The agent may read a tool response, decide on the next action, and then invoke another tool based on that response. That sequence needs a gateway that understands identity, allowlists, sandboxing, and decision logging. A model router has none of that state by design. If it is used as the only front door, tool access becomes an application concern with no dedicated policy enforcement point. That is how organisations end up with logs that show a cheap model was used, but no proof that the right tools were exposed to the right caller. Practical implication: place per-identity MCP controls in front of the agent turn, not behind the model call. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Enforce MCP allowlists and sandboxing before any tool invocation is possible.

Why prompt-injection defence is not a routing feature

Prompt injection is a context integrity problem, not a model-selection problem. The harmful content may arrive through a tool response, a document, or another external input that the agent is about to trust. A router can compare models and costs, but it does not inspect or quarantine tool output before it enters the agent context. That is why a security layer needs to isolate untrusted content, verify what is allowed to reach the main agent, and record the decision trace. Treating the router as the defence layer creates a blind spot where adversarial content can still rewrite the agent's next step. Practical implication: evaluate context filtering and tool-output quarantine separately from routing behaviour.

Practical implication: Quarantine untrusted tool output before it reaches the agent context.

NHI Mgmt Group analysis

Cost-aware routing and agent governance are orthogonal control problems. One optimises inference spend, the other constrains what an identity-bound agent can see and do. The article correctly separates those responsibilities, and that separation is the point: a cheaper model does not reduce the need for per-turn authorisation, MCP scoping, or auditable tool access. Practitioners should read this as a warning against collapsing performance controls into identity controls.

Agent turn security is a governance boundary, not a model feature. The meaningful unit is the turn on behalf of a specific human or workload, not the model request itself. That means entitlement, context exposure, and tool invocation need to be evaluated at the turn boundary, where the identity decision actually happens. Cost logic belongs upstream of that boundary, not inside it.

Identity does not select tools dynamically on its own, but the agent turn does create a live access decision. The assumption that a routing layer can also police access is flawed because the routing layer was designed for model choice, not for tool entitlement, context quarantine, or audit traceability. The implication is that teams must treat model routing as a separate control plane and stop expecting it to absorb NHI governance duties.

Untrusted tool output creates a context-risk channel that routing cannot see. The interesting security problem here is not whether the model was cheap, but whether a malicious response from a tool can influence the next action. That requires a control that sits between tool output and agent context, because inference routing has no visibility into that boundary. Practitioners should map this to agentic trust boundaries, not to spend management.

Read next: Identity Security Programme Guide

What this signals

Control-plane separation will become a baseline requirement: as agent stacks mature, teams will have to prove that cost optimisation never governs identity-bound tool access. The practical test is simple: can you show that model choice changed independently of authorisation, without leaking policy into the wrong layer?

This pattern also signals that agent security programmes need to move from model-centric conversations to turn-centric governance. The right question is no longer which model is cheapest, but which boundary proves that the agent only sees the tools and context its caller is entitled to use.

For practitioners

• Separate routing from authorisation Keep model-selection logic in one service and per-identity tool policy in another so cost optimisation cannot expand access scope.
• Enforce turn-level tool allowlists Resolve the tools visible to the agent from the caller's identity and session context before any invocation is exposed.
• Quarantine untrusted tool output Route external or adversarial tool results through a containment step before they can modify the agent's active context.
• Audit identity, tools, and model choice separately Record who called the agent, which tools were considered and invoked, and which model handled the request so reviews can distinguish policy failure from routing behaviour.

Key takeaways

• Model routing and agent governance solve different problems, and mixing them creates a false sense of control.
• The security boundary sits around the agent turn, where identity, tool access, and context exposure are decided.
• Practitioners need separate evidence for routing behaviour and policy enforcement if they want trustworthy audit trails.

Related NHI Mgmt Group resources: Identity Security Programme Guide · NHI Lifecycle Management Guide · AI Agent Identity Security Buyer's Guide

Key terms

• Model Router: A model router is an aggregation layer that lets applications access multiple LLM providers through one interface. It primarily simplifies integration and model selection, but it does not by itself provide enterprise governance, policy enforcement, or compliance control.
• Agent Turn: A single end-to-end cycle in which an AI agent receives input, reasons, calls tools, and returns output. For security evaluation, the turn is more useful than the event because it captures the full amplification effect of multi-step reasoning and repeated tool use.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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.