Drift

Expanded Definition

In NHI security, drift is the gap between the approved, codified state of a service account, workload identity, secret, or agent and the state actually running in production. It matters because controls, approvals, and risk decisions are usually made against the declared state, while attackers exploit the live state.

Drift can appear in permissions, network paths, credential location, token scope, rotation settings, or even the presence of an unapproved identity. In practice, the term is used across infrastructure-as-code, IAM, and agentic systems, although definitions vary across vendors when policy, configuration, and runtime behaviour overlap. For a governance baseline, NIST Cybersecurity Framework 2.0 is the clearest external reference point for continuous monitoring and change detection.

At NHI Management Group, drift is best understood as a control failure in motion: the environment still “works,” but no longer matches the identity assumptions used to secure it. The most common misapplication is treating drift as a purely infrastructure issue, which occurs when teams ignore identity, secret, and authorization changes after deployment.

Examples and Use Cases

Implementing drift detection rigorously often introduces operational noise, requiring organisations to weigh tighter assurance against the cost of investigating every unexpected change.

• A workload identity gains broader cloud permissions than the IaC template allows, creating hidden privilege drift that bypasses the intended approval path.
• A secret is moved out of a vault into a CI/CD variable, and the live system still functions even though the control posture has degraded.
• An API token is rotated in code but not in every runtime dependency, producing partial remediation and a mismatch that persists until the next failure.
• An AI agent receives a new tool permission during emergency troubleshooting and the permission is never removed, leaving authorization drift behind the incident.
• The pattern behind the Salesloft OAuth token breach shows how unmanaged changes in tokens and access pathways can turn an acceptable configuration into a live exposure.

For identity-led use cases, drift also appears when service account sprawl outpaces review cycles. In those environments, policy documents become outdated faster than the systems they govern, which is why runtime checks and attestation matter more than annual audits. That same pattern aligns with broader identity guidance in Ultimate Guide to NHIs.

Why It Matters in NHI Security

Drift is dangerous because NHI compromise often starts with something small: a forgotten token, an excessive role, a stale certificate, or a secret left in the wrong place. NHIMG research shows that 96% of organisations store secrets outside secrets managers, 97% of NHIs carry excessive privileges, and only 5.7% have full visibility into their service accounts. Those conditions make drift both common and hard to spot.

Once drift exists, attackers do not need to break the intended design. They only need to find the live exception. That is why drift management must cover inventory, entitlement review, secret rotation, offboarding, and continuous comparison between code and runtime. It also maps to the operational discipline described in Ultimate Guide to NHIs, where visibility and lifecycle control are central to reducing NHI risk.

Organisations typically encounter the impact of drift only after an access review, incident, or breach reveals that the environment no longer matches the approved control set, at which point drift 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