ATLAS AML.T0124: Autonomous Attack Orchestration

When one AI system starts handing out assignments to many others, a single operator gets the throughput of a team and the defender faces several coordinated intrusions that look unrelated. MITRE ATLAS added AML.T0124 Autonomous Attack Orchestration on 31 August 2026 under the AI Attack Adaptation tactic (AML.TA0001), rated realised. It describes an autonomous system used as an operational control layer that creates assignments, selects executors, allocates tools and resources, sets dependencies, schedules work and tracks progress across several agents or sub-agents without a human directing each assignment. This guide focuses on the orchestration layer itself: how attack orchestration frameworks are built, what the Taiwan government case shows, how to recognise orchestrated activity in your telemetry and how to stop your own multi-agent systems from orchestrating beyond their mandate. Path replanning, the sister technique, is covered in AML.T0117 Autonomous Attack-Path Adaptation, and general defence in Autonomous AI Attack Agents.

Key takeaways

Centralised control, distributed execution. ATLAS defines the technique by who decides which agent does which work, when, and how its output feeds other work.
Validation makes it quieter. Orchestrators request independent re-checks and discard false positives, so second waves arrive more focused than the first.
Humans can stay in the loop. ATLAS states that an operator setting objectives, choosing targets or approving consequential steps does not stop the activity counting as orchestration.
The same pattern runs inside your organisation. Supervisor and sub-agent designs are common in legitimate agent platforms, and ATLAS mitigations target agents you control.
Delegation must narrow, never widen. AML.M0037 requires sub-agents to inherit the parent's authority limits, possibly narrower but never broader.

What the orchestration layer does

ATLAS lists the functions of an orchestrating system. Each one is a design choice in the attacker's framework and, for defenders, a possible signal.

Orchestration function (ATLAS)	What it looks like in an attack framework	Defender observation
Create assignments and select executors	Specialised sub-agents for reconnaissance, authentication, API testing, vulnerability research, credentials and exploitation	Different sources or sessions each working one technique against the same target
Allocate tools or resources	More testing given to promising findings, less to weak ones	Activity concentrating on one endpoint after an early partial success
Establish dependencies and schedule	An exploitation task waits for a credential task to finish	Credentials obtained in one stream used in another within minutes
Request independent validation	The same finding re-tested by separate agents	Repeated, near-identical requests to one weakness from different origins
Reconcile conflicts and prevent duplicated effort	Work split so agents do not collide	Low overlap between sources despite shared target and timing
Reassign, scale or terminate work	Stalled streams dropped, new research started	Abrupt stop on one vector and a new technique family starting

ATLAS notes that orchestration may use direct agent interfaces to send assignments, status and results (AML.T0118.001 Direct Agent Communication); see the AML.T0118 Autonomous AI Agent Communication guide. The difference from AML.T0117 is the control function: adaptation decides which path to take given new evidence, orchestration decides how work is divided, validated and redirected across agents. The two often appear together.

Orchestration frameworks

The documented case used a framework built on two open-source agent projects, Hermes and OpenClaw, identified from workspace folders recovered by Dream Research Labs. The researchers describe a structure that is useful as a reference model for what to expect:

Waves: twelve documented waves over about four days, 1 to 4 July 2026.
Parallel dispatch: up to eight sub-agents running concurrently per wave, dispatched in three batches, each lettered and given its own targets and techniques.
A scoring engine: a Bayesian model that started each finding at a neutral prior, raised or lowered it as evidence came in, and used thresholds to promote a finding into an attack chain, test it further, queue it for the next wave or discard it; it re-ranked 14 parallel attack chains.
Validation rounds: confirmed findings were re-verified by independent agents; Dream reports eight kept as real vulnerabilities and seven recorded as false positives.
After-action reports and learning cycles: structured reports from each wave fed the next plan, and five learning cycles searched vulnerability databases and public research for new methods.

Anthropic's account of the GTG-1002 campaign in September 2025 shows a related design with one model rather than many sub-agents: operators built a framework that drove Claude Code through phases, split the work into small tasks that each looked innocuous, and returned to humans at roughly four to six decision points per campaign while AI performed 80 to 90 percent of the work. Task decomposition is how an orchestrator hides intent from the model it is directing. See Anthropic GTG-1002 Campaign 2025.

The documented case: Taiwanese government systems

ATLAS case study AML.CS0071 maps AML.T0124 to its first step: the framework dispatched up to eight specialised agents concurrently across 12 attack waves, assigned separate missions, allocated additional testing to promising findings, requested independent validation, aggregated after-action reports and redirected later work based on the status of related workstreams. Taiwan's Ministry of Digital Affairs separately confirmed detecting abnormal attacks in July involving human operation combined with OpenClaw-assisted activity.

What made the orchestration effective was not novel exploitation. According to ATLAS and the NHI Mgmt Group analysis, the framework mapped connected systems from client-side code, collected personnel identifiers from unauthenticated APIs, password-sprayed predictable passwords with automated CAPTCHA solving, and reported 85 compromised accounts, 84 of which authenticated to another system through an SSO bridge without additional MFA. Orchestration turned several ordinary identity weaknesses into one coordinated campaign in days. Read Taiwan Autonomous AI Agent Cyberattack 2026.

