MITRE ATLAS 2026.09 / technique reference

AML.T0117
Autonomous Attack-Path Adaptation

← Back to the ATLAS matrix · Pinned MITRE source · Current MITRE ATLAS site

MITRE source definition

Adversaries may use an AI agent to autonomously construct and repeatedly revise an attack path toward an adversary-defined objective. Given a high-level objective, the system may derive intermediate objectives, identify prerequisites, and compare candidate paths, and incorporate observations from previous actions to adaptively sequence techniques without a human directing each step.

Autonomous AI agents may also exhibit this behavior while pursuing an objective provided for a legitimate, benign, or authorized purpose when the intermediate objectives or methods selected by the system cross an authorization, trust, control, or safety boundary and result in attempted or realized harmful cyber activity.

Through repeated observation-decision-action cycles, the system may interpret command output, errors, defensive responses, changes in access, and newly discovered information. It may use those observations to reprioritize actions, replace an intermediate objective, abandon an unproductive branch, discard findings invalidated by additional evidence, or pursue an alternative path.

An autonomous AI system may generate enabling objectives whose primary purpose is to increase its future operational capability rather than directly accomplishing the assigned objective. These objectives may include acquiring new exploits (See Autonomous Exploit Development), additional authorities, identities, execution environments, communication paths, tools, or trust relationships that expand the set of actions available to subsequent planning cycles. Newly acquired capabilities may themselves become prerequisites for additional enabling objectives, resulting in progressive expansion of the agent's operational reach over the course of an operation.

Attack-path replanning may occur within one agent run or emerge across multiple independent agents. Agents may communicate persistent, shared artifacts (See Autonomous AI Agent Communication: Communication via Shared Artifacts), allowing discoveries, requests, capabilities, constraints, task state, and results produced by one agent to affect the subsequent path selected by another. Participating agents may adopt peer requests, divide work voluntarily, reuse successful methods, continue incomplete activity, or redirect their local paths without a centralized planner, shared context window, or complete view of the broader operation.

Human involvement does not preclude autonomous attack-path replanning. A human operator, user, evaluator, or workflow may select the target, define the objective, establish constraints, provide capabilities, or approve consequential transitions.

Autonomous Attack-Path Adaptation and Autonomous Attack Orchestration may occur together but describe different control functions. Attack-path adaptation captures how evidence changes the selected path. Attack orchestration captures how work is allocated, coordinated, validated, and redirected across agents.

Source modified 2026-08-31. Reproduced from the pinned ATLAS release; inline technique links resolve to local reference pages.

No explicit relationship in this pinned source.

Source-backed defensive context

MITRE mitigations

MITRE case studies

These are explicit source relationships, not independently reproduced incidents or validated detection coverage. The local relationship indexes link back to the pinned MITRE source.

Detection and collection design

No executable detector is supplied by this ATLAS source import. Define detection against the specific behavior in the full definition above. MITRE case-study and mitigation relationships supply context, not tested rule coverage.

No explicit AI Telemetry Logging mitigation relationship was found for this technique. Do not manufacture a sensor mapping from its tactic.

Depending on the selected scenario, the experiment may need dataset/model versions, data-access and build audit records, inference or application traces, or agent tool authorization records. These are planning options, not asserted mappings. Minimize sensitive prompt/data capture and retain provenance.

Anomaly detection design

No exact ATLAS anomaly detector is validated here. Select a measurable feature from the behavior definition; compare like-for-like model versions, workloads and identities. Changes caused by model upgrades, retrieval corpora or legitimate workload shifts must be controls, not automatically labelled attacks.

Baseline and validation methodology · AI-security ecosystem

Tools and reproducible source scenarios

No lab-tool association is invented from the technique name. Inspect the exact source scenarios below for the tools and environment actually used; a case study is not itself an executable or safe lab.

Simulation experiment plan

Select an owned, disposable system implementing AML.T0117 Autonomous Attack-Path Adaptation. Use synthetic data and sandboxed tools; disable production credentials, external side effects and data exfiltration. For poisoning or supply-chain tests, use throwaway artifacts rather than real training or deployment pipelines.

State the exact trust boundary and expected observable behavior.
Pin model, application, dataset, tool permissions and evaluation inputs.
Capture baseline and scenario traces, an authorized look-alike, and a missing-telemetry control.
Evaluate the detector against independently labelled results; do not substitute model output claims for observed tool actions.
Restore state and preserve redacted evidence.

Experiment worksheet — not fabricated telemetry

The export below is a planning record, not a native event, positive attack fixture or execution result. Unknown fields deliberately remain null.

{
  "schema": "1200km.atlas.experiment-plan.v1",
  "technique_id": "AML.T0117",
  "simulation": false,
  "target": "REQUIRES_OWNED_LAB",
  "source_scenario": [
    "AML.CS0068",
    "AML.CS0069",
    "AML.CS0070",
    "AML.CS0071"
  ],
  "input_artifact_hash": null,
  "system_version": null,
  "expected_observable": null,
  "native_telemetry_location": null,
  "baseline_reference": null,
  "result": "not_run"
}

Simulation and telemetry boundary

This is a technique reference page, not a runnable simulation. No ATLAS-specific telemetry mapping, local attack execution or detector validation is asserted. MITRE maturity describes its source evidence, not a 1200km lab result.

For broader context—not technique-specific control mappings—see AI Security, AI Security Course, and detection-validation methodology.

Provenance and attribution

Immutable MITRE ATLAS source · Import provenance · Attribution and transformation notice · Apache License 2.0