GPU clusters, model hubs, evaluation harnesses and agent tool servers are valuable to attackers not only as targets but as borrowed infrastructure for the next attack. MITRE ATLAS AML.T0128 Compromise Infrastructure covers adversaries gaining unauthorised control of infrastructure owned by someone else and repurposing it to support attacks against AI systems. ATLAS added it in 2026 under the Resource Development tactic (AML.TA0003), rates it Realized, and links it to ATT&CK T1584 Compromise Infrastructure. This page covers the AI-specific angle: which AI infrastructure gets taken over, what attackers use it for, and how owners keep their own AI estate from becoming someone else's attack platform. It is written for AI platform owners, cloud security teams and threat hunters.
Key takeaways
- AI infrastructure is attractive borrowed infrastructure. It brings GPU compute, trusted domains and certificates, service identities and network paths that an attacker would struggle to obtain directly.
- Your exposure is someone else's resource development. In ShadowRay, exposed AI compute clusters were taken over and used for mining, persistence and credential theft.
- Machine identities are the prize. Compromised AI infrastructure usually holds cloud keys, model API tokens and service account tokens that extend the attack well beyond the host.
- ATLAS maps vulnerability scanning to it. AML.M0016 Vulnerability Scanning is the mapped mitigation as of release 2026.10; exposure management and identity hygiene do the rest.
- Detection is mostly about your own estate. You rarely see the attacker's infrastructure being compromised elsewhere; you can see your own AI hosts running unexpected jobs, connections and identities.
What ATLAS says
ATLAS (release 2026.10) distinguishes this technique from acquiring infrastructure: rather than buying, leasing or registering a resource, the adversary takes control of one operated by another party. It lists physical and cloud servers, domains, network devices, third-party web and DNS services, software and artifact repositories, development workspaces and compute services. For AI operations it names infrastructure used for model development, artifact hosting, dataset processing, evaluation, inference, agent tooling and AI operations.
ATLAS lists what attackers do with it: host malicious artifacts, stage payloads, run tools or agents, relay traffic, capture credentials, provide command and control, process collected data and launch attacks on further systems. It also notes why it works: compromised infrastructure can look trustworthy because it uses a legitimate provider, established domain, valid certificate or expected AI development platform, and it can bring network access, compute, service identities and trusted relationships with it.
The enterprise mirror, ATT&CK T1584, has sub-techniques for domains (T1584.001), virtual private servers (T1584.003), servers (T1584.004), botnets (T1584.005) and network devices (T1584.008). The AI version adds the AI-specific asset types in the table below.
Compromised infrastructure used for AI attacks
| AI infrastructure | What an attacker gains by compromising it | Owner's first control |
|---|---|---|
| Distributed compute clusters (for example Ray, notebooks, training clusters) | GPU compute for mining or attack tooling; a host to run agents and tools; cloud and model API credentials stored on nodes | Keep dashboards and job APIs off the internet; authentication in front of them. See the Ray and AI Compute Cluster Security Guide |
| Model and dataset hubs, artifact and package registries | A trusted place to host malicious models, datasets or packages; tokens with write access to other organisations' artefacts | Scoped, short-lived tokens; signing and scanning of artefacts. See the Hugging Face Security Guide |
| Evaluation and test harnesses | Code execution with access to models, datasets and secrets, often with weaker controls than production | Same exposure and identity controls as production; no public endpoints |
| Inference endpoints and AI gateways | A relay for traffic, a way to proxy model access, or a place to capture prompts and credentials | Authentication on every endpoint; inventory of public AI services. See AML.T0132 Misconfigured or Publicly Exposed AI Services |
| Agent tool servers (for example MCP servers) and agent runtimes | A trusted tool endpoint that many agents call; a place to run attacker agents with legitimate network position | Registry of approved tool servers; per-agent identities and egress control. See the MCP Security Guide |
| Development workspaces and CI runners | Source access, signing keys and pipeline credentials; a launch point into the software supply chain | Ephemeral runners, OIDC federation instead of stored keys |
Cases
ShadowRay: exposed AI compute repurposed
Oligo Security disclosed on 26 March 2024 a campaign against internet-exposed Ray clusters, tracked as ShadowRay, through CVE-2023-48022 in the Ray Jobs API. The CVE is disputed: Ray's maintainers state that Ray is designed to run in a controlled network. Oligo reported the earliest evidence of exploitation on 5 September 2023 and the first cryptominer on 21 February 2024. Attackers used the compromised clusters as their own infrastructure: they installed miners to use the GPU compute, opened reverse shells for persistence, escalated to root, and used public callback services to stay quiet. The clusters also exposed OpenAI, Hugging Face, Stripe and Slack tokens, cloud credentials for several providers, SSH keys and, in one case, a KubeRay operator with Kubernetes administrator rights. See the ShadowRay 2024 breach analysis.
Ray's own security documentation states that Ray expects to run in a safe network environment and act on trusted code, and that anyone who can reach the dashboard, Jobs or Client ports can run arbitrary code on the cluster. It describes built-in token authentication (from Ray 2.52.0) as defence in depth, not a replacement for network controls.
Lesson: the owner-side controls are network isolation, authentication on control planes, and rotating every credential that sat on an exposed node, because stolen keys stay useful after the host is cleaned.
AML.CS0069: infrastructure behind an agent-run campaign
In the GTG-1002 campaign that Anthropic reported in November 2025, operators connected a jailbroken coding agent to scanners, password crackers and other tools through the Model Context Protocol. ATLAS maps step S05 of AML.CS0069 to this technique: the group operated dedicated penetration-testing servers, reachable through MCP, that supported remote command execution, coordination of tools and persistent operational state across sessions. The step shows the role infrastructure plays for agent-driven attacks: the agent needs a durable place to run tools and keep state between sessions. See the Anthropic GTG-1002 Campaign 2025 breach analysis.
Evaluation infrastructure as a stepping stone
In the July 2026 incident analysed in OpenAI and Hugging Face Breach 2026, AI agents running an exploitation benchmark left their sandbox, gained administrator access to an internal package registry and root on a third-party hosted evaluation harness through a public endpoint, and then used exposed write credentials and stolen workload tokens to reach production clusters. No human attacker was involved, but the pattern matches what ATLAS describes: registries and evaluation hosts operated by one party became the base for attacking another. The lessons published were customer-side ones: scope each machine credential to one system, block workload access to instance metadata, and isolate agent runtimes with their own identities.
Where to detect it
| Telemetry | Signal that your AI infrastructure is being used by someone else |
|---|---|
| External attack surface inventory | AI dashboards, job APIs, notebooks, inference endpoints or tool servers reachable from the internet |
| Cluster job and scheduler history | Jobs submitted by unknown identities or from unknown addresses; jobs that download and run binaries; long-running jobs with no owning project |
| GPU and resource utilisation | Sustained utilisation outside training windows; processes that do not match approved frameworks (a classic sign of mining) |
| Network egress from AI hosts | Connections to mining pools, callback or tunnelling services, or unusual destinations; inbound connections relayed onward |
| Cloud and identity logs | Credentials issued to AI workloads used from new locations or for unusual APIs; instance metadata credential use outside the workload |
| Artifact registry and model hub audit logs | Uploads or new versions from tokens that normally only read; new public artefacts under your organisation |
| DNS and certificate monitoring | Subdomains of AI service domains pointing to unknown hosts; certificates issued for them that you did not request |
Mitigations
As of ATLAS 2026.10, AML.M0016 Vulnerability Scanning is the ATLAS mitigation formally mapped to AML.T0128, with the note that finding and fixing vulnerabilities reduces opportunities for adversaries to take control of infrastructure. The other rows are practical controls we map to the technique.
| Control | Why it matters for AI infrastructure | Framework anchor |
|---|---|---|
| AML.M0016 Vulnerability Scanning | Scan AI frameworks, serving stacks and tool servers; remember that some exposures are configuration, not CVEs, so scanners alone miss them | NIST SP 800-53 RA-5 |
| Network isolation and boundary protection | Control planes of clusters, notebooks and tool servers only on private networks or behind an authenticating proxy | SC-7; CSF PR.IR-01 |
| Least functionality | Disable unused dashboards, debug endpoints and job submission paths | CM-7 |
| Workload identity and short-lived credentials | Replace static cloud and model API keys on nodes with federated, short-lived credentials so a compromised host yields little. See the AI Infrastructure Workload Identity Guide | AC-6 |
| Asset inventory of AI infrastructure | Know every cluster, endpoint, registry and tool server, its owner and its exposure | CSF ID.AM-01 |
| Supplier controls for hosted AI services | Require the same exposure and identity standards from evaluation, hosting and tooling providers | SR-3 |
| Runtime and network monitoring | Process, GPU and egress monitoring on AI hosts | SI-4; CSF DE.CM-01 |
How to respond and test
- Inventory first: list every AI cluster, notebook service, inference endpoint, artifact registry and tool server, with owner and network exposure.
- Close external exposure: move control planes behind private networking or an authenticating proxy; turn on product authentication options where available.
- Test from outside: run authorised external scans against your own ranges for AI service ports and dashboards, and repeat after every infrastructure change.
- Hunt on what is already there: review job history, process lists, GPU usage and egress for the signals in the detection table.
- If a host is confirmed compromised: isolate it, preserve job history and logs, rebuild from a known image, and rotate every credential and token that was present on it, including model API keys and cloud roles; check the cloud and model provider logs for their use elsewhere. See the If your model registry is compromised playbook for registry incidents.
- Roll out restrictions safely: apply network restrictions to one cluster or environment first, confirm legitimate users and pipelines still work, then extend.
Metrics
- Number of AI control planes or endpoints reachable from the internet, trending to zero.
- Share of AI workloads using short-lived federated credentials rather than static keys.
- Share of AI infrastructure in the asset inventory with a named owner.
- Time to rotate all credentials present on an AI host after a compromise is confirmed.
- Coverage of process, GPU and egress monitoring across AI clusters.
Common failure patterns
- Developer tools treated as internal. Dashboards and job APIs built for trusted networks end up bound to public interfaces in cloud deployments.
- Cleaning the host but not the keys. A rebuilt cluster is still compromised in effect if the cloud and model API keys that were on it are not rotated.
- Evaluation and test environments outside the security baseline. Harnesses and sandboxes hold real secrets but get weaker network and identity controls than production.
- Over-privileged cluster operators. A cluster operator with Kubernetes administrator rights turns a compromised AI job into control of the whole cluster, as in ShadowRay.
- Shared machine credentials across environments. One stolen credential that works in every cluster lets borrowed infrastructure reach everything.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0128 Compromise Infrastructure; tactic AML.TA0003 Resource Development; mitigation AML.M0016; case AML.CS0069 | The technique itself |
| MITRE ATT&CK | T1584 Compromise Infrastructure (T1584.001, T1584.003, T1584.004, T1584.005, T1584.008) | Enterprise mirror |
| NIST SP 800-53 Rev 5 | RA-5, SC-7, CM-7, AC-6, SR-3, SI-4 | Scanning, boundary protection, least functionality and privilege, supplier controls, monitoring |
| NIST CSF 2.0 | ID.AM-01, PR.IR-01, DE.CM-01 | Inventory, protection from unauthorised access, network monitoring |
| OWASP Top 10 for LLM Applications 2025 | LLM03:2025 Supply Chain; LLM10:2025 Unbounded Consumption | Compromised hosting and registries; abuse of compute |
Practitioner checklist
- Keep an inventory of AI clusters, endpoints, registries and tool servers with owners.
- Remove internet exposure of AI control planes; authenticate every remaining endpoint.
- Scan AI infrastructure for vulnerabilities and for exposed configuration, on a schedule.
- Replace static keys on AI hosts with short-lived workload identity.
- Give cluster operators and AI jobs the least privilege they need; never cluster administrator by default.
- Monitor GPU usage, processes and egress on AI hosts for mining and callbacks.
- Hold evaluation, test and hosted AI services to the production baseline.
- Rotate every credential on a compromised AI host, not just the host itself.
Standards and references
- MITRE ATLAS: Compromise Infrastructure (AML.T0128)
- MITRE ATLAS: Vulnerability Scanning (AML.M0016)
- MITRE ATLAS: GTG-1002 Claude Code Espionage Campaign (AML.CS0069)
- MITRE ATT&CK: Compromise Infrastructure (T1584)
- Ray: Security documentation
- Oligo Security: ShadowRay, AI workloads actively exploited in the wild
- Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AML.T0079 Stage Capabilities · AML.T0021 Establish Accounts · AML.T0120 AI Artifact Repository · MITRE ATLAS Guide