Model routing vs agent policy: where should each control sit?

TL;DR: Model routing and agent-turn policy solve different problems, according to Archestra: one chooses the cheapest capable model, while the other governs who can call which tools, what the agent can see, and how the turn is audited. Collapsing them creates a false control boundary and can leave an unguarded tool surface.

Editorial analysis by NHI Mgmt Group, based on content published by Archestra: “Martian router Archestra: cost-aware model routing, identity-aware tool policy”.

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.

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

A: Cheaper model selection only affects inference spend and model fit.

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.

Practitioner guidance

• 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.

Bottom line: Model routing and agent governance solve different problems, and mixing them creates a false sense of control.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →