The cloud provider secures the underlying infrastructure, but the customer remains responsible for workload identities, configuration, access, and behaviour. That division matters because the most common failure points in cloud workload security sit above the provider layer, where permissions, exposure, and runtime use are owned by the customer.
Why This Matters for Security Teams
Shared responsibility is often described too simplistically as “the provider secures the cloud, the customer secures everything else.” That misses the operational reality: workload identity, secrets, permissions, and runtime behaviour are where most cloud compromise paths emerge. As NHIMG notes in its Ultimate Guide to NHIs — What are Non-Human Identities, machine identities already outnumber human ones in many environments, and ownership is often unclear.
This is why responsibility matters more than labels. The provider may harden the substrate, but customers own the identity primitives that workloads use to call APIs, move laterally, and reach sensitive data. If those identities are overprivileged or long-lived, the cloud is still exposed. The SailPoint research linked in NHIMG’s Critical Gaps in Machine Identity Management report shows 59% of organisations struggle to audit machine identities because of weak ownership and limited visibility. In practice, many security teams discover this only after an exposed token, mis-scoped role, or compromised workload has already been used to expand access.
How It Works in Practice
In a shared responsibility model, the customer is responsible for workload security at the identity and configuration layers. That includes assigning each workload a distinct identity, limiting permissions to the minimum required, rotating secrets, validating network exposure, and monitoring runtime behaviour. The emerging best practice is to treat workload identity as the control point, not just the authentication artifact.
For cloud-native systems, that usually means replacing static credentials with short-lived, task-scoped proof of identity. The SPIFFE workload identity specification is a useful example because it focuses on cryptographic workload identity rather than shared secrets. NHIMG’s Guide to SPIFFE and SPIRE aligns with that approach by emphasizing verifiable workload identity, which helps teams issue and revoke trust more cleanly across services, containers, and ephemeral jobs.
Practically, teams should map responsibility across these layers:
- Identity: unique workload identity per service, job, or agent.
- Credentials: short-lived tokens, certificates, or ephemeral access rather than static keys.
- Authorization: least privilege at runtime, not broad inherited roles.
- Configuration: secure defaults for storage, ingress, egress, and metadata access.
- Monitoring: detection for anomalous API use, privilege escalation, and secret exposure.
This is also where Azure Key Vault privilege escalation exposure and similar cloud incidents become instructive: the infrastructure remained available, but customer-controlled identity and access choices created the breach path. These controls tend to break down in environments with many unmanaged service accounts, broad cross-account trust, or teams that rely on long-lived secrets embedded in pipelines.
Common Variations and Edge Cases
Tighter customer control often increases operational overhead, requiring organisations to balance least privilege against deployment speed and service reliability. That tradeoff becomes sharper in multi-account, hybrid, and platform-engineered environments where ownership boundaries are distributed across application, infrastructure, and security teams.
There is no universal standard for every workload pattern yet, especially for autonomous software, batch processing, and multi-agent systems. Current guidance suggests treating dynamic workloads differently from human users because their access needs are contextual and often short-lived. In agentic or highly automated systems, static RBAC alone is usually too blunt, which is why runtime policy and just-in-time credentials are gaining attention. NHIMG’s 230M AWS environment compromise and the Snowflake breach both reinforce the same lesson: cloud provider controls do not prevent customer-side identity misuse.
The most common edge cases are service meshes, CI/CD runners, and ephemeral AI or automation agents, where the workload changes state faster than manual governance can track. In those cases, responsibility still sits with the customer, but enforcement should shift toward policy-as-code, ephemeral trust, and continuous verification rather than static approvals.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Workload identity and secret handling are core shared-responsibility risks. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous workloads need runtime authorization beyond static cloud roles. |
| NIST AI RMF | AI governance applies when cloud workloads are autonomous or agentic. |
Assign unique workload identities and eliminate shared static secrets wherever possible.
