On September 25, Microsoft security researchers published an account of an attack on an Azure customer. Microsoft tracks the actor as Storm-3168, the group Sysdig first documented in July as JADEPUFFER and described as the first documented agentic ransomware operation.

The way in was ordinary. An employee posted a service principal's client ID, secret and tenant ID in plain text in a public GitHub issue. The issue was later edited to remove the secret, but it remained readable in the issue's public edit history. Microsoft's verdict belongs on every team's wall: "Removing or redacting an exposed secret does not invalidate it."

Nobody should read that as a story about one careless employee, because a credential pasted into a ticket, a chat thread or an issue tracker is one of the most ordinary mistakes in cloud operations, and it will happen in your environment too.

The Timeline

In early June, the first service principal (the non-human identity automation uses to act in Azure) spent 15.5 hours on reconnaissance, making more than 300 successful read operations. A second compromised principal joined in. Then came the destruction: more than 100 storage account deletion attempts in about seven minutes, part of more than 150 destructive or credential-harvesting operations in 35 minutes, run through five separate tokens.

Do the arithmetic. A read roughly every three minutes for most of a day, then a deletion attempt about every four seconds. The quiet phase lasted more than 130 times as long as the loud one. Low and slow, then all at once.

Most of the targeted storage accounts were deleted, along with a key vault, a function app and an app service plan. Microsoft says the timing and the split of work across principals and overlapping token streams "strongly indicate automated or scripted execution." Call it agentic or just fast. Seven minutes isn't a window a human response process closes.

Every Permission Check Passed

Least privilege is the right answer, and every cloud team already knows it. It just isn't the whole answer, and this incident shows exactly where it stops.

According to Microsoft, the principals held Storage Account Contributor for the storage they went after, plus contributor access to application resources and SQL databases. The deletions weren't a privilege escalation. The permissions were working as granted. Identity did its job: it confirmed the caller held a valid token and that the role allowed the action. Both were true.

So, what held?

A few storage accounts carried Azure resource locks or storage-level deletion protection, and those deletions were blocked. Microsoft calls them "independent safeguards that remain effective even when a compromised identity has broad administrative permissions." The SQL databases survived too, but not because of any control. Every deletion attempt used an unsupported API version. That was the attacker's bug, and nobody should build a recovery plan around the other side's bugs.

The only safeguards that worked were the ones that never asked the identity's opinion.

Two-Person Integrity for the Delete Button

The military settled this problem decades ago for the material it can least afford to lose. Under two-person integrity, no single individual, however senior or trusted, can act alone on nuclear weapons or top-tier cryptographic keys. The rule doesn't assume every person is hostile. It assumes any one person can be compromised, coerced or simply wrong.

A service principal with delete rights is a single operator with no second signature. A resource lock is the second person.

In Azure, a lock applies "a restriction across all users and roles," and removing one requires lock-management permissions held by roles such as Owner and User Access Administrator. The other major clouds offer a similar second key. AWS S3 Object Lock in compliance mode stops "any user, including the root user" from deleting a protected object version during its retention period. An AWS Backup vault lock in compliance mode "cannot be altered or deleted by any user or by AWS" once its grace time ends. Google Cloud lets you place a lien on a project "to block the project's deletion until you remove the lien."

If the identity running your automation can remove the lock, you've built a two-person rule with one person.

Four Changes Before the Next Secret Leaks

1.   Lock what you can't rebuild. Production data stores, key vaults and backup vaults get deletion protection by default. Removing it should take a change request, not an API call.

2.   Keep the second key away from automation. No workload identity should hold the permission to remove the locks that protect its own resources. Audit which roles carry lock-management rights, because broad administrative roles usually do.

3.   Split read, write and destroy. Automation that writes rarely needs to delete. Scope delete rights to named resources, not whole subscriptions.

4.   Retire the secrets people can paste. Where the platform supports it, move automation to managed or federated workload identities that have no long-lived secret to leak. Where a secret has to exist, treat any public exposure as a compromise and rotate it at once. Rotation closes the leak. Redaction doesn't.

The fair objection is that 15 and a half hours of reconnaissance is a long time, and a mature detection program should have caught it. Maybe. But every one of those 300-plus reads was a permitted call from a valid identity. Detection had to recognize authorized behavior as hostile. The lock only had to say no.

Least privilege decides how much a single key can open. Two-person integrity decides whether a single key is ever enough. At machine speed, the second question is the one that saves the data.

Lock what you can't rebuild. Keep the second key somewhere else. Assume the next secret is already public.