Azure Identity Security: Lessons From the Seven-Minute Wipe

More than 100 storage-account deletion attempts in seven minutes.

Most of the targeted storage accounts were deleted.

Azure Key Vault, an Azure Function App, and an App Service plan were also deleted. The attacker attempted to delete an Azure SQL database and continued querying for storage-account keys after the destructive activity.

Microsoft associated the operation with Storm-3168, an actor it has previously linked to agentic ransomware activity.

That makes for an attention-grabbing AI security story.

But focusing on the word agentic risks missing the more important enterprise architecture lesson.

The destructive operations were executed using compromised service principals with valid permissions.

And some of the attempted destruction was stopped not because an AI model reconsidered its actions, but because deterministic Azure controls—including resource locks and deletion protection—stood in the way.

The deeper lesson is straightforward:

The blast radius of automation is determined by the authority of the identity executing it.

Whether the next destructive operation originates from an AI agent, malicious script, compromised application, automation framework, or human attacker, excessive authority creates excessive blast radius.

That makes identity architecture one of the most important security boundaries for enterprise AI.

What Microsoft Observed

Microsoft documented activity involving two compromised service principals.

According to Microsoft’s investigation, one compromised identity performed more than 300 successful reconnaissance operations over approximately 15.5 hours.

The activity included enumeration across Azure and Microsoft Graph as the actor explored the environment.

A second compromised service principal was then used during the destructive phase.

Microsoft observed more than 100 storage-account deletion attempts during approximately seven minutes.

Most of the targeted storage accounts were successfully deleted.

The actor also deleted resources including an Azure Key Vault, Function App, and App Service plan and attempted to delete an Azure SQL database.

Some operations failed.

And those failures are arguably the most architecturally interesting part of the incident.

Don’t Let “Agentic Ransomware” Distract From the Control Failure

The term agentic ransomware naturally attracts attention.

It also creates an easy path to the wrong conclusion:

AI agents are becoming dangerous enough to destroy cloud environments.

That may be an interesting discussion, but it isn’t the strongest lesson supported by this incident.

The available evidence demonstrates automated or scripted execution using compromised identities.

It does not require us to conclude that an LLM independently selected every destructive operation.

And from an enterprise architecture perspective, that distinction isn’t even the most important one.

Consider three possibilities:

Human attacker → compromised identity → Azure API

Script → compromised identity → Azure API

AI agent → compromised identity → Azure API

The initiating intelligence changes.

The authorization boundary doesn’t.

Azure ultimately evaluates whether the identity making the request is permitted to perform the requested operation.

If the answer is yes, the platform may execute it.

That’s why the central security question isn’t:

How intelligent was the attacker?

It’s:

What could the compromised identity do?

Valid Credentials Do Not Mean Safe Actions

This is a fundamental identity-security problem.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

A compromised service principal may still authenticate successfully.

From the platform’s perspective, the credentials can be valid.

But if that identity has broad destructive permissions, those valid credentials can authorize extremely damaging operations.

This distinction becomes increasingly important as enterprises deploy AI agents.

An agent might have:

• A Microsoft Entra workload identity
• API credentials
• Database permissions
• Microsoft Graph permissions
• Azure RBAC roles
• Access to storage
• Access to Key Vault
• SaaS application permissions
• Internal API access
• Tool credentials

Once those credentials exist, agent security becomes identity security.

The model isn’t the security principal.

The workload identity executing the model’s decisions is.

Your Agent’s Blast Radius Is Defined by Its Authority

Imagine an enterprise AI agent designed to analyze application telemetry and recommend remediation.

It needs to:

• Read Azure Monitor data
• Query Application Insights
• Examine application configuration
• Retrieve deployment information

Does it also need permission to delete storage accounts?

Probably not.

Does it need permission to delete Key Vaults?

Probably not.

Does it need subscription-level administrative privileges?

Probably not.

Yet broad service accounts are often created because they simplify development.

The team gets the prototype working.

Permissions accumulate.

More capabilities are added.

Another application starts using the same credentials.

Nobody wants to break the integration.

Eventually the identity has far more authority than the workload actually requires.

Then one compromised credential becomes a large portion of the organization’s blast radius.

The principle should be:

Give the identity the permissions required by the capability—not the permissions that make development convenient.

Every Production Agent Should Have a Dedicated Workload Identity

