When one operation is split across thousands of accounts, every individual account looks like an ordinary customer. MITRE ATLAS AML.T0140 Centralized AI Service Request Routing covers adversaries distributing coordinated AI service requests across many pathways (provider APIs, cloud-hosted endpoints, third-party aggregators or relays and account pools) to hide the scale and common purpose of the activity and evade provider enforcement. ATLAS added it in release 2026.10 (28 October 2026) under Defense Evasion (AML.TA0007), rates it Realized across the Predictive, Generative, Agentic AI and Enterprise platforms, and maps one mitigation, AML.M0042 Threat Intelligence Program. This page is for AI service providers, cloud platforms hosting models, operators of AI gateways and aggregators, and enterprises whose AI accounts may end up in someone else's pool. It explains how the routing works at a defensive level, what the three ATLAS case studies show, and how to correlate distributed activity back to one operation.
Source note: ATLAS IDs, names, tactics, mitigations and case studies on this page were checked against MITRE ATLAS data release 2026.10 (mitre-atlas/atlas-data on GitHub). The technique is new, so confirm against the current ATLAS text before relying on it.
Key takeaways
- Per-account controls see only a slice. ATLAS notes distribution limits the portion of an operation visible through any single account or pathway.
- Routers behave like resilient infrastructure. They rotate identities, mix adversarial requests with unrelated customer traffic and redirect automatically when a request is blocked.
- Cost optimisation is part of the technique. ATLAS describes routers managing quotas and budgets across accounts, segmenting accounts by purpose and organising requests to maximise cache reuse.
- The scale is industrial. Anthropic reported about 24,000 fraudulent accounts and over 16 million exchanges in campaigns it attributed to three labs, with one proxy network running more than 20,000 accounts at once.
- Correlation and sharing are the defence. The single ATLAS mitigation is a threat intelligence programme that links activity across accounts, providers and intermediaries.
What ATLAS says, and what is AI-specific
ATLAS describes routing infrastructure that divides a workload or prompt suite across pathways and coordinates shifts between accounts, providers or pathways when prices or rate limits change, so the operation adapts while hiding its common control. It may be built on proxy services (ATLAS sub-technique AML.T0008.005 AI Service Proxies), multiple cloud instances, IP pools or coordination across accounts. ATLAS also lists an open-source tool, CLIProxyAPI (AML.S0036), as implementing the technique by round-robin load balancing across configured upstream accounts behind a single API endpoint.
The AI-specific element is the target: the routing serves bulk collection of model outputs, most often for distillation. ATLAS links T0140 with AML.T0063 Discover AI Model Outputs and the new Outputs from AI Models (AML.T0135) and AI Service Request Metadata Sanitization (AML.T0141) techniques, which together describe collecting responses while stripping identifiers that would tie requests to their operator.
| Routing element | What ATLAS and the case studies describe | Defender's view |
|---|---|---|
| Account pools | Compromised, fraudulent and bulk-purchased accounts used in rotation | Many low-volume accounts with shared traits |
| Multiple pathways | Native APIs, cloud-hosted model endpoints, third-party aggregators and relays | Each provider or platform sees part of the traffic |
| Traffic mixing | Adversarial requests blended with unrelated customer traffic | A reseller account that looks like a normal busy customer |
| Automatic failover | Requests redirected when blocked; banned accounts replaced | Enforcement on one account has little effect |
| Quota and cost management | Budgets allocated across accounts, cost-aware pathway choice, cache reuse | Usage that tracks pricing and rate-limit changes closely |
| Identifier removal | Organisational identifiers stripped from requests (AML.T0141) | Missing or uniform metadata across unrelated accounts |
Cases in ATLAS
Distillation of Anthropic Claude (AML.CS0056). Anthropic reported on 23 February 2026 that three labs it named used commercial proxy services that resell access to frontier models. It described "hydra cluster" architectures spreading traffic across its API and third-party cloud platforms, so a banned account is simply replaced. One proxy network ran more than 20,000 fraudulent accounts at once and mixed distillation traffic with unrelated customer requests. For one lab, traffic was synchronised across accounts, with identical patterns, shared payment methods and coordinated timing, which Anthropic read as load balancing. ATLAS maps the distribution of requests across accounts and pathways to AML.T0140.
Distillation of Google AI services (AML.CS0075). Google Threat Intelligence Group and Google DeepMind reported actors rotating queries across thousands of valid accounts in different product channels to obscure their origin and bypass security controls, using a mix of compromised and fraudulent accounts. ATLAS maps the account takeover side to AML.T0139 Compromise Accounts.
Joint advisory on industrial-scale distillation (AML.CS0076). As summarised by ATLAS, NSA, CISA and FBI attributed campaigns to six China-based AI companies collecting outputs from US models since at least late 2024. Centralised infrastructure distributed requests across provider APIs, cloud services, third-party aggregators, relays and account pools, with service-health monitoring, automated failover when blocked, central quota and budget management and cost-aware pathway selection. Operators also removed organisational identifiers from requests and used automated quality checks to tell defensive countermeasures apart from ordinary service problems.
Detecting coordinated routing
No single request is malicious. Detection works on populations of accounts and on content patterns, which is why it sits mostly with providers and large platforms.
| Signal | Example | Source |
|---|---|---|
| Synchronised behaviour across accounts | Identical prompt templates, coordinated timing, similar volumes | Anthropic, DeepSeek-attributed traffic |
| Shared registration or payment attributes | Shared payment methods, related registration details | Anthropic; ATLAS AML.T0021 |
| Infrastructure overlap | IP address correlation, shared hosting or proxy ranges | Anthropic attribution signals |
| Content aimed at training value | Highly repetitive prompt structures, volume concentrated on narrow capabilities, chain-of-thought elicitation | Anthropic behavioural red flags |
| Instant replacement after enforcement | New accounts picking up the same workload after a ban | Anthropic hydra clusters; CS0076 failover |
| Usage tracking price or rate-limit changes | Traffic shifting between pathways when a limit is reached | ATLAS technique description |
Anthropic describes classifiers and behavioural fingerprinting for distillation patterns in API traffic, including chain-of-thought elicitation, plus detection of coordinated activity across large numbers of accounts. See the Model Extraction and Distillation Defence Guide for extraction-specific controls.
Responding and reducing the payoff
- Cluster before you ban: map the related accounts, payment instruments and infrastructure first; banning one account at a time feeds automatic failover.
- Enforce on the cluster: act on all linked accounts together and watch for replacements that inherit the workload.
- Reduce output value: Anthropic describes product, API and model-level safeguards to make outputs less useful for distillation without degrading legitimate use, and Google reported protecting internal reasoning traces.
- Tighten the onboarding paths that are abused: Anthropic strengthened verification for educational, security research and startup accounts, the routes most often used to set up fraudulent accounts.
- Share indicators: Anthropic shares technical indicators with other AI labs, cloud providers and authorities. This is the substance of AML.M0042.
What enterprises and intermediaries can do
- Keep your accounts out of the pool: compromised enterprise accounts are one supply line, so the controls in AML.T0012 Valid Accounts and the LLMjacking Guide apply directly.
- If you run an AI gateway or aggregator: know your downstream customers, keep per-customer attribution in upstream requests where your provider agreements allow it, and watch for one customer whose traffic looks like a bulk collection job. See the AI Gateway and LLM Gateway Guide.
- Do not route through unvetted relays: unofficial resellers of model access may be part of this infrastructure, and your prompts would pass through it.
Metrics
- Share of enforcement actions taken at cluster level rather than single account.
- Median time for a banned workload to reappear on new accounts (should rise over time).
- Number of indicators shared with and received from peers per quarter.
- Share of high-risk onboarding paths (credits, research and startup programmes) with enhanced verification.
- Detection rate of known distillation prompt patterns in red-team replays.
Framework mapping
| Framework | Item | Relevance |
|---|---|---|
| MITRE ATLAS | AML.T0140 Centralized AI Service Request Routing, tactic AML.TA0007 Defense Evasion | The technique |
| MITRE ATLAS | AML.M0042 Threat Intelligence Program | The only mapped mitigation in release 2026.10 |
| MITRE ATLAS | AML.T0008.005 AI Service Proxies, AML.T0021 Establish Accounts, AML.T0139 Compromise Accounts | Infrastructure and account supply that routing depends on |
| MITRE ATT&CK | M1019 Threat Intelligence Program | Enterprise equivalent of the mitigation |
| NIST CSF 2.0 | ID.RA-02 Cyber threat intelligence is received from information sharing forums and sources; DE.AE-02 potentially adverse events are analysed | Sharing and correlation outcomes |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, SI-4(4) Inbound and Outbound Communications Traffic | Monitoring traffic at population scale |
See M1019 Threat Intelligence Program and the MITRE ATLAS Mitigations Guide.
Common failure patterns
- Per-account thresholds only. Each account stays under the limit while the operation as a whole collects millions of responses.
- Banning one account at a time. Automatic failover replaces it within minutes.
- Treating resellers as ordinary customers. A busy reseller account can carry distillation traffic mixed with legitimate users.
- Abuse and security teams working separately. Payment fraud, trust and safety and security each hold one signal; correlation needs all of them.
- Not sharing. Each provider sees only its own pathway, and the operation simply shifts to the next one.
Practitioner checklist
- Build cross-account clustering on prompts, timing, payment and infrastructure.
- Score traffic for distillation patterns such as chain-of-thought elicitation and repetitive templates.
- Enforce on whole clusters and track replacement accounts.
- Add verification to credit, research and startup onboarding programmes.
- Agree indicator sharing with peers, cloud platforms and authorities.
- For gateways and aggregators: know downstream customers and keep attribution.
- For enterprises: protect AI credentials and avoid unofficial resellers.
Standards and references
- MITRE ATLAS: Centralized AI Service Request Routing (AML.T0140)
- MITRE ATLAS: Threat Intelligence Program (AML.M0042)
- MITRE ATLAS: Model Distillation Campaigns Targeting Anthropic Claude (AML.CS0056)
- MITRE ATLAS: China-Based AI Companies Conducting Industrial-Scale Distillation Campaigns (AML.CS0076)
- Anthropic: Detecting and preventing distillation attacks
- MITRE ATT&CK: Threat Intelligence Program (M1019)
- MITRE ATLAS: Model Distillation Campaigns Targeting Google AI Services (AML.CS0075)
Related NHI Mgmt Group resources: Model Extraction and Distillation Defence Guide · Threat Intelligence for Identity and NHI Guide · MITRE ATLAS Guide