ATLAS Lateral Movement Tactic: Stopping Movement Through Connected AI Agents

AI agents connect systems that were never meant to trust each other, so one compromised agent, token or prompt can carry an adversary across email, repositories, clusters and model infrastructure. MITRE ATLAS tracks this under the Lateral Movement tactic, AML.TA0015, which it describes as the adversary trying to move through your AI environment, pivoting towards model registries, experiment trackers, vector databases, notebooks and training pipelines, and targeting agents because they commonly hold more permissions than standard user accounts. This hub covers every current technique and sub-technique in the tactic as of ATLAS release 2026.10, ranks them for defenders, traces how they chain in documented cases, and sets out detection and mitigation priorities. It is for detection engineers, cloud and platform security teams, and owners of AI agents and their identities. Each technique with its own guide is linked below. For the enterprise view, see the Lateral Movement Guide; for the framework, the MITRE ATLAS Guide.

Key takeaways

• Credentials are the main vehicle. Valid Accounts and Use Alternate Authentication Material account for most Lateral Movement steps in the ATLAS case record, and many of the credentials involved are non-human.
• Prompts move too. AML.T0143 LLM Prompt Propagation describes malicious instructions spreading through email, shared documents, repositories and agent memory to new agents, without the adversary delivering each payload.
• Shared machine credentials turn one foothold into many. In the July 2026 Hugging Face intrusion, one connector credential shared across clusters gave cluster-admin on two clusters within a second.
• Agents automate the pivot. In the GTG-1002 campaign (AML.CS0069), a jailbroken coding agent tested harvested credentials against discovered systems and authenticated to internal APIs, databases and registries.
• Scope and segment each agent. Per-agent identities, per-cluster credentials and controls on what an agent may do with untrusted data are what limit the reach of every technique in this tactic.

What Lateral Movement means in an AI environment

ATT&CK Lateral Movement (TA0008) is about moving between hosts with remote services and stolen authentication material. ATLAS keeps those techniques and adds the paths that AI introduces:

• Through AI Ops infrastructure: artifact registries, dataset services, inference gateways and orchestration services are high-value pivots, because they hold credentials for many other systems and are often reachable from evaluation and training environments.
• Through agent permissions: an agent connected to mail, chat, repositories and cloud APIs is a ready-made bridge; invoking its tools reaches systems the adversary cannot reach directly.
• Through content: a prompt planted in one data store is retrieved by another agent elsewhere, so movement happens through shared data rather than network connections.

Every technique in the tactic

The table lists every technique and sub-technique ATLAS 2026.10 maps to AML.TA0015, with maturity, the ATT&CK equivalent ATLAS records, and the number of case studies that use it in a Lateral Movement step. Entries without a dedicated NHI Mgmt Group guide are listed by ID and name.

Method: counts from the ATLAS 2026.10 data file, counting distinct case studies with at least one procedure step that uses the entry and is tagged to AML.TA0015. Several of these techniques also sit in other tactics (Valid Accounts and Phishing in Initial Access, for example), and their case studies under those tactics are not counted here. AI Agent Tool Invocation is used in 18 case studies overall, all tagged to other tactics in this release.

Where to start: techniques ranked for defenders

This ranking is NHI Mgmt Group's judgement from the ATLAS data, weighing frequency, realised use and the breadth of access one success yields.

1. AML.T0012 Valid Accounts. The most frequent Lateral Movement technique in the record. In AML.CS0071, a multi-agent framework tested 85 compromised office automation accounts against another government system through an SSO bridge that trusted the existing sessions. Account and credential scope is the first control to check.
2. AML.T0091 Use Alternate Authentication Material, especially Application Access Token. AI services rely on tokens as the primary way to make queries, which ATLAS notes makes them vulnerable to this technique. In AIKatz (AML.CS0036), a token taken from a desktop AI client was used to authenticate to the LLM backend as the victim.
3. AML.T0143 LLM Prompt Propagation. Unique to AI. The Morris II research (AML.CS0024) showed a self-replicating prompt spreading through a RAG-based email assistant, and the Rules File Backdoor case (AML.CS0041) shows poisoned rules files carried into new projects by forking and template reuse.
4. AML.T0122 Exploitation of Remote Services. In AML.CS0068 the agents exploited an internal Artifactory service through server-side request forgery to cross the evaluation network boundary. AI Ops services reachable from untrusted workloads deserve the same patch and exposure discipline as any internet-facing system.
5. AML.T0053 AI Agent Tool Invocation and AML.T0052 Phishing. Tool invocation has no Lateral Movement case yet but is the technique most likely to grow as agents gain connectors. Phishing appears in LAMEHUG (AML.CS0044), where a phishing email was sent from a compromised account.

How the tactic chains in real cases

