An AI agent wiped an Azure tenant in seven minutes

Microsoft disclosed on 25 September 2026 that a threat actor it tracks as Storm-3168, linked to the group publicly known as JADEPUFFER, used two compromised Azure service principals to run an autonomous destructive operation against a victim's cloud tenant (Microsoft Security Blog, 25 September 2026). The actor's "agentic threat actor" tooling used exposed credentials to access resources and delete cloud-based storage, applications and databases (Dark Reading, cloud security coverage).

What happened

The intrusion did not start with a novel exploit. An employee had published a service principal's client ID, client secret and tenant ID in plaintext inside a public GitHub issue. The post was later edited to remove the secret, but the secret remained retrievable through the issue's public edit history (Microsoft Security Blog, 25 September 2026).

From there the timeline compresses. The first compromised principal ran reconnaissance for 15 hours and 30 minutes, completing more than 300 successful read operations across the tenant. Ninety minutes after that pass began, a second principal joined, enumerating virtual machines and resource groups across two subscriptions in 5 seconds and App Service configuration stores 16 hours later. Seventy seconds after the final inventory call, the destructive sequence started: more than 150 destructive or credential-collection operations attempted in 35 minutes, including over 100 storage account deletion attempts compressed into a 7-minute window, plus more than 30 successful ListKeys calls against storage account access keys (Microsoft Security Blog, 25 September 2026).

The operation deleted multiple Azure Storage Accounts, an Azure Key Vault, a Function App and an App Service plan. Attempts against Azure SQL databases, Site Recovery locks and Backup protection locks failed, and a small number of storage accounts survived because resource locks and deletion protection had been configured on them (Microsoft Security Blog, 25 September 2026). Microsoft attributes the activity to JADEPUFFER, a group first documented by Sysdig in July 2026 running a full extortion playbook against a production database with no human operator directing the tactical execution, including an agent that diagnosed and corrected a failed login in 31 seconds on its own (Sysdig research, July 2026, via web search coverage).

Why this is not an isolated incident

Three independent signals point the same way. First, the credential path: a secret exposed in a GitHub issue and believed deleted, recoverable months later through edit history, a leak class that predates AI entirely but that an agent can now exploit at a speed no human operator matches.

Second, the operational tempo. Microsoft's own operation counts, 300-plus read operations in one reconnaissance pass and 150-plus destructive actions in 35 minutes, describe a rate of action that a human analyst reviewing each step could not sustain, let alone interrupt in time.

Third, the precedent. Sysdig's July 2026 documentation of JADEPUFFER running an extortion operation against a production database with no human in the loop establishes that this is a repeatable operating model for the group, not a one-off script, and Microsoft's naming of it as Storm-3168 confirms a tracked, ongoing threat rather than a single incident.

What it means for a regulated enterprise

The exposure here was not an AI system belonging to the victim. It was a human-created leak that an attacker's AI agent exploited. That distinction matters for scope: every organisation with a service principal, an API key or an OAuth token sitting in a repository, a ticket, a Slack message or an old issue thread is in the blast radius described here, whether or not it has deployed any AI of its own.

Under the EU AI Act's record-keeping expectations and under NIS2's management-level accountability for cybersecurity risk, the relevant question after an incident like this is not whether a policy against posting secrets existed. It is whether the organisation can show, with logs, which credentials existed, what they could reach, and how fast they were revoked once exposure was suspected. A credential that sat valid for weeks because nobody owned the task of checking GitHub edit history is not a policy failure. It is a visibility failure.

The speed of the destructive phase changes the cost of delay. A 7-minute storage deletion window means that a response process measured in hours, the normal cadence for a human-driven security review, arrives after the damage is done. Containment has to be something that happens automatically, at the moment of detection, not something scheduled for the next working day.

What actually addresses it

Two mechanisms matter here, and neither is exotic. The first is credential lifecycle discipline: every service principal, API key and token needs a named owner, a recorded scope, and a revocation path that does not depend on redeploying anything. The second is fast, scoped revocation itself. If a credential can be cut off in seconds rather than hours, a reconnaissance phase that runs for 15 hours stops being a guaranteed prelude to a destructive one, because there is a realistic window to catch it mid-enumeration and pull the credential before the destructive sequence begins.

AANCER's instance of this is a signed agent passport issued by a per-install certificate authority rather than a borrowed token, with revocation taking effect in under 30 seconds and an append-only, tamper-evident ledger recording which credential touched which system. That does not stop an employee from pasting a secret into GitHub. It does mean that when a credential is flagged, the organisation is not waiting on a deployment cycle to shut it off, and there is a record to check against during a review, mapped to 27 regulations including the EU AI Act and NIS2 obligations referenced above.

What to check on Monday

Search your own repositories, issue trackers and chat history for anything that looks like a client ID, secret or connection string, including in edit history and closed or deleted posts. GitHub's edit history keeps old versions visible by design. Pull the list of every service principal and API key your organisation holds and ask, for each one, who owns it and how long revocation would take if it needed to happen right now. If the honest answer is "we'd have to find who built that integration first," that is the gap this incident exploited, and it costs nothing to close except the afternoon it takes to make the list.