Shared credentials are especially problematic for autonomous systems.

Suppose five applications and three AI agents all use the same broadly privileged service principal.

When something goes wrong, several questions become difficult:

• Which workload performed the action?
• Which workload actually required the permission?
• Can one workload be disabled without affecting the others?
• Can credentials be rotated safely?
• Can permissions be reduced without breaking unrelated systems?
• Can activity be attributed reliably?
• What is the blast radius if the credential is compromised?

A dedicated workload identity makes those questions easier.

A production AI agent should generally have its own identity rather than borrowing credentials from a user or sharing a giant service account with unrelated applications.

Then authorization can be designed around that agent’s actual responsibilities.

Agent → Dedicated Identity → Approved Capabilities → Required Permissions

That gives architects a much cleaner security boundary.

Least Privilege Must Apply to Capabilities

Traditional least privilege is sometimes interpreted too broadly:

Give the application only the Azure role it needs.

For AI agents, I would go one level deeper.

Start with the business capability.

Suppose the approved capability is:

GetCustomerOrderStatus

The agent may need permission to retrieve a limited subset of order information.

That does not imply authority to:

• Execute arbitrary SQL
• Update customer records
• Delete orders
• Modify database schemas
• Retrieve unrelated tables
• Administer the database

Likewise, an infrastructure-analysis agent may need:

GetResourceHealth

That doesn’t imply:

DeleteResource

This is why capability design matters.

The safest enterprise AI architecture doesn’t expose an entire technical system merely because the agent needs one function inside it.

It exposes the narrowest useful capability.

Separate Read, Write, and Destructive Authority

Not all permissions carry equal risk.

A useful authorization hierarchy is:

Read → Recommend → Draft → Write → Approve → Destructive Action

Those steps should not automatically share the same identity or permission boundary.

An agent that analyzes resources may require read access.

An agent that recommends remediation may still require only read access.

An agent that creates a proposed change might write to a staging area.

An agent that executes production changes needs a different level of authority.

An agent capable of deleting production resources crosses another boundary entirely.

This gives enterprises a path toward progressive autonomy.

Don’t jump from:

The AI can analyze the environment

to:

The AI can administer the environment.

Increase authority only when the business case justifies the additional blast radius.

Resource Locks Were More Important Than Intelligence

One of the most useful details in Microsoft’s account is that not every destructive operation succeeded.

Some resources were protected by controls such as resource locks and deletion protection.

Those controls mattered even though the attacker was operating with compromised credentials.

That’s defense in depth.

The identity might say:

I am authorized.

The resource can still say:

You cannot delete me.

That second boundary matters.

For critical resources, enterprises shouldn’t assume that identity authorization alone provides sufficient protection.

Use independent controls where the consequence justifies them.

Examples can include:

• Azure resource locks
• Database deletion protection
• Immutable or protected backups
• Network segmentation
• Privileged Identity Management
• Approval workflows
• Separate administrative identities
• Recovery accounts
• Policy enforcement
• Independent logging

The important architectural idea is independence.

A compromised workload should not automatically inherit the ability to remove every safeguard protecting the resources it can reach.

Put Critical Safeguards Outside the Workload’s Authority

This principle applies directly to AI agents.

If an agent can:

1. Modify a production resource,
2. Disable the resource’s protection,
3. Delete the resource,
4. Delete the audit trail,
5. Disable the backup,
6. And modify its own permissions,

then the organization has created an enormous failure domain.

The controls exist.

But they’re all inside the same authority boundary.

A stronger architecture deliberately separates them.

For example:

Operational Identity
Can perform approved normal business actions.

Privileged Change Identity
Can perform narrowly defined administrative changes.

Destructive-Action Identity
Used only when deletion or similarly consequential operations are explicitly authorized.

Recovery Identity
Can restore the environment but isn’t available to normal production workloads.

Security Control Plane
Can disable identities, block network paths, or stop workloads independently.

Now compromising one identity doesn’t automatically compromise the entire control structure.

Recovery Must Survive the Production Identity

This leads to another principle:

The identity operating production should not be able to destroy the organization’s ability to recover production.

Backups are useful only if the compromised workload cannot delete them.

Audit logs are useful only if the workload being audited cannot rewrite them.

Kill switches are useful only if the workload cannot disable them.

Resource locks are useful only if removing them requires a sufficiently independent authority.

