# A Cloud Identity Needs a Blast Radius Before It Runs

> A Storm-3168 attack used stolen Azure application identities to map a tenant and delete cloud resources in minutes. The useful lesson is how to limit machine authority before fast automation turns one credential into a wide outage.

- **Author:** Kubilay Tunca
- **Published:** 2026-09-29
- **Category:** For Developers
- **Tags:** Cloud Security, Identity Security, AI Agents, Incident Response
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/cloud-identity-needs-a-blast-radius

---

One stolen application identity spent more than fifteen hours quietly reading the map of an Azure environment. A second identity needed about seven minutes to attempt the deletion of more than one hundred storage accounts. The clock that mattered did not start when deletion began. It started much earlier, when those machine identities received enough authority to see and change a large part of the tenant.

Microsoft published the incident on 25 September 2026 and linked the activity to Storm-3168, the actor also known as JADEPUFFER. Its researchers described two compromised service principals in the same Azure tenant: one concentrated on reconnaissance, while the other performed destructive operations and collected credentials. A service principal is the identity an application or automated service uses when no person is sitting at a login screen ([Microsoft Security Blog](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/)).

The label “agentic” will attract attention, but it can obscure the control failure. Fast automation made the attack more efficient. It did not create the storage accounts, grant the roles, expose the credentials, or decide which deletions needed a second barrier. The computer moved quickly because the environment had already given a machine identity a wide road.

For engineering and platform teams, the practical lesson is blunt: every non-human identity needs a stated job, a narrow route, a short credential life, and a tested limit on what happens when it is stolen. If those limits exist only in a design document, seven minutes is enough time to discover the difference.

## What Microsoft observed in Azure

Microsoft says the activity took place in early June 2026 and involved two compromised service principals belonging to one tenant. Both identities connected through infrastructure associated with Storm-3168, showed the same network fingerprint, and used the same Python requests user agent. That evidence linked the separate streams of activity, although Microsoft said it did not know exactly how the attacker first obtained the identities ([Microsoft Security Blog](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/)).

The first service principal behaved like a surveyor. Over roughly fifteen and a half hours, it completed more than 300 successful read operations while discovering virtual machines, subscriptions, resource groups, and other Azure resources. That pace is important. The reconnaissance was automated, but it was not an instant burst that vanished before any monitoring system could notice. A working day passed while one machine identity asked broad questions about the tenant.

About ninety minutes after that survey began, the second compromised identity enumerated virtual machines and resource groups across two subscriptions in five seconds. It later attempted to list a storage account key. Seventy seconds after that request, it tried the same operation against a storage account that did not exist. Less than one second after the unsuccessful request, the destructive sequence started, according to Microsoft's timeline.

The second identity attempted more than 150 destructive or credential-related operations over 35 minutes. The main deletion burst lasted about seven minutes and included attempts against more than 100 Azure Storage accounts. Most of those deletion attempts succeeded. Some did not, because resource locks and storage account deletion protections were already present ([The Register](https://www.theregister.com/security/2026/09/28/jadepuffer-crims-hijacked-azure-identities-and-used-them-to-blow-up-cloud-resources/5299591)).

Storage was not the only target. Microsoft reported deletion activity involving SQL databases, a Key Vault, a Function App, an App Service plan, virtual machines, and related cloud resources. The actor also tried to remove recovery protection locks associated with Azure Site Recovery and Azure Backup. Those attempts failed. The pattern suggests an effort to damage both production services and the path used to restore them, rather than a simple cleanup of one application.

About half an hour after the storage deletion attempts, the actor made more than 30 requests for storage account keys, most of which succeeded. A storage account key can grant broad access to data in that account, depending on configuration. This means the event cannot be understood only as deletion. The same machine authority supported mapping, destructive changes, and collection of credentials that might open further data paths ([BleepingComputer](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/)).

There is one clue about possible credential exposure, but it needs careful wording. Microsoft found that an employee from the affected organisation had previously posted client IDs, client secrets, and a tenant ID in plaintext in a public GitHub issue. Microsoft did not claim that this event proved the initial access route. Publicly exposed application credentials are plainly dangerous, but proximity is not proof. The incident report leaves the initial compromise unresolved.

Independent reporting from The Register and BleepingComputer matches Microsoft's central account: two Azure application identities were compromised; one mapped the environment; another carried out bulk deletion and key collection; pre-existing locks stopped some actions. As of 29 September 2026, Microsoft has not publicly named the affected organisation in the report. There is also no public claim in the cited material that every requested key was used to steal data. Those limits belong in the story because response decisions should follow evidence, not the most dramatic possible interpretation.

## A service principal is a standing worker badge

Human access is easier to picture. A developer signs in, completes multi-factor authentication, opens a console, and performs an action. A service principal sits behind an application, deployment pipeline, scheduled job, or integration. It authenticates without a person and receives tokens that let software call Azure services.

Microsoft groups service principals, applications, and managed identities under the term workload identities. They exist because software needs to work when no employee is present. A deployment system may create an App Service. A backup process may read one storage account and write to another. A monitoring tool may inspect resource health across a subscription. Removing machine identities would break normal cloud operations ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview)).

The useful analogy is a building badge issued to a night-shift contractor. The badge can open exactly the rooms needed for the job, or it can open every door because assigning one broad role was quicker. Nobody sees the contractor tap the badge at reception each morning. The access is quiet, repeatable, and easy to forget once the integration works.

Role scope then decides the blast radius. A role assigned to one storage account creates a different incident from the same role assigned at subscription level. Read access creates a different incident from permission to delete resources or list account keys. Permission to manage locks creates a different incident from permission to modify an application while the lock remains outside its reach.

The first compromised identity in Microsoft's account could inspect a wide landscape. That visibility helped the actor build a useful map before the destructive phase. Read permissions deserve scrutiny because enumeration is how an attacker turns a stolen credential into a plan. “Read only” may prevent direct damage, but broad discovery can reveal names, regions, resource groups, dependencies, identities, and likely recovery targets.

The second identity carried authority that converted the map into action. More than 100 storage-account deletion attempts in seven minutes are striking, yet the speed is only the final multiplier. The larger failure is that one non-human identity could reach so many valuable resources and perform destructive management operations across them.

A team should therefore review a workload identity as a running worker, not as a configuration object. Ask what job it performs, which resources it can see, which actions it can take, and what independent control remains if the identity becomes hostile. If nobody can answer those questions, the identity is already outside a defensible boundary.

## Automation compresses the response window

A human intruder can also script cloud commands. “Agentic” does not mark the first time automation has appeared in an attack. Malware, command loops, infrastructure scanners, and cloud administration scripts have been automating sequences for years. The new concern is the ease with which a system can interpret results, choose the next action, and continue across unfamiliar resources at machine speed.

Imagine an alert reaching an on-call engineer two minutes after the first deletion. That sounds fast. During a seven-minute sequence, however, almost a third of the active destruction has already passed before the engineer even sees the page. They still need to understand the identity, decide whether the event is real, find the correct control, revoke credentials, and check whether another identity is involved.

Approval by a person at attack time is not a realistic control for every cloud operation. Production systems need unattended jobs. The answer is to make ordinary automation narrow enough that stealing it does not expose an entire environment, then place the most damaging actions behind controls the ordinary job cannot remove.

This is the same design problem teams face with coding agents. A fast tool can read repositories, run commands, modify infrastructure files, and call cloud APIs. Asking it to pause before every harmless read destroys its usefulness. Giving it one permanent credential with subscription-wide administration creates a crisis waiting for a confusing instruction, poisoned dependency, or stolen secret. The middle path gives the agent only the identity for its current task and sends logs somewhere that identity cannot alter.

Speed changes which controls deserve priority. Detection remains necessary because the fifteen-hour reconnaissance should have produced signals worth investigating. Once bulk deletion begins, prevention and containment configured beforehand carry more weight than a clever alert. The locks that blocked some deletions did not have to understand JADEPUFFER, identify an AI model, or wait for an analyst. They simply refused an operation that crossed a pre-set boundary.

That is the memorable lesson from the seven-minute number. Fast attackers do not make monitoring pointless. They make preventive blast-radius controls non-optional.

## The controls that survived were already in the path

Azure resource locks can be applied at the subscription, resource-group, or individual-resource level. A `CanNotDelete` lock allows authorised changes but blocks deletion. A `ReadOnly` lock is stricter and can interfere with normal service operations, so it needs careful testing. Locks inherit down the resource hierarchy, and they override ordinary user permissions for the protected management operation ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources)).

