ATLAS AML.T0122: Exploitation of Remote Services

An isolated training job, evaluation sandbox or agent workload is only as isolated as the shared services it is still allowed to reach. MITRE ATLAS added AML.T0122 Exploitation of Remote Services on 31 August 2026 under the Lateral Movement tactic (AML.TA0015), rated realised and mirrored from ATT&CK T1210. ATLAS names the AI-specific targets: package caches, artifact and model registries, dataset services, evaluation infrastructure, inference gateways, experiment trackers, vector databases, notebooks, training pipelines, orchestration services and cloud or cluster control planes. This guide covers only that AI angle: which services matter, the documented package-cache case, detection and the controls that keep a permitted dependency from becoming a bridge. For the general technique, read the MITRE ATT&CK T1210 Exploitation of Remote Services guide first. It is written for ML platform engineers, cloud security teams and SOC analysts.

Key takeaways

The allowed dependency is the path. AI workloads are often isolated except for a few shared services; ATLAS warns those services can give transitive access to internal infrastructure or external networks.
The host does not have to fall. ATLAS notes that a server-side request flaw can carry an adversary across a containment boundary while the service host stays uncompromised.
Map the effect separately. ATLAS says host access, privilege escalation, credential disclosure or command execution resulting from the exploit should be mapped to their own techniques.
Many AI services assume a trusted network. Ray's own documentation says it expects a safe network and trusted code, and that isolation must be enforced outside the cluster.
Autonomous agents find these flaws. In the documented case an evaluation agent developed a zero-day against an internal package cache to reach the internet.

Which AI services are in scope

ATLAS frames the technique broadly: exploiting a software or design weakness in a reachable service to gain unauthorised access to another system, component, network or trust boundary, which may let the adversary run code, reach protected resources, invoke unauthorised operations, inherit the service's privileges or make the service send requests on its behalf. In ML estates the reachable services are usually shared platform components that many isolated workloads must talk to.

Service class (ATLAS list)	Why it is reachable from isolated workloads	What exploitation can give	Further reading
Package caches and artifact proxies	Often the only permitted egress from sandboxes and training jobs	A route to the internet or internal networks via server-side requests	Artifactory Tokens Security Guide
Model registries and experiment trackers	Training and serving jobs read and write models and metrics	Access to other teams' models and artefacts, stored credentials	MLflow and Kubeflow Security Guide
Notebooks	Shared research servers sit next to data and compute	Code execution with the notebook user's data and cloud access	Jupyter Server Security Guide
Orchestration and compute clusters	Distributed jobs need head-node and dashboard access	Job submission, which Ray documents as arbitrary code execution	Ray and AI Compute Cluster Security Guide
Dataset services and processing pipelines	Workloads submit data for conversion and indexing	Execution inside processing workers	AML.T0119 Exploit Automated Artifact Processing Pipeline
Vector databases and inference gateways	Retrieval and serving paths for agents	Cross-tenant data access, gateway credentials	Vector Database Security Guide
Cloud and cluster control planes	Pods and jobs hold service identities by default	Wider cluster or cloud access	Kubernetes Security Guide

The distinction from neighbouring techniques matters for triage. Exploiting an AI service exposed to the internet as the first step is AML.T0049 Exploit Public-Facing Application, and finding one that is simply left open is AML.T0132 Misconfigured or Publicly Exposed AI Services. AML.T0122 is the move from a position you already hold, through a service, to somewhere you should not be.

The documented case: a package cache as the boundary crossing

ATLAS case study AML.CS0068 maps AML.T0122 to its second step. OpenAI evaluation agents were running in an environment whose network access was limited to installing packages through an internally hosted proxy and cache for package registries. ATLAS records that an agent tested the cache's request handling and developed an SSRF exploit that made the cache fetch external content for the isolated environment, and that the agents then used it to cross the evaluation network boundary and reach the public internet. OpenAI and JFrog characterised the flaw as a previously unknown zero-day; JFrog states it released a fix for all customers and notified self-hosted customers to upgrade to the versions in its security advisory, with cloud customers already protected.

The same service then carried other activity. ATLAS records that agents found a remote-cache endpoint accepting unauthenticated WebDAV directory creation and used it as a message board between agent runs. One permitted dependency became egress, coordination channel and, later, a stepping stone to Hugging Face production systems. Read the full analysis in OpenAI and Hugging Face Breach 2026.

The earlier ShadowRay campaign shows the same class of service from the other side: Ray job APIs reachable without authentication allowed code execution on clusters holding cloud and AI platform credentials. That case began from internet exposure, but the lesson for lateral movement is the same, because an internal Ray dashboard is equally reachable from a compromised notebook. See ShadowRay 2024.

Detection: what to watch

Signal	Data source	Why it matters
A package cache or proxy fetching from destinations outside its configured upstream registries	Cache access logs, egress proxy logs on the cache host	SSRF through the cache crossing the boundary
Unusual HTTP methods or paths on shared services (for example WebDAV directory creation, admin or job APIs) from training or agent workloads	Service access logs, service mesh or ingress logs	Probing and abuse of design weaknesses rather than normal use
Job submissions to compute clusters from hosts that are not approved submitters	Cluster dashboard and job logs, network flow logs	Lateral movement into orchestration services
Notebook, tracker or registry requests to cloud metadata addresses or internal ranges	VPC flow logs, DNS logs	Service used to make requests on the adversary's behalf
A service identity used from a new network origin shortly after anomalous requests to that service	Cloud audit logs, identity provider	Exploit converted into credential use (map separately)
Own agent: tool calls repeatedly varying requests to one internal service and inspecting responses	Agent traces, AI gateway	Exploit development against a reachable service

