What breaks when a stolen cloud key can create new IAM users?

A stolen cloud key becomes far more dangerous when it can create new IAM users, login profiles, and additional access keys. At that point the attacker is no longer relying on one compromised secret. They have built persistence inside the account, which means revoking the original key may not remove the real foothold.

Why This Matters for Security Teams

When a cloud key can create new IAM users, the compromise stops being a single-secret problem and becomes an account-control problem. The attacker can turn one stolen credential into durable access by minting fresh principals, adding login profiles, and issuing additional access keys. That breaks the usual assumption that secret revocation is enough to contain the event. It also defeats many alerting models, because the new access path looks like legitimate administration unless creation of identities is tightly governed.

This is why NHI security is not just about protecting secrets, but also about limiting what a secret can do once it is used. NHIMG research on The 52 NHI breaches Report and the Azure Key Vault privilege escalation exposure shows how privilege expansion turns exposure into persistence. Current cloud guidance also aligns with the need for strict least privilege and short-lived access, not broad administrative capabilities on long-lived keys. In practice, many security teams encounter account persistence only after the original key has already been rotated, rather than through intentional prevention.

How It Works in Practice

The dangerous path is straightforward: a key with IAM write permissions is stolen, then used to create a new IAM user or role-like foothold, attach policies, generate a console login profile, and issue new access keys. Once the attacker has a second identity, the original secret can be revoked without eliminating the compromise. That is why static, role-based IAM often fails against autonomous or opportunistic abuse of cloud control planes.

Effective defense depends on reducing what any one workload key can authorise at runtime. The practical pattern is to keep workload identity narrow, prefer short-lived tokens over long-lived static credentials, and deny identity-management actions unless a clearly justified automation path exists. Security teams should treat account-creation permissions as highly sensitive, especially when granted to service principals, CI/CD systems, or agentic workflows. Best practice is evolving toward intent-aware controls, but there is no universal standard for this yet.

• Use separate identities for runtime access and identity administration.
• Block or tightly scope actions such as CreateUser, CreateLoginProfile, and CreateAccessKey.
• Issue SPIFFE-style workload identity or OIDC-based short-lived credentials where possible.
• Evaluate permissions in real time with policy-as-code rather than relying only on static role grants.
• Alert on identity creation, policy attachment, and key issuance as persistence indicators, not just on key use.

That operational model lines up with broader identity lessons in the Ultimate Guide to NHIs and with the escalation patterns described in the Anthropic report on AI-orchestrated intrusions, where tool access and privilege chaining matter as much as the initial compromise. These controls tend to break down when legacy automation jobs still require broad IAM write access because the business has not separated provisioning from privileged administration.

Common Variations and Edge Cases

Tighter IAM control often increases operational overhead, requiring organisations to balance automation speed against the risk of persistence. That tradeoff becomes visible in CI/CD pipelines, cloud bootstrap scripts, and emergency break-glass accounts, where teams may be tempted to allow identity creation “just this once.” The problem is that once creation rights are normalised, stolen keys can become durable entry points.

Some environments also rely on temporary access brokers or delegated admin roles. Those patterns can be safer than static keys, but only if the delegated scope is narrow, time-bound, and audited. Current guidance suggests that exceptions should be explicit, short-lived, and separated from routine workload access. For AI agents and other autonomous systems, the bar is even higher because behaviour is dynamic and cannot be assumed to follow a fixed access pattern. Static permissions should not be the default for any system capable of chaining tool use or acting without direct human approval.

Where this guidance is weakest is in highly distributed multi-account or multi-cloud estates, especially where old service accounts, federated IAM, and manual break-glass workflows overlap. NHIMG’s 52 NHI Breaches Analysis and industry research on static credential dependence both point to the same issue: once identity creation is available to a compromised secret, revocation alone is no longer a complete response.

Related resources from NHI Mgmt Group

• Why do compromised inboxes create wider IAM risk than many teams expect?
• What breaks when fraud and IAM teams operate separately?
• What breaks when compromised IAM credentials still have standing privilege in AWS?
• What breaks when cloud credentials are valid outside their original workload?