In Microsoft's incident, resource locks and storage-level deletion protection preserved some storage accounts while most targeted accounts were deleted. This is a concrete example of an independent safeguard doing useful work after an identity with broad permissions had already been compromised. The lock narrowed the effect of valid credentials.

A lock is not magic. Principals with the required `Microsoft.Authorization/locks/*` permissions can remove management locks. Azure documentation notes that the built-in Owner and User Access Administrator roles include relevant lock-management authority ([Microsoft Learn](https://learn.microsoft.com/en-us/rest/api/resources/management-locks/delete-at-resource-level?view=rest-resources-2016-09-01)). If the same service principal can both remove a lock and delete the protected resource, the two steps form one route rather than two barriers.

The correct design separates routine application work from boundary administration. A deployment identity may update the application it owns without receiving permission to remove the deletion lock around its storage or recovery resources. Lock management can sit with a smaller administrative group, a controlled break-glass process, or a deployment stage requiring stronger review.

Backups need authority separation for the same reason. Microsoft documents locked immutability for supported Azure Backup vaults, which prevents backup data from being deleted or its retention reduced before expiry. A backup that shares the production administrator's credentials and deletion path is a second copy, not an independent recovery boundary ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/backup/azure-backup-data-protection-best-practices)).

A useful recovery claim needs a receipt. Select a representative service, restore it into an isolated location, verify the data and application dependency chain, record the time, and confirm that the normal production identity cannot delete either the backup or the evidence. “Backup job succeeded” proves that a write occurred. It does not prove that recovery survives a stolen administrator.

## Secrets are only one part of the identity problem

The public GitHub issue mentioned by Microsoft is a familiar failure. Client IDs and tenant IDs are often identifiers rather than secrets, but a client secret is supposed to remain private. Put the working combination in a public issue, repository, build log, paste service, support ticket, or chat transcript, and someone else may be able to authenticate as the application until that secret expires or is revoked.

Secret scanning helps find that class of mistake. Repository push protection can stop known credential shapes before they land in a public branch. Build systems can mask registered secret values in logs. Incident procedures can rotate exposed credentials and inspect their use. These controls are worth having because ordinary work produces accidental copies.

Yet “keep the secret secret” is too small a security model. An application with a perfectly stored credential can still be compromised through its runtime and use the identity exactly as designed. Its role should cover the smallest practical scope, and it should not combine lock removal, recovery deletion, key listing, and broad resource deletion merely because setup was easier that way.

Managed identities can remove the need to distribute a reusable client secret to Azure-hosted workloads. Code obtains a token for the identity assigned to its compute resource, rather than reading a static secret from a file. This reduces copying and rotation problems. It does not repair an oversized role. A stolen workload or token can still exercise whatever permission the managed identity carries ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview)).

Federated workload identity can serve a similar purpose for deployment platforms. Instead of storing one long-lived Azure secret, Azure trusts narrowly described tokens from that platform. The trust condition needs exact repository, branch, environment, or workload claims. Rotation must also remove the old value and prove the new one works; adding fresh credentials while old ones remain valid only grows the attack surface.

Inventory closes the loop. Each service principal should have an owner, purpose, creation date, credential type, expiry, assigned roles, resource scope, expected sign-in source, and retirement condition. The owner should be a maintained team or service, not one employee who may leave. An identity without an owner should lose access until someone can justify it.

Microsoft recommends continuously assessing application credentials and avoiding storage of service-principal secrets, storage keys, and connection strings in source code. That advice is sound, but it lands only when teams connect it to deployment mechanics: replace static values, remove old copies, narrow roles, and verify sign-in logs after the change ([Microsoft Security Blog](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/)).

## Read activity can be the start of the incident

Security teams naturally alert on deletion. A burst of storage-account removals is visible and urgent. The first service principal's fifteen-hour survey is less dramatic, yet it offered the better chance to interrupt the operation before damage.

Microsoft Entra sign-in logs include workload-identity activity as well as human sign-ins. Azure Activity Log records management operations against resources. Together, they can answer two different questions: where and how did this machine identity authenticate, and what did it do after receiving a token ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins)).