Detecting orchestrated activity

Single-source detections see each sub-agent as a separate, modest event. Orchestration becomes visible only when you correlate across sources by target, time and technique.

Parallel technique families against one asset: enumeration, authentication attempts and API testing from different origins within the same window, grouped by target rather than by source IP.
Wave rhythm: bursts of coordinated activity separated by quiet periods, followed by a narrower, better-aimed burst.
Cross-stream credential hand-off: an account compromised by one source used by another soon after.
Re-verification traffic: the same weakness probed again by several origins after first discovery.
Rapid enumeration and mass credential testing: the NHI Mgmt Group Taiwan analysis lists alerts on rapid API enumeration, mass credential testing and parallel scanning.

Metrics:

Percentage of high-value applications whose detections correlate by target across sources.
Time from first wave to a campaign-level incident (rather than several unrelated tickets).
Number of multi-agent systems you operate with sub-agent delegation logged end to end.
Percentage of sub-agent credentials that are narrower than or equal to the parent's.

When the orchestrator is yours

As of ATLAS release 2026.10, ATLAS maps seven mitigations to AML.T0124: AML.M0028, AML.M0029, AML.M0032, AML.M0036, AML.M0037, AML.M0038 and AML.M0042. The two most specific to orchestration are below; they apply only where you have administrative control over the AI system. They do not constrain an adversary's own framework, so the defensive work above remains essential.

Mitigation	ATLAS guidance for orchestration	How to implement
AML.M0037 AI Agent Authority Expansion Controls	Propagate the parent agent's authority constraints to sub-agents so orchestration cannot create or direct executors with broader targets, permissions or permitted actions than the originating agent	Issue sub-agent credentials by token exchange from the parent's credential with attenuated scope; enforce target allowlists and approval gates in a policy engine outside the agents; cap the number and lifetime of concurrent tokens
AML.M0038 AI Agent Scope Drift Detection	Changes in task hierarchy, assignments, resource allocation and newly initiated work are signals that the orchestrator may be drifting from its authorised objective	Log every assignment, sub-agent creation and resource change as a structured event; compare against the authorised task plan; pause, restrict tools, require approval or terminate on drift

Practical rollout for an internal multi-agent platform:

Inventory orchestrators. Find every agent that can spawn or task other agents, including security testing and evaluation agents.
Bind delegation to identity. Give each sub-agent its own traceable identity derived from the parent, so actions can be attributed along the chain. See the Delegation Chains and Attenuated Authority for AI Agents guide.
Set hard limits. Maximum concurrent sub-agents, maximum depth of delegation, allowed targets and tools, set before runtime and enforced outside the model.
Monitor in shadow mode first. Run drift detection in alert-only mode for a pilot group to tune thresholds, then enforce pause-on-drift.
Test it. In an authorised exercise, instruct a test orchestrator to request a sub-agent with wider scope and confirm the policy engine refuses it.
Keep a stop path. One action must halt the orchestrator and every sub-agent it created; see the AI Agent Kill Switch and Containment Guide.

Common failure patterns

Ticket-per-alert triage. Each sub-agent's activity is closed as low severity and the campaign is never assembled.
Sub-agents inheriting the platform's credential. A shared service credential lets every executor act with full platform authority.
Limits in the prompt only. ATLAS states authority expansion controls should not rely on system prompts, model alignment or the agent recognising that an action is out of scope.
No cap on fan-out. An orchestrator that can create unlimited workers can multiply any mistake.
Weak identity seams. SSO bridges without step-up and predictable passwords let orchestrated streams convert one finding into many accounts.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS tactic	AML.TA0001 AI Attack Adaptation	Tactic for AML.T0124
MITRE ATLAS mitigations	AML.M0028, AML.M0029, AML.M0032, AML.M0036, AML.M0037, AML.M0038, AML.M0042	Mapped by ATLAS 2026.10 to AML.T0124
MITRE ATLAS related techniques	AML.T0117, AML.T0118.001, AML.T0116, AML.T0126	Path adaptation, direct agent communication, autonomous reconnaissance and automated collection seen with orchestration in AML.CS0071
OWASP Top 10 for Agentic Applications	ASI07 Insecure Inter-Agent Communication; ASI03 Identity and Privilege Abuse	Unprotected task channels and delegated privilege; see the OWASP Agentic Top 10 ASI07 Guide
MITRE ATT&CK	T1078 Valid Accounts	The account abuse the orchestrated streams relied on in AML.CS0071; ATT&CK has no technique for the orchestration layer itself

Practitioner checklist

Correlate detections by target across sources for internet-facing and SSO-connected applications.
Treat coordinated multi-source activity as one incident and escalate on pattern, not on per-event score.
Require MFA or step-up at SSO bridges and remove predictable password patterns.
Inventory every internal agent that can spawn or task other agents.
Derive sub-agent credentials from the parent with equal or narrower scope.
Cap fan-out, delegation depth and token lifetime outside the model.
Log assignments and sub-agent creation, and run scope drift detection on them.
Test that a request for a wider-scoped sub-agent is refused.

AML.T0124 Autonomous Attack Orchestration: Detecting and Constraining Multi-Agent Attack Control