Start by mapping every route the model can take, including fallback paths, platform-specific behavior and any policy trigger that changes the response. Then confirm that audit logs, approvals and access controls still reflect the actual path used, not just the nominal model ID. If the fallback can change what the model is allowed to do, govern the path as tightly as the model itself.
Why fallback behavior changes the control problem
Fallback behavior matters because it can change the real request path, the effective permissions, and the evidence you rely on to review the system later. If a model can route traffic differently by platform, policy trigger, or availability state, then “the model” is no longer one stable control point. The first job is to make the alternate path visible before you decide how to govern it.
That means treating fallback as part of the model’s operating design, not a rare exception. If a fallback route can call different tools, access different data, or return different classes of response, the security review has to cover that route explicitly. Teams often miss the mismatch between the nominal model ID and the actual execution path, especially when the fallback is handled in orchestration rather than inside the model itself.
For AI systems with broader threat modelling needs, MITRE ATLAS Guide is useful for mapping how model behavior, routing changes, and adversarial conditions can alter the attack surface.
How to map the actual request path before trusting the model
Start by inventorying every route that can process the request, including the primary model, backup model, policy-gated branch, vendor-specific fallback, and any response transformation layer. The practical question is not just “which model was called?”, but “which system path actually handled the request and under what condition did it switch?”
Once the paths are mapped, compare them for differences in logging, approval steps, content filtering, retrieval access, and downstream action authority. A fallback that only changes formatting is a different problem from one that changes tool access or decision rights. If one path can approve, suppress, enrich, or reframe outputs differently, then the path itself is part of the control boundary.
That path review should also include human review points and exception handling. If a policy trigger can divert requests to a less capable or less governed route, make sure the trigger is deterministic, documented, and observable. Otherwise teams end up with policy drift, where the system silently behaves one way during testing and another way under load, quota pressure, or safety fallback.
For governance of those decision points, the AI Governance Guide helps frame route ownership, approval logic, and oversight as part of the operating model.
For posture and configuration review across the AI stack, the AI Security Posture Management (AI-SPM) Guide is relevant when the fallback path changes how models, keys, or workloads are configured.
What teams must verify when fallback changes request handling
The key verification step is to compare the intended control path with the observed one. Audit logs should record the actual model or route used, approvals should apply to the route that executed, and access controls should reflect the permissions of that route rather than a generic model label. If that evidence does not line up, the team cannot honestly say it knows how the request was handled.
Teams should also verify whether the fallback path creates a privilege change. A route that is allowed to bypass retrieval, use broader context, or call additional tools can turn a harmless failover into an authorization change. That is why the path needs the same scrutiny as the model: fallback can be an operational feature, but it can also become a control bypass if it is not governed.
When the fallback introduces new tooling, API calls, or cross-service access, review the request as an access decision rather than only as a model-selection decision. The strongest systems do not merely survive fallback, they prove that fallback cannot expand authority without detection and review.
For model-level abuse and inference controls, the AI Model Security Guide is useful when fallback changes inference behavior, output handling, or endpoint exposure.
Risk and Threat Considerations
Fallback paths create exposure when they are less visible, less logged, or less constrained than the primary route. Attackers and abusive users benefit from ambiguity, because a hidden branch can offer weaker filtering, broader permissions, or a different policy outcome than the one defenders expect.
Failure mechanism: The system silently routes requests to an alternate model, vendor path, or policy branch that has different access rights, weaker logging, or looser controls than the nominal path.
Impact: Teams lose confidence in audit evidence and may miss unauthorized access, unsafe output handling, or privilege expansion that only appears under fallback conditions.
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 and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Fallback paths must be logged on the actual executed route. |
| AC-6 — Least Privilege | Fallback may change effective permissions and must stay constrained. | |
| IA-2 — Identification and Authentication (Organizational Users) | Request handling changes often hinge on who or what is authenticated to act. | |
| Recommendation — Log the routed path, approval state, and model used for every fallback decision. Limit fallback routes to the minimum permissions needed for their function. Authenticate the actor behind each request path before allowing privileged handling. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Fallback can shift agent authority or expose a stronger execution path. |
| Recommendation — Prevent fallback branches from inheriting broader agent privileges than intended. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Fallback routing changes operational and security risk that must be governed. |
| Recommendation — Include fallback behavior in the system's risk treatment and oversight decisions. | ||
Practitioner Guidance
What to prioritise: Treat the routing map as the first artifact, not the final model card. If you cannot enumerate the fallback branches, you cannot judge whether the response path is actually governed.
What to verify: Confirm that logs, approvals, and access checks are attached to the executed path, not only to the advertised model name. If the fallback path can change allowed actions, require the same review standard as the primary path.
Practitioner takeaway: The important control question is not whether the model has a fallback, but whether fallback can change authority without changing the governance evidence.
Related resources from NHI Mgmt Group
- What should teams review first when adding AI to an existing security model?
- How should security teams govern AI agents when model pricing changes?
- How should security teams respond when an AI model exposes its system prompt on request?
- How should AI teams use copilots to speed up debugging without losing control of model changes?