A useful baseline is often simple. The nightly billing export signs in from one workload and reads one set of resources during a predictable window. The signal comes from deviation: a narrow identity lists virtual machines across two subscriptions, requests storage keys, or starts deleting resources outside its application boundary.

Logs also need an independent destination. If the compromised identity can delete or shorten retention on the same workspace that records its actions, the evidence boundary collapses during the incident. Export critical identity, activity, Key Vault, storage, and backup events to a security account or platform governed by a separate role.

Alert design should name a response action. “Unusual service-principal activity” leaves an on-call engineer searching through context while the clock runs. “Deployment identity X listed resources outside resource group Y; disable credential Z, block the identity, and contact team Q” gives them a route. The runbook should state what production process will fail when the identity is disabled, because responders hesitate when revocation might cause an unknown outage.

Bulk deletion deserves a preventive policy as well as an alert. Azure Policy can audit or deny selected configurations, but it is not a universal undo button for every operation. Resource locks, narrow role assignments, protected backups, and approval around the few identities allowed to remove those barriers provide the stronger path. Detection should tell you someone hit the wall. The wall has to exist first.

## What to do before the next seven-minute sequence

The right response is not a subscription-wide freeze or an inventory spreadsheet with no owner. Start with the machine identities that can cause the largest irreversible change, reduce their authority, and prove that recovery sits outside their reach.

1. **Find every non-human identity with wide scope.** Export service principals, managed identities, federated identities, role assignments, and credentials. Prioritise subscription and management-group scope, Owner, Contributor, User Access Administrator, storage key access, Key Vault administration, lock management, backup administration, and custom roles containing delete actions. Record inherited roles, not only assignments attached directly to the identity.

2. **Write the identity's job in one sentence.** “Deploys the payments Function App in production” is testable. “Automation account” is not. From that sentence, name the resource group, actions, expected source, operating window, and team owner. If the current role cannot be justified by the job, replace it with a narrower built-in or custom role and test the real workflow.

3. **Remove reusable secrets where the platform supports a better credential.** Use managed identity for Azure-hosted workloads and tightly scoped workload federation for trusted external automation. Where a client secret remains necessary, shorten its life, store it in a controlled secret service, scan repositories and logs for copies, and revoke superseded credentials. Verify sign-ins after rotation rather than assuming the old value disappeared.

4. **Separate change authority from boundary authority.** The identity that updates an application should not normally remove resource locks, weaken backup retention, grant itself roles, or list account keys across unrelated storage. Put those actions behind a different identity and a smaller administrative path. Review custom roles for combinations that recreate broad ownership under another name.

5. **Protect the resources whose loss stops the business.** Apply tested deletion locks to critical storage accounts, Key Vaults, databases, network foundations, and recovery components where service behaviour permits it. Enable data-level recovery features that match each service. Keep immutable or otherwise protected backups under separate authority, then run a real restore into isolation.

6. **Baseline reads as well as writes.** Send workload sign-ins and Azure management events to an independently controlled destination. Alert when a narrow identity enumerates new subscriptions, requests keys, touches recovery controls, changes roles, removes locks, or operates from an unexpected source. Include the owner and revocation command in the alert.

7. **Practice containment without improvising.** In a non-production exercise, disable a service principal, revoke or remove its credential, stop its federated route, inspect active role assignments, and trace dependent jobs. Measure the time. Decide in advance who can take that action in production and what evidence must be preserved before cleanup.

8. **Collect a blast-radius receipt.** For each high-impact identity, keep evidence showing its effective role, scope, credential type, lock permissions, reachable secrets, expected sign-in path, logging destination, and latest containment test. Recalculate after infrastructure changes. A diagram from last quarter cannot prove what Azure will authorise today.

Teams running coding agents should apply the same sequence to the credentials exposed inside agent sessions. Do not place a general production cloud identity in the agent's shell because a task may need it later. Issue task-specific authority, constrain the network route, separate planning from production execution, and preserve an external record of every cloud action. The Secure Harness covers this model in detail because coding autonomy becomes safe enough for real work only when its authority has edges.

## How to respond if a workload identity looks stolen

Containment starts with the identity, but deleting it immediately can erase context and break services in ways that hide the original event. The order needs to be fast and deliberate. Preserve the relevant sign-in and activity records to an independent location, note the current roles and credentials, then block the identity or revoke the compromised route according to the tested runbook.

