For production use, agent identity and access governance should come first because they control what the system can touch. Model routing matters for performance and model choice, but it does not limit delegated action, which is where enterprise exposure usually begins.
Why agent identity should be prioritised before model routing
agent identity is the control point that decides what an autonomous system can access, change, or delegate. That means it governs blast radius, privilege boundaries, session behaviour, and accountability before the model even enters the decision path. Model routing still matters, but it is downstream of the more consequential question: who or what is allowed to act.
When organisations treat routing as the first design decision, they often optimise for latency, cost, or model quality while leaving delegated authority loosely defined. The safer order is to establish the agent’s identity, credentials, and access boundaries first, then route tasks to the appropriate model inside those limits. For practical identity design patterns, the Agentic AI Identity Guide is the most direct starting point.
That order also explains why agent identity is not just an implementation detail. If an agent can retrieve data, call tools, or trigger workflows under broad standing access, the model selection only changes how the work is performed, not whether the work should have been permitted at all. In enterprise environments, that distinction is usually what separates a contained system from one that can create cross-system exposure.
What model routing does, and what it does not do
Model routing is about choosing which model handles a request, often based on task type, risk, cost, speed, or capability. It can improve quality and efficiency, and it can reduce unnecessary use of more powerful models. It does not, by itself, define the authority to read customer records, send messages, approve actions, or invoke external systems.
That is why routing should be treated as a control within an already-governed operating model, not as the control that creates governance. A strong route can send a task to a safer or cheaper model, but if the agent has overbroad permissions, the wrong task can still produce real-world impact. Routing becomes useful only after the identity layer has narrowed what the agent is allowed to do.
This is also where organisations should be careful about confusing model safety with access safety. A well-routed model can still execute harmful or unauthorised actions if the surrounding agent has excessive delegation, weak tool permissions, or reused credentials. Conversely, a tightly governed agent can limit damage even when the routing logic is imperfect.
What changes when identity comes first
Putting identity first changes the architecture in three practical ways. First, permissions become explicit and reviewable, which means the team can define which tools, APIs, and data scopes are acceptable before any routing logic is added. Second, access can be scoped to the minimum needed for the task, instead of being inherited from convenience. Third, incident response becomes more precise because the organisation can attribute actions to a bounded agent identity rather than to a generic application path.
This is especially important for delegated workflows, where an agent may act on behalf of a human or another system. In those cases, the question is not just which model was used, but whether the delegated identity was authenticated, authorised, and constrained appropriately. The Ultimate Guide to NHIs, Why NHI Security Matters Now is useful for understanding why this governance layer has become a priority across machine and agent populations.
It also matters because agent identity is where compromise often begins. If attackers can steal tokens, reuse sessions, abuse default credentials, or exploit overprivileged access, routing choices become irrelevant. The system will still route a request, but now it will do so under a compromised authority. For a concrete example of how exposed credentials and agent identity failures translate into breach conditions, see Moltbook AI agent keys breach.
Risk and Threat Considerations
When model routing is prioritised before identity governance, the organisation can end up optimising model choice while leaving the real attack surface untouched. The exposure is not the model decision itself, it is the delegated access that lets an agent reach sensitive systems, secrets, or business actions. That creates a wider blast radius if the agent is misused, hijacked, or overtrusted.
Failure mechanism: An agent with broad standing access can be redirected, manipulated, or compromised even if the routing layer selects a benign or high-quality model. The routing decision does not stop tool abuse, credential theft, consent phishing, or privilege escalation.
Impact: The result can be unauthorised data access, unwanted side effects in business systems, and difficult incident containment because the action looks like a permitted agent operation rather than an obvious intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent identity depends on secure authentication and delegated access. |
| NHI-05 — Overprivileged NHI | The question is about limiting what an agent can touch before routing choices matter. | |
| NHI-07 — Long-Lived Secrets | Agent identity risks rise when credentials outlive the task or session. | |
| Recommendation — Use secure authentication and delegated access flows for every agent identity. Minimise agent privileges before adding routing or orchestration logic. Replace long-lived agent secrets with short-lived, scoped credentials. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The main issue is whether an agent's authority is bounded before it acts. |
| Recommendation — Constrain agent identity and privilege before allowing model routing to execute tasks. | ||
Practitioner Guidance
What to prioritise: Define agent identity, delegated authority, and tool permissions before optimising model selection. If an agent can reach production data or trigger external side effects, treat access governance as the prerequisite control.
What to verify: Confirm that each agent has a unique identity, bounded credentials, and a clear scope for tool invocation and data access. If routing changes do not alter those permissions, they should be treated as an optimisation layer, not a security boundary.
Practitioner takeaway: The safest design order is identity first, routing second, because the damage comes from what the agent can do, not from which model it uses to do it.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations prioritise secrets rotation or agent identity design first?
- When should organisations prioritise agent identity controls over model tuning?
- What should organisations prioritise first for AI agent identity risk: visibility or credential reduction?