Workflow Drift

Expanded Definition

Workflow drift is the gradual gap between an approved access or provisioning workflow and the version actually running in production. In NHI operations, it often appears when automation changes, AI-generated logic, or emergency exceptions bypass approvals, edge cases, or revocation steps. Industry usage is still evolving, but the core idea is consistent: the process no longer matches the control intent. Under NIST Cybersecurity Framework 2.0, this maps to governance, access control, and continuous monitoring expectations rather than a standalone identity category. Drift is especially dangerous in workflows that issue or renew secrets, because the surrounding control process may look compliant while silently skipping the steps that prevent overprovisioning. The most common misapplication is treating workflow drift as a one-time configuration error, which occurs when teams fix the visible policy but leave the underlying automation path unchanged.

Examples and Use Cases

Implementing workflow controls rigorously often introduces slower change cycles, requiring organisations to balance delivery speed against assurance that every provisioning path still enforces approvals and revocation.

• An AI assistant generates a service-account onboarding flow that creates credentials but forgets the exception path for blocked regions, so an approved access request becomes a shadow process.
• A CI/CD pipeline adds a temporary bypass during an outage and never removes it, allowing repeated issuance of tokens outside normal review. That pattern is similar to the failures seen in the Salesloft OAuth token breach, where token handling and access control breakdowns became operationally exposed.
• A provisioning workflow for an API key rotates credentials on schedule, but the downstream inventory system is not updated, so expired credentials continue to be treated as active.
• Exception handling for emergency access is documented in policy, yet the production workflow omits the approver notification step, creating a silent approval gap.

These cases are easier to detect when the organisation compares intended control design with runtime evidence, not just tickets or policy text. The same discipline appears in the NIST Cybersecurity Framework 2.0, which expects organisations to verify that protection activities continue to operate as intended after changes.

Why It Matters in NHI Security

Workflow drift matters because NHI risk is usually created by accumulated process exceptions, not a single bad decision. When access workflows diverge from approved design, organisations lose trust in the controls that govern service accounts, API keys, and agent permissions. That loss of trust can expose overprivileged identities, missed revocations, and unauthorised persistence even when the written policy appears sound. NHI Mgmt Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which means workflow drift often lands directly in the revocation gap. It also reinforces why governance must include runtime verification, not just policy review, especially when automation or AI agents modify identity operations. For broader remediation context, the exposure patterns discussed in Salesloft OAuth token breach show how quickly token handling failures can turn into enterprise-wide access risk. Organisations typically encounter workflow drift only after a breach, failed audit, or privilege review exposes the gap, 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?
• How should organisations secure workflow platforms that handle both files and secrets?
• Why do workflow engines create such a large blast radius for attackers?