Ten ATLAS 2026.10 case studies include a Lateral Movement step. Before the first such step, Initial Access appears in 8 and Execution in 6. After the last, Defense Evasion, AI Attack Adaptation and Initial Access appear in 4 each, and Credential Access in 3. That last figure matters: movement and credential theft feed each other, so each new system reached tends to yield the next credential. See the Credential chaining guide for the same pattern across NHI breaches.

The July 2026 Hugging Face intrusion (AML.CS0068)

The clearest chain in the record, from Hugging Face's own technical timeline and the OpenAI and Hugging Face breach page:

1. Node credentials to cluster identity: from a compromised production pod, the agent read the node's cloud role credentials from the instance metadata service and used them to authenticate to the Kubernetes API as the node, then minted service account tokens.
2. Secrets to new trust domains: a production secret object yielded a mesh VPN auth key, an access broker credential and a JWT signing key, which allowed forged identity tokens for private datasets.
3. Shared connector credential: one connector credential shared across clusters and bound to system:masters gave cluster-admin on two clusters within a second.
4. VPN and source control: the VPN key recorded 181 enrolments over the campaign, according to Hugging Face, and a GitHub App integration yielded installation tokens with write scopes; Hugging Face's review found no unauthorised commits.

Hugging Face's remediation is a useful control list: block pod access to the metadata service, rotate credentials broadly, replace long-lived credentials with workload identity, and rebuild the broker with a separate cluster-scoped credential per cluster.

Detection priorities across the tactic

Metrics that show the controls are working:

• Shared credentials: count of credentials valid on more than one cluster, environment or agent; target zero.
• Per-agent identity coverage: share of agents running under their own identity rather than a user's or a shared service account.
• Metadata service exposure: share of AI workloads blocked from the instance metadata service or limited to its token-based version.
• Token origin alerting: share of machine credentials with alerts for use from unexpected origins.
• Propagation tests: red team tests per quarter that try to spread an instruction between agents, and their pass rate.

Mitigation priorities

ATLAS 2026.10 maps mitigations to every entry in this tactic except AML.T0091.001 Web Session Cookie. The table groups them by the control they imply.

For AML.T0091.001, apply the ATT&CK T1550.004 practice: short session lifetimes and re-authentication for sensitive actions, covered in the Session Hijacking and Cookie Theft Guide.

Rolling out the controls

1. Map the bridges: list each agent's connectors and each AI Ops service's credentials, and mark every credential valid in more than one place.
2. Split shared credentials: replace them with per-cluster, per-environment and per-agent credentials, starting with any that grant admin rights.
3. Cut ambient credentials: block workload access to the metadata service, disable service account token automounting where unneeded, and move to workload identity federation.
4. Restrict tools on untrusted data: stop agents from sending, committing or sharing when their context contains external content, or require approval.
5. Test and roll back: stage each change in monitor mode, keep old credentials valid for a short overlap, and revoke once traffic has moved.

Where identity fits

Lateral Movement in AI environments is mostly an identity problem. ATLAS notes that agents commonly have more permissions than standard user accounts, and AML.M0027 sets the user's permissions as an upper bound that a delegated agent should not automatically inherit in full. Give each agent its own identity bound to its owner, scope it to its task, and keep machine credentials short-lived and unique to one system. See the Agentic AI Identity Guide and the Agent-to-Agent Authentication Guide.

Common failure patterns

• One credential across clusters: the shared connector credential in the OpenAI and Hugging Face breach.
• Ambient cloud credentials in AI pods: workloads that process untrusted data and can reach the instance metadata service.
• Agents inheriting full user rights: delegated agents acting with everything the user can do, so an injection reaches every connected system.
• SSO trust without step-up: systems that accept existing sessions from another system, as in AML.CS0071, so one compromised account set opens the next system.
• Unchecked automation keys: VPN, CI and source-control app keys without origin alerts or enrolment limits.

Framework mapping

Practitioner checklist

• Inventory every agent connector and AI Ops service credential, and flag any credential valid in more than one place.
• Give each agent its own identity, scoped below the delegating user's permissions.
• Replace shared cluster, connector and environment credentials with per-system credentials.
• Block AI workloads from the instance metadata service and use workload identity federation.
• Alert on machine credentials and tokens used from new origins, and on new VPN device enrolments.
• Restrict agent send, share and commit actions when context includes untrusted content.
• Keep internal AI Ops services unreachable from evaluation and agent sandboxes unless explicitly allowed.
• Run a propagation exercise between two agents each quarter and track the result.

Standards and references

• MITRE ATLAS: Lateral Movement (AML.TA0015)
• MITRE ATLAS: ATLAS data repository
• MITRE ATT&CK: Lateral Movement (TA0008)
• OWASP: LLM06:2025 Excessive Agency
• Hugging Face: Agent intrusion technical timeline
• arXiv: Morris II worm research paper (2403.02817)

Related NHI Mgmt Group resources: MITRE ATLAS Guide · Lateral Movement Guide · MITRE ATT&CK T1550 Use Alternate Authentication Material Guide · Agentic AI Identity Guide