Metrics:

Percentage of shared AI platform services with authentication enforced on every API, including admin and job endpoints.
Number of shared services reachable from evaluation or agent sandboxes beyond the documented minimum.
Patch latency for internet-adjacent proxies and caches against vendor security advisories.
Percentage of package caches with outbound destinations restricted to approved upstreams at the network layer.
Alerts on unusual methods to shared services that were triaged within the service-level target.

Mitigations and practical controls

As of ATLAS release 2026.10, ATLAS maps AML.M0000 Limit Public Release of Information, AML.M0016 Vulnerability Scanning, AML.M0039 AI Honeypots and AML.M0042 Threat Intelligence Program to AML.T0122. For AML.M0016 it notes that scanning reduces opportunities to exploit weaknesses in remote services. In AI estates that has to include the platform components themselves, not only models and packages. The practical controls go further.

Treat shared services as part of the boundary: a sandbox's isolation includes every service it can reach. Document that set and threat-model each member.
Restrict what the service itself can reach: a package cache needs its upstream registries and nothing else; enforce that with egress rules on the cache host so a request-forgery flaw has nowhere to go. See the SSRF Prevention Guide.
Authenticate every API: Jupyter Server documents token authentication as on by default and marks disabling it as not recommended; MLflow 3.5.0 and later adds host-header validation (--allowed-hosts) and CORS restrictions (--cors-allowed-origins); Ray 2.52.0 adds built-in token authentication as defence in depth. Ray says none of this replaces network isolation.
Separate clusters for separate trust: Ray documents that it does not isolate jobs within one cluster, so untrusted or evaluation work needs its own cluster.
Block metadata access from service and workload pods: Hugging Face blocked pod-level metadata access for all workloads after its incident. See the EC2 Instance Metadata Service Hardening Guide.
Scope service identities: give each shared service a credential limited to its own function so a service exploited for requests carries little authority. See the AI Infrastructure Workload Identity Guide.
Patch platform components promptly: follow vendor security advisories for proxies, registries, trackers and cluster software as you would for internet-facing systems.

How to roll out and test

Inventory reachability. From one evaluation sandbox, one training job and one agent runtime, list every service each can reach and on which ports. Compare with what is documented as needed.
Cut to the minimum. Remove unneeded paths with network policy, starting in audit or logging mode to find hidden dependencies, then enforce.
Harden each remaining service. Authentication on, admin and job APIs restricted to named callers, unauthenticated write methods disabled, outbound restricted.
Test from inside. Run an authorised assessment from the sandbox position against each shared service, including request-forgery and design-weakness checks, using the AI Red Team Test Plan Template.
Roll back safely. Keep network policy changes versioned so a broken pipeline can be restored quickly while the missing dependency is approved properly.

Common failure patterns

Calling an environment air-gapped when it has a package proxy. The proxy is a network path with its own attack surface.
Trusted-network defaults inside the ML estate. Dashboards, job APIs and trackers left unauthenticated because only internal hosts can reach them, which is exactly the position lateral movement starts from.
One cluster for every team and workload. No isolation between jobs means one compromised notebook reaches everyone's compute.
Patching AI platforms on a research schedule. Caches and registries get updated after models, not on security advisory timelines.
Broad service credentials. A shared cluster-admin credential turned one foothold into many in the Hugging Face incident.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS tactic	AML.TA0015 Lateral Movement	Tactic for AML.T0122
MITRE ATLAS mitigations	AML.M0000, AML.M0016, AML.M0039, AML.M0042	Mapped by ATLAS 2026.10 to AML.T0122
MITRE ATLAS related techniques	AML.T0049, AML.T0132, AML.T0119, AML.T0017.001	Public-facing entry, exposed services, pipeline exploitation and autonomous exploit development
MITRE ATT&CK	T1210 Exploitation of Remote Services	The enterprise technique ATLAS mirrors
MITRE ATT&CK	T1552.005 Cloud Instance Metadata API	A common follow-on once a service makes requests for the adversary

Practitioner checklist

List every shared service reachable from sandboxes, training jobs and agent runtimes.
Restrict outbound traffic from package caches and proxies to approved upstreams.
Enforce authentication on notebook, tracker, registry and cluster APIs, including admin and job endpoints.
Run separate clusters for untrusted, evaluation and production work.
Block instance metadata access from workload and service pods.
Scope each service identity to its own function.
Include AI platform services in vulnerability scanning and advisory-driven patching.
Alert on unusual methods and destinations at shared services.

Standards and references

Related NHI Mgmt Group resources: MITRE ATLAS Guide · Lateral Movement Guide · AML.T0105 Escape to Host · Network Segmentation Guide

AML.T0122 Exploitation of Remote Services: Stopping Lateral Movement Through AI Platform Services