Assume one credential may not be the whole incident. Microsoft's report involved two service principals in the same tenant. Search for identities using the same source infrastructure, user agent, credential repository, deployment platform, owner, and role-change history. Review recent additions of secrets, certificates, federated credentials, consent grants, and role assignments.

Next, trace effect rather than counting alerts. List deleted and modified resources. Check storage key requests, Key Vault access, backup and recovery-control changes, role assignments, network changes, and new application credentials. A failed delete request may still identify what the attacker valued. A successful key request may matter even when the storage account survived.

Rotate or revoke exposed credentials after you understand where they are used. Replace storage account keys that the actor successfully retrieved, update dependent applications through the controlled secret path, and watch for use of the old values. Review data access separately from management activity because obtaining a key can move later actions out of the resource-management log.

CISA's ransomware guidance recommends isolating affected systems, preserving evidence, engaging the appropriate internal and external responders, and restoring from offline or otherwise protected backups based on business priority. Cloud incidents need the same discipline even when the “system” is a collection of identities, APIs, storage accounts, and control-plane records rather than one infected server ([CISA](https://www.cisa.gov/stopransomware/ransomware-guide)).

Do not let the word “AI” distort the response. The urgent facts are the credentials used, authority granted, resources touched, controls changed, data paths opened, and recovery options left. Whether a model selected each API call may matter to threat intelligence. It does not change the first containment steps.

The post-incident review should end with a narrower identity and an independent recovery barrier, not only a new detection rule for one actor's fingerprint. User agents change. Infrastructure changes. A role that cannot delete a protected resource remains useful against the next tool.

## The machine should meet the boundary before the analyst meets the alert

Storm-3168's Azure activity is unsettling because it joins patience with speed. One stolen identity mapped the environment over fifteen hours. Another attempted a dense sequence of destructive and credential-related operations, with the main deletion burst compressed into about seven minutes.

The environment was not uniformly defenceless. Some storage accounts survived because deletion protections were already present. Attempts to remove recovery protection locks failed. Those outcomes came from controls in the action path, not from an analyst winning a race against automation.

That is the standard to carry into your own cloud. A machine identity should have enough authority to complete one named job. Critical deletion, lock removal, role assignment, key retrieval, and backup destruction should not collect in that same identity by convenience. Logs and recovery copies should remain useful after the production credential is lost.

AI can make reconnaissance and action selection faster. It cannot grant itself a role the tenant never gave it, remove a lock it lacks permission to manage, or delete a protected backup held behind separate authority. Those are engineering choices made before the incident.

Give every cloud identity a blast radius while the day is quiet. Then test the edge. Seven minutes should be enough time for an attacker to hit a boundary, not enough time to teach your team that none was there.

For one calm, practical security email each month, join the newsletter on this site.

## Sources

- [Microsoft Security Blog: Storm-3168, agentic-driven cloud attacks using compromised service principals](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/), accessed 2026-09-29
- [The Register: JadePuffer crims hijacked Azure identities and used them to blow up cloud resources](https://www.theregister.com/security/2026/09/28/jadepuffer-crims-hijacked-azure-identities-and-used-them-to-blow-up-cloud-resources/5299591), accessed 2026-09-29
- [BleepingComputer: JadePuffer agentic AI attacks target Azure, destroy cloud resources](https://www.bleepingcomputer.com/news/security/jadepuffer-agentic-ai-attacks-target-azure-destroy-cloud-resources/), accessed 2026-09-29
- [Microsoft Learn: Workload identities](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview), accessed 2026-09-29
- [Microsoft Learn: Lock your Azure resources](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources), accessed 2026-09-29
- [Microsoft Learn: Delete a management lock at resource level](https://learn.microsoft.com/en-us/rest/api/resources/management-locks/delete-at-resource-level?view=rest-resources-2016-09-01), accessed 2026-09-29
- [Microsoft Learn: Azure Backup data protection recommendations](https://learn.microsoft.com/en-us/azure/backup/azure-backup-data-protection-best-practices), accessed 2026-09-29
- [Microsoft Learn: Managed identities for Azure resources](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview), accessed 2026-09-29
- [Microsoft Learn: Sign-in logs in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins), accessed 2026-09-29

- [CISA: StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide), accessed 2026-09-29

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._