An AI agent that can delete files, drop tables or remove cloud resources can be steered into doing it, and the deletion runs with the agent's own legitimate permissions. MITRE ATLAS tracks this as AML.T0101 Data Destruction via AI Agent Tool Invocation, an Impact technique (AML.TA0011) that ATLAS rates as realised. ATLAS describes adversaries invoking an agent tool capable of mutative operations to destroy data on specific systems or across a network, interrupting availability. This guide covers how the technique shows up, the six ATLAS mitigations mapped to it, detection, recovery design and a rollout plan. It is for teams that build, approve or run agents with write or delete access, and it goes deeper than the MITRE ATLAS Guide.
Key takeaways
- The agent is the deputy, not the attacker. The destructive call is a normal tool call made with valid credentials, so perimeter and malware controls rarely see it.
- Three triggers are on record. ATLAS case studies show indirect prompt injection (AML.CS0046, AML.CS0063) and a malicious agent prompt shipped in a compromised software release (AML.CS0047).
- Permissions decide the blast radius. ATLAS maps three access mitigations (AML.M0026, AML.M0027, AML.M0028) that all say the same thing: separate destructive permissions from routine access.
- Confirmation must sit outside the model. Human approval (AML.M0029) and restricting tools when untrusted data is in context (AML.M0030) only work when enforced by the platform, not by a prompt.
- Recovery is part of the defence. Soft delete, versioning and backups the agent's credentials cannot reach turn a destructive call into an incident you can reverse.
How the technique works
ATLAS created AML.T0101 in November 2025 and last modified it in May 2026; it applies to the Agentic AI platform and has no sub-techniques. It is the agent-specific counterpart of ATT&CK T1485 Data Destruction. Three ingredients are needed: an agent holding a tool that can delete or overwrite (a shell, a file system tool, a database or cloud API, a SaaS connector), credentials behind that tool with destructive rights, and a way to make the agent call it. That last step usually comes from AML.T0051 LLM Prompt Injection, delivered through content the agent reads, and ends in AML.T0053 AI Agent Tool Invocation.
| ATLAS case study | Trigger | Tool abused | Outcome |
|---|---|---|---|
| AML.CS0046 Data Destruction via Indirect Prompt Injection Targeting Claude Computer-Use (research, HiddenLayer, October 2024) | Obfuscated instructions hidden in a PDF the user asked the agent to open, framed as a safe test sandbox | Shell (bash) tool | The agent ran a command that deleted the victim's file system |
| AML.CS0047 Code to Deploy Destructive AI Agent Discovered in Amazon Q VS Code Extension (incident, AWS, July 2025) | A malicious commit, made with an inappropriately scoped GitHub token, added an agent prompt to clean a system to near factory state and delete file system and cloud resources | Agent file system and bash tools | Shipped in extension version 1.84.0; AWS reports the code failed to run because of a syntax error |
| AML.CS0063 Prompt-Based Attacks Against Gemini via Calendar Invitations (research, SafeBreach, August 2025) | Instructions in a calendar invite title, triggered on a later ordinary reply such as "Thanks" | Calendar and other connected agent tools | Gemini deleted a victim calendar event; Google deployed layered defences after disclosure |
The pattern without an attacker is just as instructive. In the PocketOS database deletion of April 2026, a coding agent working in staging hit a credential mismatch, found an account-scoped platform token in an unrelated file and used it to delete a production volume and its volume-level backups in one API call. No adversary was involved, but every control that would have stopped it (scoped tokens, no secrets in the workspace, approval for deletes, backups outside the credential's reach) is the same control that defeats AML.T0101.
Why it is hard to stop at the model
- Guardrails can be talked round: in AML.CS0046 the agent refused the plain instruction, then complied once the request was obfuscated and framed as a test environment.
- The trigger can be delayed: in AML.CS0063 the action fired on a later, harmless user reply, so the user saw no link between the poisoned content and the deletion.
- The agent may be the payload: in AML.CS0047 the destructive instruction arrived through the software supply chain, so the user never saw it. ATLAS tracks the related step as AML.T0103 Deploy AI Agent.
Classifying destructive tools
Before applying controls, list every tool each agent holds and rate it by how much it can destroy and how reversible that is. The tiers below are our recommendation, not ATLAS text.
| Tier | Examples | Default control (our recommendation) |
|---|---|---|
| Unbounded | General shell, cloud CLI with account-wide credentials, database connection with DROP or TRUNCATE rights, infrastructure-as-code apply | Remove from autonomous agents; sandbox with no production credentials; human approval with full command shown |
| Bulk destructive | Delete many files, purge a mailbox folder, delete a storage bucket or volume, bulk record delete in a CRM | Separate permission and separate tool; approval; per-call item cap; soft delete required at target |
| Single-item destructive | Delete one calendar event, close one ticket, delete one document | Scope to resources the requesting user owns; confirmation when untrusted content is in context |
| Overwrite | Update a record, write a file over an existing one, change a configuration | Versioning at the target; log before and after values |
| Read only | Search, list, read | Normal access control and logging |
A shell tool is in the top tier whatever its stated purpose, because any destructive command is one argument away. The AI Agent Permission Matrix Template gives a format for recording these ratings per agent.
Prevention: the ATLAS mitigations
ATLAS 2026.10 maps six mitigations to AML.T0101. The table gives each one's ATLAS name and what ATLAS says about it for this technique.
| ATLAS mitigation | Guidance for AML.T0101 |
|---|---|
| AML.M0026 Manage AI Agent Service Access | Separate deletion, overwrite and other destructive permissions from routine service access; limit them to required workflows and target resources; authorise workflow initiators so that access to the agent does not confer destructive privileges |
| AML.M0027 Manage User-Delegated AI Agent Access | Use read-only delegation when modification is unnecessary; limit destructive permissions to explicitly authorised tasks and resources rather than automatically delegating everything the user can do |
| AML.M0028 Enforce Access Controls for AI Agent Tools | Separately authorise destructive tool operations against specific targets; withhold destructive permissions from callers and tool execution identities that do not need them; enforce outside the model, in the tool or MCP server |
| AML.M0029 Human In-the-Loop for AI Agent Actions | Require user confirmation of tool invocations so an adversary cannot have tools run automatically |
| AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data | Restrict automatic tool use when untrusted data is present, so prompt injections cannot invoke tools |
| AML.M0024 AI Telemetry Logging and Monitoring | Log AI agent tool invocations to detect malicious calls |
The broader catalogue is covered in the MITRE ATLAS Mitigations Guide.
Putting the mitigations into practice
- Split read and delete identities: give the agent's routine tools a credential with no delete rights, and route destructive operations through a separate tool backed by a separate, narrowly scoped identity. This is the practical reading of AML.M0026 and AML.M0028.
- Bound user delegation: when an agent acts for a user through OAuth, request read scopes by default and ask for write or delete scopes per task, not at install time (AML.M0027).
- Show the real action: an approval prompt must show the exact command, query or resource identifiers, not a model-written summary. Approval fatigue is real, so reserve it for the top two tiers. See the Human-in-the-Loop for AI Agents Guide.
- Taint tracking for context: once a web page, email, document, issue or tool output from outside the trust boundary enters the context, block destructive tools or force approval for the rest of the session (AML.M0030).
- Keep credentials out of reach: no long-lived platform tokens in repositories or agent workspaces; use a secrets manager and short-lived, environment-scoped credentials. ATLAS tracks credential finding as AML.T0055 Unsecured Credentials.
- Sandbox the shell: run code and shell tools in an isolated environment with no production credentials and disposable storage. See the AI Agent Sandboxing and Code Execution Guide.
Where identity fits
Every AML.T0101 outcome is bounded by the identity the tool runs as. In the Amazon Q case the entry point was an over-broad GitHub token in a build configuration; at PocketOS it was a token created for domain management that was account-scoped and could do anything. Treat each agent and each tool backend as a non-human identity with an owner, a purpose, an environment scope and an expiry, and review it for drift as tools are added. See Agent Permission Drift.
Recovery design
Prevention will fail eventually, so the target systems must make agent deletions reversible. ATT&CK tracks attacks on recovery itself as T1490 Inhibit System Recovery; the PocketOS deletion removed backups stored in the same volume.
| Control | What it gives you | Check |
|---|---|---|
| Soft delete or retention window at the target | Deleted objects recoverable for a set period | Confirm the API path the agent uses honours it, not just the console (Railway changed its API to 48-hour soft deletes after the PocketOS incident) |
| Object or file versioning | Overwrites recoverable | Versions cannot be purged by the agent's credential |
| Backups in a separate account or vault | Restore after bulk deletion | Agent and production credentials have no delete rights on backups |
| Point-in-time recovery for databases | Restore to the minute before the call | Tested restore time meets the service's target |
| Disposable agent workspaces | Local destruction affects only throwaway storage | Workspace snapshots or rebuild from source |
For the wider pattern see the Data Integrity Protection Against Destructive Attacks Guide and the T1490 Inhibit System Recovery Defensive Guide.
Detection
Detection depends on AML.M0024: if tool calls are not logged with the agent identity, the user it acted for and what was in its context, investigations cannot tell an attack from a mistake.
| Data source | What to look for |
|---|---|
| Agent tool call logs | Calls to destructive tools; recursive or wildcard arguments; targets outside the task's stated environment; many deletes in one session |
| Agent trace with context sources | A destructive call in the same session as untrusted content (web page, email, shared file, calendar invite, issue) |
| Cloud and SaaS audit logs | Delete events (storage, volumes, databases, mailbox items, calendar events) from agent identities, especially against production |
| Endpoint telemetry for developer agents | Shell commands that remove large directory trees or use elevated rights, spawned by an agent or IDE extension process |
| Software inventory | Agent extensions and tools at versions withdrawn by the vendor, such as Amazon Q Developer for VS Code 1.84.0 |
Measuring it
- Destructive tool coverage: share of agents whose tools are rated by tier.
- Standing delete rights: number of agent identities holding delete or admin rights with no task-time grant; target zero for the unbounded tier.
- Approval coverage: share of top-tier tool calls that required and received human approval.
- Taint enforcement: share of sessions with untrusted content in which destructive tools were blocked or gated.
- Restore proof: time to restore from a test deletion through the agent's actual API path, measured each quarter.
Implementation steps
- Inventory: list every agent, its tools, the identity behind each tool and that identity's rights. Include IDE coding agents and SaaS assistants with connectors.
- Rate tools: apply the tier table. Remove unbounded tools from any agent that processes untrusted content.
- Turn on logging first: capture tool calls and context sources (AML.M0024) for two to four weeks to see real usage before changing permissions.
- Split identities: move destructive operations to separate tools and credentials scoped by environment and resource. Pilot on one agent; roll back by restoring the previous credential if workflows break.
- Add gates: enforce approval and taint rules in the agent platform or tool server, starting in log-only mode, then blocking for the top tier.
- Fix recovery: confirm soft delete, versioning and isolated backups on every system an agent can delete from, and test a restore.
- Exercise: run a tabletop or red-team test with an injected instruction in a document the agent reads, and check that the call is blocked, gated or reversible.
Small teams can stop at steps 1, 2, 5 and 6: remove shell and bulk-delete tools from assistants and make targets reversible. Large organisations need the identity split and central policy so that controls hold across many agent platforms.
Common failure patterns
- Prompt rules as access control: a system prompt saying "never delete" is advice, not enforcement; the PocketOS agent broke its own instructions.
- Purpose-built token, account-wide scope: a token made for one job but able to do anything, left where the agent can read it.
- Summarised approvals: the user approves "clean up temporary files" while the real command targets the whole disk.
- Backups in the blast radius: backups stored with, or deletable by, the same credential as production.
- Unpinned agent extensions: auto-updating IDE agents and tools mean a compromised release reaches developers within days, as AML.CS0047 shows.
- Delegating everything the user can do: an assistant given full mailbox, calendar or drive rights when the task only needs read.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1485 Data Destruction; T1490 Inhibit System Recovery; T1059.004 Unix Shell; T1552.001 Credentials In Files | Enterprise equivalents of the outcome, the recovery attack, the shell tool and the found token |
| OWASP Top 10 for LLM Applications 2025 | LLM06:2025 Excessive Agency; LLM01:2025 Prompt Injection | Excessive functionality, permissions and autonomy enable the impact; injection is the usual trigger |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; AC-3 Access Enforcement; AU-12 Audit Record Generation; CP-9 System Backup; SI-4 System Monitoring | Scoped rights, enforced outside the model, logged, with recoverable data |
| NIST CSF 2.0 | PR.AA-05; PR.DS-11; PR.PS-04; DE.CM-09 | Least privilege, protected backups, logging and monitoring |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control; 8.2 Privileged access rights; 8.13 Information backup; 8.15 Logging | Policy-level controls for agent identities and recovery |
Practitioner checklist
- Every agent tool is rated by destructive tier, with an owner.
- No agent that reads untrusted content holds an unbounded shell or account-wide cloud credential.
- Destructive operations use separate tools and separate, environment-scoped identities.
- User-delegated agents start with read-only scopes.
- Approval prompts show the exact command or resource identifiers, enforced by the platform.
- Destructive tools are blocked or gated once untrusted data enters the context.
- No long-lived platform tokens sit in repositories or agent workspaces.
- Every system an agent can delete from has soft delete or versioning and backups the agent cannot reach.
- Tool calls are logged with agent identity, acting user and context sources, and delete events alert.
- Agent extensions and tools are pinned and checked against vendor security bulletins.
Standards and references
- MITRE ATLAS: AML.T0101 Data Destruction via AI Agent Tool Invocation
- MITRE ATLAS: AML.CS0047 Code to Deploy Destructive AI Agent Discovered in Amazon Q VS Code Extension
- AWS: Security Bulletin AWS-2025-015, Amazon Q Developer Extension for Visual Studio Code
- MITRE ATLAS: AML.CS0046 Data Destruction via Indirect Prompt Injection Targeting Claude Computer-Use
- MITRE ATLAS: AML.CS0063 Prompt-Based Attacks Against Gemini via Calendar Invitations
- OWASP: LLM06:2025 Excessive Agency
- MITRE ATT&CK: T1485 Data Destruction
- SafeBreach Labs: Invitation Is All You Need, Hacking Gemini
Related NHI Mgmt Group resources: MITRE ATLAS Guide, AML.T0053 AI Agent Tool Invocation, Human-in-the-Loop for AI Agents Guide, Agent Permission Drift, AML.T0102 Generate Malicious Commands, AML.T0142 Event Triggered Execution.