The main failure is that capability selection becomes part of the agent’s live behaviour rather than a fixed design choice. That makes static entitlements too blunt, because the real risk is not only what the agent can do, but which reasoning tier it can invoke for each task. Governance has to cover runtime selection, not just initial access.
Runtime Model Choice Changes the Control Point
When an agent can choose models during execution, the security question shifts from “who can use the agent” to “what capability can the agent invoke right now.” That breaks a fixed-permission mindset. A task that is harmless with one model tier can become materially different with a more capable reasoning model, a higher-context model, or a model with tool-calling behavior that changes the agent’s effective authority.
This is why runtime model selection is not just an optimisation detail. It creates a moving trust boundary inside the workflow, so the control must follow the decision point rather than stop at account provisioning. If the agent can swap to a stronger model for a sensitive task, governance has to understand that selection logic as part of the security posture.
Why Static Entitlements Stop Being Enough
Traditional entitlements assume the service principal, application, or agent identity has a mostly fixed capability set. Runtime model choice breaks that assumption because the same identity may produce very different outcomes depending on the model it selects. The practical result is that least privilege must be expressed at the decision level, not only at the identity level.
That is especially important where model choice affects reasoning depth, tool use, content exposure, or access to internal context. A model router that can silently upgrade capability is functionally a privilege escalation path if the higher tier can influence approvals, generate actions, or interpret more sensitive data. The control question becomes whether the agent is allowed to select that model for that task class, under that policy, and with what oversight.
In identity terms, the important issue is not the existence of a token or login alone, but the runtime authorization around capability switching. AI Agent Authorisation Guide is directly relevant here because task-scoped and per-action decisions are the right mental model when capability can change mid-run. The broader distinction between agent forms also matters, because AI Agents vs Agentic AI helps frame how autonomy changes as orchestration becomes more dynamic.
What Needs to Be Governed at Runtime
At runtime, the system needs policy on three separate things: which models are eligible, what triggers a switch, and who or what can approve the switch. Without that, model choice becomes an implicit privilege path hidden inside orchestration code or routing logic. The safest designs treat model selection as a governed action with logging, policy checks, and blast-radius limits.
That means the routing layer should be reviewed like any other authorization decision point. If a model change can alter output quality, memory access, tool invocation, or safety behaviour, then the router is part of the control plane, not a convenience layer. Zero Trust for AI Agents fits this pattern because it emphasizes verifying the agent, principal, and request per action instead of assuming a one-time grant is enough.
The issue also extends to observability. If the selected model is not recorded, teams cannot reconstruct why the agent behaved differently, which tier handled a task, or whether a capability boundary was crossed. That is why AI Agent Observability, Audit and Incident Response Guide is useful here: model-choice events are part of the audit trail, not just debugging noise.
Risk and Threat Considerations
Runtime model choice creates a privilege-escalation surface because the agent can steer itself toward a more capable reasoning path when the task becomes harder, more sensitive, or more exploitable. If that selection is not governed, an attacker can aim for the route that unlocks stronger tool use, more context, or weaker scrutiny.
Failure mechanism: The routing policy is treated as an implementation detail, so the agent can select higher-capability models without a separate authorization decision, context-aware approval, or reliable audit record.
Impact: The same identity can produce different security outcomes across runs, which weakens least privilege, complicates incident reconstruction, and can turn model selection into a hidden escalation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime model switching can change the agent's effective authority. |
| Recommendation — Require explicit policy for any model swap that increases authority or capability. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent model routing and tool use depend on authenticated service interactions. |
| AC-6 — Least Privilege | Dynamic model choice can silently expand what the agent can do. | |
| Recommendation — Authenticate model and tool interactions before permitting runtime capability changes. Limit runtime model options to the minimum capability needed for the task. | ||
| NIST Zero Trust (SP 800-207) | PA-12 — Application/Workload Identity | Zero trust requires per-request verification when runtime capability changes. |
| Recommendation — Verify each model-selection request before allowing a capability upgrade. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A runtime model picker can create excess effective privilege for an agent. |
| Recommendation — Constrain agent model choices so higher-capability paths require approval. | ||
Practitioner Guidance
What to verify: Confirm that model selection is policy-controlled and logged as a first-class security event, not inferred from application code or vendor defaults. The record should show which task class triggered the choice, what policy approved it, and whether any human approval was required.
Decision rule: If a higher-tier model can change tool access, data exposure, or decision quality for a task, require explicit authorization for that switch. If the only difference is cost or latency, treat it as an operational optimisation rather than a security decision.
What practitioners underestimate: Teams often secure the initial agent login and miss the dynamic capability boundary created by routing. The real control objective is to keep model choice observable, bounded, and justifiable at the moment it changes the agent’s effective authority.
Practitioner takeaway: Runtime model selection should be governed like runtime privilege, because the security boundary has moved from “who is the agent” to “what capability did the agent just invoke.”