Routing Drift

Expanded Definition

Routing drift describes the slow, often unnoticed movement of an agent, workflow, or request stream away from its intended execution path. In NHI and agentic AI governance, it shows up when model selection, tool access, escalation logic, or fallback behavior is left to convention instead of explicit policy. Definitions vary across vendors, but the operational meaning is consistent: the system still works, yet it no longer behaves the way architects intended.

That distinction matters because routing is not just a technical decision. It determines which model sees the prompt, which credentials are available, whether MCP-connected tools can be invoked, and whether the workload stays inside a Zero Trust Architecture as described in NIST Cybersecurity Framework 2.0. When routing drifts, governance gaps appear in access control, logging, and reviewability, even if the application continues to return valid outputs. The most common misapplication is treating a cost-based fallback or exception path as harmless, which occurs when teams allow unreviewed overrides to accumulate under production pressure.

Examples and Use Cases

Implementing routing controls rigorously often introduces latency and operational friction, requiring organisations to weigh consistent governance against faster or cheaper execution paths.

• An AI assistant routes routine questions to a low-cost model, then silently begins sending sensitive prompts there as exception rules pile up.
• A customer-support agent with tool access starts bypassing the intended approval path because a fallback route was left enabled after testing.
• A workflow that should use a narrowly scoped service account instead calls a broader identity after the primary path times out, expanding blast radius.
• A security team discovers that routing changed after a price optimisation rollout, echoing the failure pattern seen in the Salesloft OAuth token breach, where token handling and trust boundaries were not tightly governed.
• Engineering teams align routing policy with NIST Cybersecurity Framework 2.0 to keep identity, access, and monitoring controls consistent across each execution path.

In practice, routing drift is most visible when operators discover that the “normal” path is no longer the default path. The difference between intended and actual routing is often small in code, but large in governance impact.

Why It Matters in NHI Security

Routing drift turns policy into a moving target. Once requests start taking unintended paths, least privilege becomes harder to enforce, audit trails become fragmented, and incident response teams can no longer assume that a given task used the same model, tool, or credential set every time. That is especially dangerous for agents with execution authority, because a minor routing change can alter the secrets they can reach, the NHI they impersonate, or the approval boundary they cross.

The risk is not theoretical. NHI Mgmt Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, which means drifted routes can continue to operate long after defenders think they have contained an issue. Routing discipline also supports the intent of NIST Cybersecurity Framework 2.0, because identify, protect, and detect functions depend on knowing which path was taken and why. Organisations typically encounter routing drift only after an access review, incident, or unexpected bill reveals that the system has been executing along an unapproved path, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift
• Privilege Drift