A stolen credential doesn't set off any alarms. It doesn't fail a login attempt, doesn't trip a rate limiter, doesn't look any different from its rightful owner using it at 2 a.m. That's the whole problem with static, long-lived credentials—there's no signal at the moment they're stolen, only at the moment they're used for something bad, which is usually too late.
That gap is exactly how one compromised identity turned into a cloud-wide breach earlier this year. What actually happened—and the question a stolen credential's entitlements can never answer—is worth walking through in detail.
One login, four accounts
In May, Microsoft published a detailed writeup of a threat actor it tracks as Storm-2949. The initial entry was social: abuse of Entra ID self-service password reset, paired with social engineering that tricked users into approving fraudulent MFA prompts, then stripped their real authentication methods—phone numbers, email addresses, Microsoft Authenticator registrations—to lock the real owner out. Microsoft's own framing: the actor "didn't rely on traditional malware and other on-premises tactics, techniques, and procedures (TTPs)," deliberately targeting IT personnel and senior leadership. The foothold grew from one compromised identity to four accounts, and once the actor reached the cloud tenant, exfiltration from storage continued over multiple days.
Once inside, the attackers didn't need to be clever. They searched remote file shares for password-related strings and exfiltrated .pfx certificate files that could carry private keys. From there, they abused those identities' own privileged Azure RBAC permissions: pulling storage account keys through a management-plane call, manipulating Key Vault access to reach dozens of secrets—database connection strings, identity credentials—and rewriting SQL server firewall rules, then using Key Vault credentials to connect to the SQL server, far outside the work the compromised accounts were actually doing.
This is the pattern that matters more than the specific vector. The initial compromise was one identity. The breach was everything that identity's standing entitlements could reach, because nothing narrowed those entitlements to the task at hand—no expiry, no task scoping, just whatever Azure RBAC roles that account happened to hold.
Machine-speed lateral movement
Lateral movement with a stolen credential now happens in minutes, not days. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout time—the time from initial compromise to lateral movement onto a second system—at 29 minutes, a 65% increase in speed from 2024 (CrowdStrike). Most access-control programs were built assuming that number was measured in days, not minutes. A quarterly credential rotation policy, or an access review that happens once a sprint, isn't a control against a threat that moves in under half an hour.
As Unit 42's Sam Rubin put it, attackers are increasingly logging in, not breaking in (Help Net Security). Once they're in, the thing that lets a single stolen credential become a cloud-wide breach is standing access that nobody remembers to revoke—the exact shape of the Storm-2949 pattern. A complaint we hear repeatedly from platform teams isn't "how did they get in," but "why did that credential still work three months later."
Storm-2949 compromised a human identity, but the same standing-entitlement failure applies with more force to the identities most companies aren't watching at all. In cloud-native and DevOps environments, machine identities now outnumber humans by as much as 144:1 (Entro Labs, NHI & Secrets Risk Report H1 2025, via axis-intelligence). Every AI agent, every automation script is another identity that can accumulate standing access nobody remembers to revoke—and unlike a human account, nobody gets an MFA prompt to notice when one of those goes missing.
What a declared intent adds that RBAC can't
A Work Session in Alpacon is opened with a declared identity and a declared intent. Commands an agent runs through the exec, command-API and MCP lanes are judged against that declared intent before they run—rules, then baseline, then LLM intent judgment—not just checked against what the account's role happens to allow.
That's the piece Storm-2949's compromised identity was missing, and the piece RBAC can't supply on its own: the actor inherited privileged Azure RBAC roles, and those roles carry no field for what they're supposed to be used for on a given day. A found API token or a leftover certificate carries the same gap. It has entitlements. It doesn't have a purpose, and nothing is checking whether an action matches one.
That coverage stops at the exec, command-API and MCP lanes. Service tokens and a human working in an interactive shell are governed by different models entirely.
The takeaway
Storm-2949's most useful lesson isn't "get better MFA" or "rotate your keys more often"—both are true and both miss the actual failure mode. The failure mode is standing access that was never narrowed to a task and carries no attached purpose, sitting on infrastructure long after anyone remembers granting it, waiting for one compromised identity to find it. Expiry alone doesn't close that door—a deadline that can be renewed by whoever holds it isn't actually a deadline. What's missing is any check of whether an action matches a declared purpose, not only whether the credential running it is still valid.
If judging what a command is trying to do—not just whether the credential behind it still checks out—is a gap in how your infrastructure governs AI agents today, that's the layer worth evaluating next.
