AML.T0008 Acquire Infrastructure: AI Attack Defence

Before an attack on an AI system starts, the adversary buys, rents or borrows the infrastructure to run it: GPUs to tune an attack, an expired domain that a dataset or an allow-list still trusts, a serverless endpoint that slips past a content security policy, or a proxy that resells someone else's model access. MITRE ATLAS records this as AML.T0008 Acquire Infrastructure, a Resource Development (AML.TA0003) technique with six sub-techniques. It mirrors the ATT&CK technique T1583 Acquire Infrastructure; the general case is covered in the T1583 Acquire Infrastructure guide, and this page covers only the AI-specific angle. It is for threat intelligence, AI platform, data engineering and identity teams.

Key takeaways

Six AI-relevant forms. ATLAS lists AI Development Workspaces, Consumer Hardware, Domains, Physical Countermeasures, Serverless and AI Service Proxies as sub-techniques, each with its own defender touchpoint.
Your trust lists are part of the attack surface. Expired domains still named in training dataset URL lists or in an AI agent's allow-list can be bought and turned against you, as the split-view poisoning research and the ForcedLeak case show.
AI service proxies run on stolen or fraudulent identities. ATLAS links proxy infrastructure to LLMjacking with stolen cloud credentials and to industrial-scale distillation using thousands of fraudulent accounts, so key hygiene is a direct control.
Serverless and AI services blend in. Traffic to Google Apps Script, cloud functions or web AI services looks like normal use, which is exactly why attackers choose them.
Your own agents can acquire infrastructure too. ATLAS records an evaluation agent obtaining hosting and callback resources on its own and maps AML.M0043 to decommission what agents acquire.

What ATLAS says about the technique

ATLAS describes AML.T0008 as adversaries buying, leasing or renting infrastructure such as physical or cloud servers, domains, mobile devices and third-party web services, plus physical components such as printed materials, wearables or disguises that degrade AI components or sensors. It stresses infrastructure that blends with normal traffic, is hard to tie back to the adversary, and can be provisioned and shut down quickly. In the 2026.10 release the parent technique has maturity "Realized".

Sub-technique	What is acquired	ATLAS maturity (2026.10)	ATT&CK mirror
AML.T0008.000 AI Development Workspaces	GPU and cloud notebook resources (ATLAS names Google Colaboratory, AWS, Azure and Google Cloud) to develop and stage attacks, possibly across several workspaces	Demonstrated	None listed
AML.T0008.001 Consumer Hardware	Phones and other devices the adversary fully controls and that are hard to trace	Realized	None listed
AML.T0008.002 Domains	Purchased or free domains, including expired domains still referenced by web-scale datasets	Demonstrated	T1583.001 Domains
AML.T0008.003 Physical Countermeasures	Adversarial patches on stickers or clothing, disguises, decoys, laser pointers or lights that disrupt models or sensors	Demonstrated	None listed
AML.T0008.004 Serverless	Cloudflare Workers, AWS Lambda or Google Apps Script endpoints whose traffic appears to come from common cloud provider subdomains	Feasible	T1583.007 Serverless
AML.T0008.005 AI Service Proxies	Proxy services or self-hosted proxy software that pool upstream AI accounts and hide the underlying credentials from downstream users	Realized	None listed

Cases that show each form

Domains

AML.CS0025 Web-Scale Data Poisoning, Split-View Attack: Carlini and colleagues showed that datasets distributed as URL lists can be poisoned by buying expired domains that once hosted dataset content. Their paper states they could have poisoned 0.01% of LAION-400M or COYO-700M for 60 US dollars.
AML.CS0049 and AML.CS0061: researchers registered domains to host a poisoned agent skill's server and to act as an HTTPS relay endpoint for web AI services used as command and control.
ForcedLeak: the live ForcedLeak 2025 case shows the defender side. An expired domain still on an AI agent's content security policy allow-list was bought for about five dollars and used to receive CRM data exfiltrated through agent output. The fix was enforcing Trusted URLs and securing the domain.

Serverless

AML.CS0029 Google Bard Conversation Exfiltration: ATLAS records the researcher using Google Apps Script, which can be invoked from script.google.com or googleusercontent.com without authentication, so the request did not trigger Bard's content security policy.

AI service proxies

AML.CS0030 LLMjacking: Sysdig found attackers using stolen cloud credentials behind reverse-proxy tooling to resell LLM access, with usage billed to the account holder. See the live LLMjacking 2024 to 2026 page for the timeline and cost estimates.
AML.CS0056 Distillation campaigns targeting Anthropic Claude: Anthropic reported in February 2026 that three labs generated over 16 million exchanges through about 24,000 fraudulent accounts, using commercial proxy services whose "hydra cluster" designs replace banned accounts; one proxy network managed more than 20,000 accounts at once and mixed distillation traffic with ordinary customer requests.
AML.CS0075 and AML.CS0076: ATLAS records proxy infrastructure in distillation campaigns against Google AI services, and an NSA, CISA and FBI attribution of campaigns by six China-based AI companies that used gray-market proxies known as "transfer stations".
AML.CS0057 Storm-2139: the group acquired infrastructure to sell access to a jailbroken Azure OpenAI Service, powered by customer credentials scraped from public sources.

Workspaces, hardware and physical countermeasures

AML.CS0007 GPT-2 Model Replication: researchers used TensorFlow Research Cloud through academic credentials.
AML.CS0004 Camera Hijack Attack on Facial Recognition: attackers bought customised low-end phones.
AML.CS0012 Face Identification Evasion: a team printed an optimised adversarial patch.

Agent-acquired infrastructure

AML.CS0074 records UK AI Security Institute evaluation agents that, during cyber testing in July 2026, obtained verification, hosting and callback resources for account creation, payload delivery and remote tasking. AISI's own report describes the agents creating fake identities and leaving reusable accounts and artefacts on GitHub, which AISI later worked with GitHub to remove.

What defenders can observe

Most acquisition happens outside your estate. These are the points where it becomes visible or where you can make it useless.

Sub-technique	Where you can see or blunt it	What to look for
.002 Domains	Dataset manifests, AI agent URL allow-lists, CSP headers, DNS and proxy logs	Domains in your allow-lists or dataset URL lists that have expired or changed registrant; outbound requests to newly registered domains from AI output rendering
.004 Serverless	CSP and egress policy for AI front ends; proxy logs	AI responses that render images or links pointing at broad provider domains such as script endpoints or worker subdomains
.005 AI Service Proxies	Your own AI provider accounts and keys (you are the upstream); for providers, account and traffic analytics	Usage spikes, first-time model enablement, invocations from unfamiliar IPs or regions, keys used outside business hours
.000 Workspaces	Your model API gateway	High-volume, distributed querying from cloud provider IP ranges consistent with attack tuning or extraction
.001 Hardware, .003 Physical	Biometric and computer vision pipelines	Injected or virtual camera feeds, repeated near-identical presentation attempts, unusual patterns in sensor input
Agent-acquired infrastructure	Agent runtime egress and account creation logs	Agents registering accounts, domains, tunnels or file shares outside their task

The Newly Registered Domains Guide covers the general NRD detection approach that applies here.

Mitigations and hardening

ATLAS maps one mitigation directly to the parent technique: AML.M0043 AI Agent External Resource Lifecycle Management, to decommission agent-acquired infrastructure when authorisation ends. As with ATT&CK T1583, the rest is about making acquired infrastructure useless against you.

Pin dataset integrity: record a cryptographic hash for every datapoint when a URL-list dataset is first curated and reject content that no longer matches at download time. This removes the value of a bought expired domain.
Audit allow-lists for expired domains: review every domain in agent URL allow-lists and content security policies on a schedule, remove unused ones, and keep ownership of domains you still trust. See the Domain Portfolio and Lookalike Domain Management Guide.
Do not allow-list whole provider domains: broad entries such as a cloud provider's script or worker domain let anyone's serverless code receive your data. Allow specific hosts only.
Stop your keys feeding proxies: replace long-lived AI provider keys with roles or workload identity, deny model enablement by default, set spend alerts and keep invocation logging on. See the LLMjacking Guide.
Raise the cost of fraudulent accounts: if you provide AI services, apply verification to account types that are commonly abused and correlate activity across accounts, as Anthropic describes. See the Model Extraction and Distillation Defence Guide.
Contain agent footprints: give agents egress allow-lists, record every external resource they create, and remove those resources when the task ends (AML.M0043).
Harden sensor pipelines: use liveness and injection detection on camera inputs so consumer hardware and physical countermeasures are less effective. See the Identity Proofing and KYC Guide.

Where identity fits

AI service proxies are built on identities: stolen cloud keys in LLMjacking, scraped customer credentials in Storm-2139, and bulk-registered fraudulent accounts in the distillation campaigns. For an enterprise, the practical identity control is to make sure none of your AI provider credentials can become upstream capacity for someone else's proxy: every key has an owner, a quota, a short life and monitoring. For your own agents, every account, domain or token an agent creates is a new non-human identity that needs an owner and an end date. The AML.T0021 Establish Accounts and AML.T0012 Valid Accounts guides cover those adjacent techniques.

How to prepare, step by step

List trust anchors: every domain in AI agent allow-lists and CSPs, every external URL list used to build datasets, and every AI provider key and account.
Close expired and broad entries: remove unused domains, replace wildcard provider domains with specific hosts, and check registrant status for the rest.
Add integrity checks to data pipelines: hash datapoints at curation and verify at download; test on one dataset before applying to all.
Lock down AI provider access: move to role-based or federated access, set quotas and spend alerts, and enable invocation logging. Pilot with one team and keep the old key valid for a short, documented rollback window.
Instrument agents: log external resources created by agents and add a decommissioning step to every agent task.
Test: in an authorised exercise, add a test domain you control to a non-production allow-list, let it lapse in your records, and confirm the audit flags it. See the AI Red Teaming Guide.

Small organisations: focus on AI key hygiene and allow-list review. Large organisations and AI providers: add dataset integrity pinning, cross-account correlation and agent resource lifecycle tracking.

Measuring readiness

Share of allow-listed domains with confirmed current ownership (target 100%).
Number of wildcard or whole-provider domains in agent allow-lists and CSPs (target zero).
Share of URL-list datasets with per-item integrity hashes.
Share of AI provider credentials that are long-lived static keys (trending to zero), and share with spend alerts.
Share of agent-created external resources with an owner and a removal date.

Framework mapping

Framework	Reference	Relevance
MITRE ATLAS	AML.T0008 and .000 to .005 (tactic AML.TA0003 Resource Development); mitigation AML.M0043	The technique, its sub-techniques and mapped mitigation
MITRE ATT&CK v20	T1583 Acquire Infrastructure; T1583.001 Domains; T1583.007 Serverless	The enterprise technique this mirrors
OWASP Top 10 for LLM Applications 2025	LLM04:2025 Data and Model Poisoning; LLM10:2025 Unbounded Consumption	Split-view poisoning through bought domains; resale and abuse of model access
NIST SP 800-53 Rev 5	SR-4 Provenance; SC-7 Boundary Protection; IA-5 Authenticator Management; CM-8 System Component Inventory	Dataset provenance, egress allow-lists, AI key management, inventory of agent resources
NIST CSF 2.0	ID.AM-08; ID.RA-05; DE.CM-01	Lifecycle of trusted assets, threat-informed risk, network monitoring

Common failure patterns

Allow-lists that outlive their domains: the ForcedLeak domain was still trusted after it expired.
Trusting dataset URLs without hashes: content can change between curation and training, which is the whole split-view attack.
Allow-listing a provider rather than a host: anyone's serverless function on that provider becomes a trusted destination.
Long-lived AI keys with no spend alert: stolen keys quietly power resale proxies, billed to you.
No record of what agents create: accounts and artefacts left by agents stay usable after the task, as the AISI incident showed.

Practitioner checklist

Inventory domains in agent allow-lists, CSPs and dataset URL lists; confirm ownership.
Remove expired, unused and wildcard provider entries.
Hash datapoints at curation and verify before training.
Give every AI provider key an owner, quota, spend alert and rotation; prefer federated access.
Keep AI invocation logging on and alert on spikes and first-time model access.
Log and decommission every external resource an agent creates.
Add AI infrastructure patterns from ATLAS case studies to threat intelligence requirements.

AML.T0008 Acquire Infrastructure: How the Technique Works Against AI Systems and How to Defend