Recovery credentials are useful only if they’re isolated from the credentials used during ordinary execution.

This is not uniquely an AI problem.

It’s established enterprise architecture.

AI simply increases the urgency because autonomous systems can potentially execute many actions quickly.

Automation Compresses the Time Available to Respond

The seven-minute destructive sequence highlights another important consequence of automation.

Automation compresses time.

A human administrator might manually perform a destructive operation, inspect the result, move to another resource, and continue.

Automated execution can attempt operations across many resources much faster.

That changes incident response.

A security process that assumes someone will notice suspicious behavior and manually intervene after twenty minutes may be useless against an automated sequence that completes in seven.

As execution speed increases, controls must move closer to the execution path.

That means relying more heavily on:

• Preventive authorization
• Resource-level protections
• Automated anomaly detection
• Rate limits
• Policy enforcement
• Independent containment
• Rapid credential revocation
• Automated kill switches

Human response remains important.

But humans shouldn’t be the only thing standing between a compromised identity and hundreds of destructive API calls.

Agent Security Is Cloud Identity Security

As AI agents become enterprise applications, some organizations will be tempted to build an entirely new security vocabulary around them.

Some new controls will absolutely be necessary.

But much of the foundation already exists.

Enterprise AI agents still depend on:

• Identity
• Authentication
• Authorization
• Secrets
• Network boundaries
• APIs
• Logging
• Monitoring
• Recovery
• Separation of duties
• Least privilege

Those aren’t obsolete because an LLM entered the architecture.

They’re more important.

The model may decide what action it wants to take.

The surrounding architecture decides whether that action is possible.

That gives us a useful way to think about agentic security:

Model behavior determines what the agent attempts.

Identity and architecture determine what the agent can actually accomplish.

Ask the Compromise Question Before Production

Before deploying an autonomous agent, ask a deliberately pessimistic question:

If this agent’s identity were completely compromised tomorrow, what could an attacker do with it?

Not:

What do we expect the agent to do?

Not:

What does the prompt tell it to do?

Not:

What should the agent do?

Assume the identity is compromised.

Then enumerate its actual authority.

Can it:

• Read sensitive data?
• Modify customer records?
• Send external communications?
• Create users?
• Change permissions?
• Retrieve secrets?
• Execute code?
• Modify infrastructure?
• Delete resources?
• Disable logging?
• Remove backups?
• Change network rules?

The resulting list is your practical maximum blast radius.

If that blast radius is unacceptable, redesign the permissions before production.

Build the Agent Around an Authority Contract

Every consequential enterprise agent should have an explicit authority contract.

At minimum, define:

Owner
Who is accountable for the agent?

Identity
Which workload identity executes its actions?

Capabilities
Which business functions may it invoke?

Permissions
What may the identity read, write, modify, approve, or delete?

Systems
Which applications, databases, APIs, and cloud resources may it reach?

Network Boundaries
Where may it communicate?

Execution Limits
How frequently and for how long may it act?

Destructive Authority
Which actions require elevated permissions or human approval?

Observability
Which actions and authorization decisions are recorded?

Containment
How can the identity or workload be disabled rapidly?

Recovery
Which safeguards remain available if the workload itself is compromised?

This is where agent governance becomes engineering rather than policy documentation.

The Seven-Minute Lesson

The Storm-3168 incident will understandably be discussed as another example of increasingly automated or agentic cyberattacks.

But enterprises shouldn’t wait for agreement over exactly how much AI selected each action before learning from it.

The architecture lesson already exists.

Compromised identities had destructive authority.

Automation exercised that authority quickly.

Independent protections stopped some operations.

That is enough.

For enterprise AI architects, the takeaway is not:

Be afraid of intelligent agents.

It’s:

Architect every autonomous workload as though its identity may eventually be compromised.

Give agents dedicated workload identities.

Apply least privilege.

Expose narrow capabilities instead of broad administrative tools.

Separate read, write, and destructive authority.

Protect critical resources independently.

Keep recovery outside the production workload’s control.

And design containment for machine-speed execution.

Because when an autonomous system goes wrong—or when an attacker takes control of it—the intelligence behind the action is only part of the problem.

The blast radius is defined by the authority you gave it.

Related Architecture Topic

Enterprise AI Architecture — Agents | Pillar 6 of EAA

Frequently Asked Questions