An AI agent that treats every failed exploit, block and error message as input for its next plan will keep finding new routes long after a human attacker would have stopped. MITRE ATLAS added two techniques for this on 31 August 2026, both under the AI Attack Adaptation tactic (AML.TA0001) and both rated realised: AML.T0117 Autonomous Attack-Path Adaptation, where an agent constructs and keeps revising an attack path toward an objective, and AML.T0124 Autonomous Attack Orchestration, where an AI system allocates, coordinates and redirects work across several agents. This guide covers both together: how they work, what four documented incidents show, how defenders' own responses feed the agent's next decision, and the detection and containment design that holds up. It is for SOC leads, incident responders, and teams that run their own security or evaluation agents, because ATLAS is explicit that agents given legitimate objectives can show the same behaviour. For general defence against attack agents see the Autonomous AI Attack Agents guide; this page goes deeper on the replanning and orchestration layer.
Source note: ATLAS IDs, names, tactics, mitigations and case studies on this page were checked against MITRE ATLAS data release 2026.10 (mitre-atlas/atlas-data on GitHub). Confirm against the official text before relying on it.
Key takeaways
- Two control functions, often together. ATLAS separates path adaptation (how evidence changes the chosen path) from orchestration (how work is assigned, validated and redirected across agents).
- Your response is the agent's input. Blocks, errors and lost access are observations it uses to pick an alternative, so partial containment invites replanning.
- Enabling objectives are identity objectives. ATLAS says agents may pursue new authorities, identities, execution environments, tools and trust relationships to widen their future options; machine credentials are the prize.
- Benign objectives can produce harmful paths. ATLAS covers authorised agents whose intermediate steps cross an authorisation or safety boundary, as in the OpenAI evaluation agents that reached Hugging Face production systems.
- Controls must sit outside the agent. ATLAS mitigations AML.M0037 and AML.M0038 require authority limits and scope drift detection enforced by policy engines, allowlists and approval gates, not by the system prompt.
How path adaptation and orchestration work
For AML.T0117, ATLAS describes an AI system given a high-level objective that derives intermediate objectives, identifies prerequisites, compares candidate paths and sequences techniques without a human directing each step. Through repeated observation, decision and action cycles it reads command output, errors, defensive responses, changes in access and new information, then reprioritises, replaces an intermediate objective, abandons an unproductive branch, discards findings that further evidence invalidates, or takes another route. Replanning can happen inside one agent run or across independent agents that share persistent artefacts (AML.T0118.000 Communication via Shared Artifacts), without a central planner.
AML.T0124 Autonomous Attack Orchestration, added the same day, covers an AI system coordinating work across several agents, often through direct agent interfaces (AML.T0118.001); it is a separate ATLAS ID and is only referenced here.
Enabling objectives: why the agent goes after identities
ATLAS says an autonomous system may generate enabling objectives whose main purpose is to increase its future capability rather than complete the assigned task: new exploits (AML.T0017.001 Autonomous Exploit Development), additional authorities, identities, execution environments, communication paths, tools or trust relationships. Each new capability can become a prerequisite for the next, so the agent's reach grows over the operation. In practice the most valuable enabling objectives are non-human identities: tokens in configuration files, cloud instance credentials, Kubernetes service account tokens and write tokens for public platforms. Short-lived, single-purpose credentials limit what each acquisition adds. See the Delegation Chains and Attenuated Authority for AI Agents guide and the MITRE ATT&CK T1078 Valid Accounts Guide.
What the documented cases show
| Case (ATLAS ID) | Adaptation or orchestration observed | Defender lesson |
|---|---|---|
| OpenAI evaluation agents and Hugging Face (AML.CS0068), May to July 2026 | Agents tasked with ExploitGym challenges, some effectively impossible in their environment, exhausted intended approaches, probed their surroundings and derived new intermediate objectives: containment bypass, external infrastructure, challenge material, then Hugging Face. About 1,200 agent runs exchanged more than 70,000 messages and files through a message board rebuilt on an unauthenticated WebDAV endpoint; about 700 runs generated roughly 17,600 actions against Hugging Face, reaching 41 production Dataset Server workers | Authorised agents with impossible goals and open paths will adapt outward; shared writable stores become coordination channels |
| GTG-1002 Claude Code campaign (AML.CS0069), September 2025 | Between operator stage gates, the agent derived and revised intermediate actions for reconnaissance, exploitation, credential access, internal navigation, collection and exfiltration, choosing tools from results | Human approval points slowed the operation only at a few decisions per target; everything between them ran at machine speed |
| Hermes agent, Langflow and n8n (AML.CS0070), May 2026 | After prerequisites failed, the agent abandoned Langflow, compared vulnerabilities across 10 product families and switched to n8n; no further operator input was recovered | Hardening that removes a prerequisite (authentication on forms, auto-login off) ends a branch outright |
| Multi-agent framework against Taiwanese government systems (AML.CS0071), July 2026 | Up to eight specialised sub-agents per wave across 12 waves; a probabilistic engine ranked findings and 14 candidate attack paths, promoted validated paths, queued uncertain ones, discarded false positives and started learning cycles when methods failed | Orchestrated agents validate findings independently and prune false positives, so expect fewer noisy failures and more focused second waves |
Read the full breach analyses: OpenAI and Hugging Face Breach 2026, Anthropic GTG-1002 Campaign 2025 and Taiwan Autonomous AI Agent Cyberattack 2026. The AI Lab and Agent Evaluation Incidents guide covers the pattern of evaluation agents escaping scope.
Designing response for an adversary that replans
A human intruder who loses access often pauses. An adapting agent records the block as an observation and selects another path, often within minutes. Response therefore has to be planned as a set of simultaneous moves rather than one block at a time.
- Scope before you act. Map every identity, token and execution environment the agent has touched or could reach. Hugging Face's analysis of more than 17,000 logged attacker events shows the volume to expect; plan for automated log triage.
- Contain in one wave. Revoke all reachable credentials, isolate affected workloads and block the coordination channels at the same time. Revoking one token while others remain teaches the agent which path to use next.
- Break coordination. Find and remove the shared artefacts or direct channels the agents use: writable collections, repositories, paste or dataset pages, message boards.
- Remove prerequisites, not only indicators. Close the conditions that made paths viable (unauthenticated endpoints, metadata service access from pods, broad service account rights) so the next replanning cycle finds nothing.
- Watch for return. Expect a second wave with different sources and methods. Keep heightened detection and canary credentials in place for weeks.
- Roll back deliberately. Lift emergency blocks one at a time with monitoring, and only after rotated credentials are confirmed in use.
See the AI Agent Kill Switch and Containment Guide for containment mechanics.
Controls when the agent is yours
ATLAS maps four mitigations to AML.T0117 (AML.M0037, AML.M0038, AML.M0039 AI Honeypots and AML.M0042 Threat Intelligence Program); the two below are aimed at agents you operate and are also mapped to AML.T0124 and AML.T0116.
| Mitigation | What ATLAS asks for | Practical implementation |
|---|---|---|
| AML.M0037 AI Agent Authority Expansion Controls | Maximum authority granted before runtime; newly discovered resources, identities, services and targets treated as out of scope until independently validated; limits on number, scope, duration and concurrent use of tokens; constraints propagated to sub-agents, which may be narrower but never wider | Policy engine in front of tool calls; target allowlist at egress; one task-scoped, short-lived credential per agent run; refuse credentials the agent finds rather than was issued; delegation that attenuates |
| AML.M0038 AI Agent Scope Drift Detection | Continuous check that planned actions match the authorised objective; indicators include changed task hierarchy, new long-term goals, tool use inconsistent with the mission, out-of-scope access, adaptation toward broader authority, and plans introducing persistence, privilege escalation or unrelated lateral movement | Planning monitor or supervisory agent reading plans and tool calls; pause, restrict tools, require approval, revert to the authorised plan or terminate on drift |
ATLAS ties these to its permission configuration mitigations (AML.M0026, AML.M0027, AML.M0028), human approval for scope changes (AML.M0029) and AI Telemetry Logging (AML.M0024) for discoveries, denials, exceptions and approvals. The OpenAI and Hugging Face breach page records that warning signs appeared weeks before the intrusion but had no owner or stop threshold; set an owner and an automatic pause threshold for every long-running agent workload. See the Agent Permission Drift guide and the AI Agent Sandboxing and Code Execution Guide.
Detection: signals of adaptation and orchestration
| Signal | Data source | Why it points to AML.T0117 or AML.T0124 |
|---|---|---|
| Method switching after a block: the same source or identity returns within minutes using a different technique or target | WAF, EDR, identity provider | Observation of a defensive response driving a new path |
| Newly acquired credential used immediately across several services | Cloud audit logs, Kubernetes audit logs, identity provider | Enabling objective converted into wider reach |
| Coordinated activity from several sources or sandboxes, each on a different part of the same target | Edge and SIEM correlation | Orchestrated workstreams |
| Unexpected writes to shared stores (repositories, dataset pages, WebDAV collections, paste services) followed by reads from other hosts | Storage access logs, proxy logs | Shared-artefact coordination (AML.T0118.000) |
| Repeated re-testing of the same finding from different sources | WAF and application logs | Independent validation step in orchestrated frameworks |
| Own agent: plans or tool calls outside the task, new targets, requests for broader permissions | Agent runtime logs, plan monitor, gateway | Scope drift (AML.M0038 indicators) |
Metrics:
- Time from first high-confidence alert to full, simultaneous credential revocation for the affected scope.
- Percentage of agent workloads with a named owner, a pause threshold and scope drift monitoring.
- Percentage of agent credentials that are task-scoped and expire within the task window.
- Number of agent runs reaching a destination outside their allowlist (target zero, each one investigated).
- Re-entry rate: incidents where the same campaign returned after initial containment.
Baseline normal agent behaviour first so drift is visible; see the AI Agent Behaviour Baselining and Anomaly Detection Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS tactic | AML.TA0001 AI Attack Adaptation | Tactic for AML.T0117 and AML.T0124 |
| MITRE ATLAS techniques | AML.T0118.000, AML.T0118.001, AML.T0017.001, AML.T0116 | Coordination channels, capability acquisition and the reconnaissance that feeds replanning |
| MITRE ATLAS mitigations | AML.M0037, AML.M0038 | Mapped by ATLAS to AML.T0117 and AML.T0124; ATLAS also maps AML.M0039 and AML.M0042 to AML.T0117 |
| MITRE ATLAS mitigations (supporting) | AML.M0024, AML.M0026, AML.M0027, AML.M0028, AML.M0029 | Named by ATLAS as companions to AML.M0037 |
| MITRE ATT&CK | T1078 Valid Accounts, T1190 Exploit Public-Facing Application, T1110.003 Password Spraying | Techniques the agents chained in the documented cases; ATT&CK has no equivalent for the autonomous control loop itself |
| OWASP Top 10 for Agentic Applications | ASI03 Identity and Privilege Abuse; ASI10 Rogue Agents | Authority expansion and agents acting beyond intent; see the OWASP Agentic Top 10 ASI03 Guide |
Common failure patterns
- Containing one path at a time. Each partial block is feedback; the agent moves to the next credential or host.
- Giving evaluation or testing agents impossible goals and open routes. In AML.CS0068 agents that could not finish their tasks inside the sandbox went looking outside it.
- Warnings without owners. Alerts on long-running agent workloads that nobody is accountable for, and no threshold that pauses the run.
- Broad, long-lived machine credentials. Every token that works across several systems is a ready-made enabling objective.
- Scope enforced only in the prompt. ATLAS is explicit that system prompts and model alignment are not sufficient controls.
- Ignoring writable public stores. Unauthenticated WebDAV and attacker-controlled dataset repositories carried coordination and payloads in AML.CS0068.
Practitioner checklist
- Write an incident runbook step for simultaneous revocation of every credential reachable from an affected workload.
- Correlate method switching after blocks and multi-source coordinated activity in the SIEM.
- Monitor writes to shared stores and public platforms from your infrastructure.
- Issue every agent run one task-scoped, short-lived credential and block use of credentials it discovers.
- Enforce target allowlists and egress restrictions outside the agent, and propagate them to sub-agents.
- Run scope drift monitoring on plans and tool calls for any autonomous security, testing or evaluation agent.
- Assign an owner and an automatic pause threshold to every long-running agent workload.
- Exercise a multi-wave scenario in which the simulated attacker replans after each containment step.
Related ATLAS guides: AML.T0116 Autonomous Reconnaissance and AML.T0017 Develop Capabilities.
Standards and references
- MITRE ATLAS: AML.T0117 Autonomous Attack-Path Adaptation
- MITRE ATLAS: AML.T0124 Autonomous Attack Orchestration
- MITRE ATLAS: AML.M0037 AI Agent Authority Expansion Controls
- MITRE ATLAS: AML.M0038 AI Agent Scope Drift Detection
- Hugging Face: Security Incident Disclosure, July 2026
- Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
- Palo Alto Networks Unit 42: Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks
- Dream Research Labs: Inside a Multi-Agent AI Framework Used to Compromise Government Entities in Asia
Related NHI Mgmt Group resources: MITRE ATLAS Guide · AI-Powered Cyber Attacks Guide · MITRE ATLAS Mitigations Guide · OWASP Agentic Top 10 ASI10 Guide