How should teams separate model routing from agent access control?

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.

Separate routing decisions from access decisions

Model routing and agent access control solve different problems and should be designed by different rules. Routing decides which model instance or provider to use for a workload, so it belongs in performance, resilience, and spend management. Agent access control decides whether a caller may reach a tool, dataset, or context window, which is an authorization decision with security consequences.

Keeping those layers apart avoids a common failure mode: a routing service that quietly accumulates policy authority. If the same component chooses the model and also decides what an agent may do, teams blur operational optimisation with security enforcement and make it harder to prove why a specific action was allowed.

For the access side, the useful mental model is externalised authorisation: the policy decision should be made from caller identity, request attributes, and resource sensitivity, not from whichever model the router happened to choose. That is why a routing layer can be interchangeable while access policy remains stable and auditable.

What belongs in the router, and what does not

The router should be free to select among models based on latency, quality, cost, region, availability, or task fit. It may also handle failover and provider health. Those are operational concerns, and they can change often without changing who is allowed to act or what data may be exposed.

What the router should not own is tool entitlements, context scoping, or approval gates. If the router starts trimming tool lists or expanding context based on model choice, policy becomes coupled to an infrastructure decision. That creates hidden behavioural drift, because a model swap can unintentionally change the agent’s effective authority.

This separation is especially important when different model classes are used for different trust levels. A lightweight classifier, a premium reasoning model, and a private in-house model may all serve the same agent, but they should inherit the same access policy unless there is an explicit, separately governed reason to vary it.

NHIMG’s Authorisation Models Guide is useful here because it helps teams choose policy patterns for people, workloads, and AI agents without confusing that choice with model selection.

How to keep policy observable and auditable

Audit quality improves when routing decisions and access decisions are logged separately. A routing record should show which model was chosen and why. An access record should show the caller, policy inputs, resource decision, and any approval or denial. When those records are mixed, investigators have to reconstruct policy from side effects rather than from the decision point itself.

Separate logs also make exception handling safer. If a team grants temporary tool access for one agent flow, that exception should be visible as an access event with expiry and owner, not as an implicit side effect of a routing rule. The same principle applies when a model fallback occurs: the fallback should not silently widen context or permissions.

When access policy and routing are split cleanly, it becomes much easier to answer a basic question during review: did the model change, or did the authority change? That distinction matters for incident response, compliance evidence, and post-deployment assurance.

NHIMG’s AI Agent Observability, Audit and Incident Response Guide supports that separation by showing how to attribute agent actions and retain evidence that distinguishes control-plane decisions from model behaviour.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Access to tools and context should be limited by policy, not routing choice.
	IA-9 — Service Identification and Authentication	Agent and workload access depends on strong authentication before policy decisions apply.
	AU-3 — Content of Audit Records	Separate routing and access logs are needed to explain why a request was allowed.
Recommendation — Enforce least privilege at the access layer so routing cannot change tool authority. Authenticate the agent or service before evaluating any tool or context request. Log routing and access decisions separately so audits can distinguish optimisation from authorization.
ISO/IEC 27001:2022	A.5.15 — Access control	The subject is about separating access decisions from routing and keeping policy explicit.
Recommendation — Define access control independently from model selection rules.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Cloud and agent access governance must stay distinct from execution routing logic.
Recommendation — Keep IAM policy separate from model routing and enforce it at the control point.

Practitioner Guidance

What to prioritise: Put the policy boundary at the access layer first, then let routing optimise execution inside that boundary. If a routing change can alter permissions, you have not separated the functions yet.

What to verify: Confirm that tool access, context visibility, and approval logic are evaluated independently of model selection. A good test is whether you can replace the model without changing the access decision for the same request.

Common mistake: Teams often let the router “help” by pruning tools or exposing extra context for certain models. That shortcut looks convenient, but it creates policy drift and makes audit evidence ambiguous.

Practitioner takeaway: Treat model routing as an execution choice and agent access control as a security decision. If those two layers are coupled, every optimisation becomes a potential privilege change.