The warning signs are uncontrolled fallback to cheaper models, unclear handling of sensitive prompts, tool calls that vary by application instead of policy, and no evidence that routing exceptions are reviewed. If different teams are making ad hoc decisions about where requests go, the gateway has become a convenience layer rather than a governed control.
How to tell when routing has stopped being a policy
Weak routing shows up when the gateway reacts to cost or convenience first and governance second. If requests are sent to different models based on whichever team touched the code, or if sensitive prompts can be downgraded without a defined rule, the routing layer is no longer enforcing a shared decision standard. It is merely relaying traffic.
A healthy routing policy should make the same decision for the same class of request, with exceptions handled deliberately and recorded. That means the policy should define what inputs matter, what sensitivity triggers a higher-assurance path, and who can approve deviations. If those decisions live in application code, support tickets, or informal team preference, the routing control is too weak to trust.
Where weak routing creates the most exposure
The biggest exposure is not just model choice, it is loss of control over what reaches each model and why. A weak policy can send confidential prompts to a lower-trust model, allow tool-enabled requests to bypass stricter handling, or create inconsistent outcomes for the same user action across applications. That inconsistency is usually the first sign that the organisation cannot prove governance over the path requests take.
It also creates blind spots in review and accountability. If exceptions are not tracked, you cannot tell whether fallback routing is a temporary failure mode or a permanent shadow policy. Security Policy Framework Guide is useful here because weak routing is often really a policy-structure problem: rules, exceptions and review cycles must be explicit or the control degrades into ad hoc practice.
What stronger routing control looks like in practice
Stronger routing is policy-led, not team-led. The policy should classify request types, define when a prompt must stay on a higher-trust path, and state whether cost-based fallback is allowed at all for sensitive workflows. It should also make routing exceptions observable, so the organisation can review who overrode the default and whether that override was justified.
For AI-specific governance, the policy should also cover approved tools, human review points, and the handling of sensitive data. AI Acceptable Use Policy Template helps anchor those expectations, while Agentic AI Security Policy Template is the better fit when routing decisions affect autonomous agents, high-impact actions, or tool use.
Risk and Threat Considerations
Weak routing policies create governance drift, and in AI systems that drift quickly becomes security exposure. The practical danger is not only accidental misrouting, but also deliberate abuse of permissive paths, because an attacker or insider can try to steer sensitive work toward a cheaper, weaker, or less monitored path.
Failure mechanism: The control fails when routing logic is implemented as scattered application behaviour instead of a single governed policy with enforced defaults, sensitivity rules, and exception review.
Impact: Sensitive prompts may be processed under the wrong trust conditions, tool calls may escape consistent oversight, and the organisation may be unable to demonstrate which decisions were policy-driven versus improvised.
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 addresses the attack surface, NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Routing policy weakness can let requests and tool use bypass governed trust and privilege boundaries. |
| Recommendation — Enforce policy-controlled routing paths so tool-enabled actions cannot bypass governed approval and review. | ||
| NIST AI RMF | GOVERN — Govern | The question is about AI governance over routing decisions, exceptions, and accountability. |
| Recommendation — Define routing accountability, approval criteria, and exception handling as part of AI governance. | ||
| ISO/IEC 42001:2023 | A.6.2 — AI objectives and planning to achieve them | Routing policy needs defined objectives, criteria, and oversight to stay governed. |
| Recommendation — Set routing objectives and review criteria so model selection stays aligned with defined AI governance goals. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy Establishment | Routing weakness is fundamentally a policy design and enforcement gap. |
| Recommendation — Establish and maintain a formal routing policy with clear decision rules and exception handling. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Routing policies govern which requests get which level of access, scrutiny, and handling. |
| Recommendation — Restrict routing paths so sensitive requests cannot be downgraded by default or convenience. | ||
Practitioner Guidance
What to verify: Check whether routing decisions are centrally defined, whether exceptions are logged with an owner and reason, and whether the same request class produces the same destination across applications. If the answer depends on the team that built the app, the policy is too weak.
Decision rule: If a route can expose sensitive prompts, privileged tools, or regulated data to a lower-assurance model, treat that route as a governed exception, not a performance optimisation. If no one can explain why an exception happened, assume the control is incomplete until proven otherwise.
Practitioner takeaway: The key test is whether routing still behaves like a policy when cost, urgency, or team preference would make a shortcut attractive. If it does not, you do not have routing governance, you have discretionary routing.