Why is user-borrowed access risky for cloud workloads?

Because the service’s effective permissions become whichever entitlements the user already has, rather than the permissions the task actually needs. That turns a workload into an extension of human privilege and expands blast radius whenever the user is over-privileged.

Why This Matters for Security Teams

User-borrowed access turns a cloud workload into a proxy for human entitlements, which is dangerous because workloads do not behave like users. A service may only need one API call, but if it inherits the user’s full session or group membership, it can read data, invoke admin functions, or move laterally far beyond the task’s actual scope. That breaks least privilege and makes incident containment much harder.

This is one reason NHI governance keeps showing up as a separate discipline from human IAM. NHI Management Group’s research on Ultimate Guide to NHIs – Key Challenges and Risks highlights how quickly workload access becomes inconsistent once identities are shared, inherited, or reused across environments. The same pattern appears in the 2024 Non-Human Identity Security Report: 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which is a warning sign for any team relying on user-borrowed access.

Current guidance from the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 points toward workload-specific identity and explicit authorization rather than inherited human privilege. In practice, many security teams discover the risk only after a workload has already been used to access something the original user was never meant to delegate.

How It Works in Practice

The safer pattern is to give the workload its own identity and authorize it for the task, not for the user’s standing privileges. That usually means workload identity, short-lived credentials, and policy evaluated at request time. Instead of borrowing a user’s session, the workload presents proof of what it is and what it is trying to do. In modern environments, that proof often comes from mechanisms described in the SPIFFE workload identity specification, where identity is cryptographic and workload-scoped rather than manually assigned.

In operational terms, teams should separate authentication from authorization:

• Issue a workload identity to the service, not a shared user token.
• Use just-in-time, short-lived credentials for each task or session.
• Evaluate policy at runtime with context such as service, destination, time, and action.
• Revoke or expire access automatically when the task completes.

This approach aligns with the NHI-specific guidance in NHI Management Group’s Guide to SPIFFE and SPIRE and with the control logic in the OWASP Non-Human Identity Top 10. It also fits NIST’s zero-trust direction, where access is not assumed from network location or inherited trust. For cloud workloads, this is especially important when automation chains multiple tools, because each hop can amplify a borrowed permission into a much larger blast radius. These controls tend to break down when teams reuse human SSO sessions inside CI/CD or orchestration flows because the workload inherits privileges it cannot safely justify.

Common Variations and Edge Cases

Tighter workload authorization often increases operational overhead, requiring organisations to balance security gains against deployment complexity. That tradeoff is real, especially in hybrid cloud, legacy automation, and fast-moving delivery pipelines where teams want a simple way to make things work. But current guidance suggests that convenience-based borrowing is only acceptable when the resulting scope is narrowly bounded and tightly monitored, and there is no universal standard for this yet.

One edge case is temporary break-glass automation, where a workload may need elevated access for remediation or migration. Even there, the elevation should be explicit, time-limited, and separately logged. Another is platform tooling that runs on behalf of many users. Those services should not inherit the caller’s access by default, because the service often has broader technical reach than the user intended.

NHI Management Group research also shows why this matters in cloud-native estates. The 52 NHI Breaches Analysis illustrates how credential reuse and over-broad service access repeatedly surface in real incidents, while the 2026 Infrastructure Identity Survey shows most organisations still rely heavily on static credentials despite the risks. The same lesson applies here: if the workload cannot be cleanly separated from the user, the environment is already treating identity as a convenience layer rather than a control boundary.

Related resources from NHI Mgmt Group

• Why do long-lived secrets still appear in cross-cloud workloads?
• Why is OAuth token management critical in cloud environments?
• Why do ephemeral credentials still leave risk in machine access models?
• What makes OAuth tokens risky in NHI environments?