The AI Security Control Nobody Tests: Can an Agent Reach Your Backups?
An agent that can create a customer summary is useful. An agent that can delete the storage account holding the customer's records is a different class of system. The difference is not whether the model is clever. It is whether its identity can reach the recovery plane.
That distinction became unusually concrete in Microsoft's September 25 investigation of Storm-3168. Microsoft observed two compromised Azure service principals in one tenant. One enumerated resources; the other performed discovery, destruction and credential collection. In a roughly seven-minute destructive sequence, the second principal made more than 100 storage-account deletion attempts. It also attempted to remove recovery protections. Some storage deletions were blocked by resource locks or deletion protection. Microsoft did not confirm successful exfiltration or observe a ransom note.
This was threat-actor activity, not evidence that a legitimate enterprise AI assistant decided to attack its employer. Microsoft describes the operation as linked to an actor associated with agentic ransomware and says the timing and divided work strongly indicate automated or scripted execution. The governance lesson is narrower and more useful: once automated work inherits a powerful cloud identity, an attacker does not need to defeat the model to damage the business. The identity's permissions are enough.
A backup is only safe if the caller cannot erase the way back
Many AI security reviews stop at the prompt. What information can the assistant read? Will a guardrail catch a secret in the response? Those are necessary questions, especially for Descubrimiento de IA en la sombra, but they do not tell you what a connected agent can do to the systems on which recovery depends.
In Microsoft's case, the destructive operations followed existing Azure role assignments. A group-granted Storage Account Contributor role authorized storage actions; direct Contributor access authorized deletion of application resources. The SQL database deletion attempts failed because the operation used an unsupported API version, not because a business approval stopped them. That is a brittle kind of safety. Resource locks and storage-account deletion protection, by contrast, did stop some attempts. The report is a reminder that an independent control can matter after an identity is compromised.
Imagine an internal agent asked to tidy a development environment. It can inventory assets, invoke cloud APIs and suggest deletions. If its service principal can alter backup retention, remove a recovery lock and delete production storage, a harmless request, a compromised token or a malicious instruction in a tool result can all lead to the same risky capability. We are not claiming this hypothetical happened in Microsoft's incident. We are asking whether your architecture would constrain it if it did.
Map the action path, not just the application list
A standard inventory might say that the company has approved a particular agent platform. That tells you little about an individual agent's real blast radius. A useful inventory links each workflow to its caller identity, permitted API actions and protected assets. The question is not simply "which AI tools do we have?" It is "which action can this automation take, through which credential, against which resource?"
Start with one deployed workflow, not a spreadsheet of every experiment. For example, take an agent that prepares cloud cost recommendations. Record whether it only reads billing data, whether it can execute cleanup, and which identity actually runs the cleanup. Trace any group membership or inherited role that expands its reach. Then ask whether that identity can list storage keys, delete storage accounts, change recovery configuration or modify the pipeline that grants the next identity access.
The last point matters beyond this single incident. In a September 29 Microsoft DART case, a different actor used a compromised user identity to reach Azure DevOps and modify a pipeline designed to harvest Kubernetes credentials. It was not reported as an AI-agent incident. It does show how an approved identity can move through connected development and cloud systems. If an agent may edit pipeline definitions, the security boundary extends into every downstream service connection that pipeline can use.
Put the recovery plane outside routine automation
For an agent-enabled workflow, recovery controls should be an explicit deny-by-default category. Avoid giving its ordinary runtime identity authority to remove backups, disable deletion protection, change retention or retrieve broad storage keys. Keep these rights in separate identities and approval paths. Review inherited group permissions as carefully as direct grants; the Storm-3168 report shows why.
A practical pre-launch review can fit on one page:
- **Identity:** Which workload identity signs each cloud request, y who can rotate or impersonate it?
- **Reach:** Which exact resources y operations are allowed, including group-inherited rights y service connections?
- **Recovery:** Can that identity touch backups, retention, locks, key vaults or recovery accounts?
- **Approval:** Which irreversible actions require a separate human or independently held credential?
- **Evidence:** Can responders reconstruct the proposed action, approval, API call y result without relying on a chat transcript alone?
- **Revocation:** How quickly can the operator disable the workflow y rotate a compromised secret?
These are testable conditions, not promises that a generic "human in the loop" switch will solve everything. A human who sees only "clean up unused resources" cannot approve deletion of a specific recovery account responsibly. Show the resource identifier, operation and expected impact at the point of decision. Make the approval independent of the agent's own ability to rewrite its instructions or credentials.
Test the failure path as well. In a staging environment, attempt the forbidden operation with the agent's real runtime identity. It should fail because the permission is absent or because an independent safeguard rejects it, not because the prompt says "do not delete backups." Confirm that the alert names the identity and target resource and that the operator can shut the workflow down. Never run a destructive rehearsal against live recovery assets.
The useful question for this week's review
Microsoft's investigation does not prove that every AI agent is an imminent ransomware risk. It does expose an old cloud security failure mode that becomes harder to tolerate when machines can chain actions quickly: a broadly privileged identity, connected to a large resource graph, with recovery controls inside its reach. The reported seven-minute sequence is a good reason to inspect what happens before anyone has time to read an alert.
If your team is rolling out AI assistants y agents, pick one workflow y draw its path from user request to cloud API and backup boundary. If that path is not visible yet, start withAona's approach to discovering y governing enterprise AI useand bring security, platform engineering y the workflow owner into the same review. The aim is not to stop useful automation. It is to make sure useful automation cannot remove your way back.
