Contribution
This post adds a defensive method for finding a distillation campaign that has been split across accounts, proxy routes and model endpoints. The method builds an account-route-workload graph, then looks for coordinated demand that stays ordinary when each account is viewed alone. It is a detection contribution: the two source reports describe the component signals, while the graph join and its tuning procedure below turn them into one reproducible investigation.
The pattern
On 8 September 2026, CISA, the NSA and the FBI published AA26-251A, a joint advisory on industrial-scale knowledge distillation against US model providers. The agencies attribute campaigns since at least late 2024 to several China-based AI companies. They describe billions of tokens collected through millions of exchanges against frontier models, with access spread across native APIs, cloud providers, aggregators and grey-market proxy services known as 'transfer stations'.
The important detail is the distribution. A provider that watches one API key, IP address or reseller at a time sees fragments. The operator behind the campaign can keep an individual subscription near its quota, rotate an account when challenged and send the next batch through another route. AA26-251A calls out shared accounts appearing from different IPs and user agents, continuous use without human idle periods, new subscriptions moving straight to maximum usage and coordinated switching when prices or rate limits change.
Anthropic's September 2026 threat intelligence report gives the provider-side view. It reports that Zhipu rotated through 273 fraudulent accounts during a ten-day chain-of-thought extraction campaign, with 770,609 exchanges passing through a cleaner and more than three million associated exchanges over the same period. Anthropic also reports more than 400,000 Xiaomi-linked requests routed across more than 1,500 accounts through proxy services, with the campaign observed over twenty days in March and April 2026. Anthropic reports that Moonshot and DeepSeek relayed customer requests to Claude and replayed reasoning signatures across sessions to recover reasoning traces.
The reports agree on a useful distinction. High volume is evidence, but it is not the offence. Legitimate coding products, evaluation services and enterprise gateways can consume large numbers of tokens. The suspicious unit is a coordinated account population whose members share infrastructure or workload characteristics while acting as if they are unrelated customers.
The data risk also extends beyond model capability. Anthropic reports that some relayed sessions contained corporate code, credentials, personal details and surveillance material supplied by users who believed they were talking to another service. A proxy or model router that secretly forwards prompts can therefore act as both an extraction channel and a processor of customer data outside the expected trust boundary.
This is why a per-account threshold is a poor primary control. It catches the clumsiest burst and misses the account pool. The investigation should start with relationships: which accounts were created together, which routes they share, which prompts follow the same template, and whether their combined output has the regularity of a training-data pipeline.
Why it matters to cloud defenders
Most organisations are not frontier model providers, but many now operate an AI gateway in front of Azure OpenAI, Amazon Bedrock, Vertex AI or direct model APIs. That gateway is where teams apply cost controls, route requests and attach a business identity to model use. It is also the only place where activity split between several upstream providers can be joined under one policy.
Three exposure cases deserve attention. The first is a company selling an AI-backed service whose own accounts are being used to extract its model behaviour. The second is an enterprise reseller or internal gateway whose credentials are quietly feeding an external collection pipeline. The third is an employee or product team sending sensitive prompts through an unapproved intermediary that logs and resells the exchanges.
Cloud billing alone will not distinguish those cases. A cost anomaly can show that token use changed, but it usually lacks prompt family, account age and route history. Model telemetry alone has the opposite weakness: it can show repetitive requests without identifying that several keys share a payment instrument, deployment identity or egress network. Identity logs can show account creation and verification changes, but not what the accounts asked for.
The practical detection surface therefore spans the model gateway, identity system and network edge. Preserve a stable principal identifier, credential identifier, account creation time, model name, input and output token counts, request timestamp, response status, source network and a privacy-safe prompt fingerprint. Where policy permits, add a payment or subscription identifier as a one-way token. Do not place raw prompts in a general SIEM merely to make this detection possible. A keyed fingerprint of a normalised prompt template can reveal reuse without turning the security platform into a second store of customer content.
Cloud defenders also need to separate their own automation from a hostile collection pipeline. Regression testing, red-team evaluations and synthetic-data jobs can look remarkably similar. The difference is governance. Approved jobs should have an owner, a declared source workload, a known account set and a scheduled window. Activity with the same machine cadence but no matching registration should not inherit trust because its traffic reaches a legitimate API.
ATT&CK mapping
The entry point maps most closely to T1136.003 Create Account: Cloud Account. The account pool in these reports is created at a SaaS or API provider rather than inside a compromised enterprise tenant, so the mapping describes the behaviour, not proof that a customer's IAM environment was breached. It becomes useful to defenders when many fresh service accounts or API principals receive credentials and begin high-throughput use before the normal adoption period.
Use of those authenticated principals maps to T1078.004 Valid Accounts: Cloud Accounts. The accounts are valid at the service boundary even when they were created or acquired to break policy. The reports do not say that every credential was stolen, so a valid-account event must stay separate from an account-takeover claim. Detection comes from how a group of authenticated principals behaves, not from treating every successful API call as hostile.
Proxy services and transfer stations resemble ATT&CK T1090.002, External Proxy. Some operations may involve multi-hop chains under T1090.003, but the available reporting does not prove that every request crossed several proxies. Treat the last visible address as a route attribute, not as actor identity. Rotation across cloud endpoints and aggregators is more important than any single IP reputation result.
The collection stage maps to T1119 Automated Collection. A distillation worker issues templated requests, saves responses and repeats the job across a capability domain. The object being collected is unusual: model outputs, reasoning traces and cleaned exchanges rather than files from a compromised host. T1020, Automated Exfiltration, describes the likely onward transfer into a training pipeline, but the public reporting does not expose that transfer telemetry in enough detail to make it a primary mapping.
T1136.003, T1078.004 and T1119 are listed in this post's technique_ids. Each has a full technique page in this library and each marks a different observable stage: account creation, authenticated use and automated collection. T1090.002 and T1020 remain in the analysis because their fit is conditional and neither should be mistaken for proof of compromise on its own. MITRE ATLAS has the more exact model-extraction vocabulary, including AML.T0040 (AI Model Inference API Access) and AML.T0024.002 (Extract AI Model), but ATLAS identifiers do not belong in an ATT&CK technique field.
The chain is therefore: create or acquire cloud service accounts, hide their common operator behind changing routes, issue coordinated extraction workloads, then collect the responses for cleaning or training. Detection has to follow that chain. A rule on account creation alone is weak, and a token-volume alarm at the end arrives after much of the output has already left.
Detection guidance
Start by building one event stream at the AI gateway. Each row should contain principal_id, credential_id, account_created_at, route_id, asn, user_agent_family, model_id, input_tokens, output_tokens, prompt_fingerprint and request_time. route_id can be a privacy-safe hash of the observable egress attributes. prompt_fingerprint should remove volatile values such as repository names and random seeds before hashing, while retaining the instruction shape and requested capability.
Calculate baselines separately for interactive users, registered batch jobs and resellers. For each class, retain the distribution of hourly output tokens, active minutes per day, idle gaps, prompt-fingerprint reuse and the number of routes seen per principal. Percentiles from the organisation's own history are safer than a universal request limit because model size, workload and pricing change.
Next, form a rolling graph. Accounts are nodes. Add an edge when two accounts share a route, recovery attribute, subscription token or unusually similar prompt family within the same observation window. Weight direct identity links more heavily than a common public-cloud ASN. A single shared exit node is cheap evidence; synchronized prompt batches across that node and a second route are much harder to explain as coincidence.
A workable first alert requires all of the following:
- A connected component contains at least three recently created or newly activated principals.
- Its combined output-token rate exceeds the 99th percentile for the matching customer class, while at least half of its members remain below their individual 95th percentile.
- The component repeats the same prompt family across two or more route identifiers with start times falling inside one normal batch interval.
- No approved evaluation, reseller or synthetic-data registration owns the account set and window.
Those values are starting points, not claims about the campaigns in the reports. Back-test them against thirty days of local telemetry and move them until approved batch jobs stop paging without erasing the split-account case. Keep the component's members, edge reasons and baseline class in the alert so an analyst can see why separate accounts were joined.
The strongest confirming signals come after the first graph match. Look for quota exhaustion that hands off from one account to another, abrupt route changes after a challenge, near-continuous use across local night hours and repeated requests aimed at one capability such as agentic tool use, coding and data analysis, or logical reasoning. AA26-251A also notes traffic tuned for cache reuse and coordinated pathway changes after price or rate-limit shifts. These are campaign behaviours, not standalone block conditions.
False positives cluster around legitimate evaluators. A model quality team may deliberately run the same prompt suite against several models. A gateway vendor may multiplex many customers behind a small set of addresses. University research can involve fresh accounts and sustained experiments. Close those cases with ownership and consent evidence: named programme, registered account group, declared dataset, expected duration and permission to retain outputs. An explanation such as 'research traffic' without an owner should not clear a high-volume graph.
Do not automate response degradation from a low-confidence anomaly. The joint advisory recommends that model providers subtly alter responses to suspected malicious distillation attempts, while Anthropic describes enforcement at the organisation level rather than banning one proxy account at a time. For most enterprises, the safer response ladder is to preserve evidence, reduce burst quotas, require renewed identity verification and contact the account owner. Block or change service only when the graph has a strong identity link or the operator confirms abuse.
What to do now
First, check whether your model gateway can join usage to a stable business identity. If API keys are the only identity, add an ownership registry and record key creation, rotation and revocation. Export account lifecycle events alongside model requests so a fresh principal reaching batch-level throughput is visible in one investigation.
Second, add prompt-template fingerprints at the gateway rather than copying prompt bodies into the SIEM. Document the normalisation method, key the hash to prevent outside dictionary matching and set a short retention period. Security needs enough information to correlate repeated workloads, not an indefinite archive of customer conversations.
Third, register legitimate high-volume jobs. Give each evaluation or synthetic-data run an owner, account set, source workload and expiry date. Feed that registry into the detector as context, then alert when a machine-like workload has no live registration or continues after its window closes.
Fourth, back-test the account-route-workload graph. Seed it with a controlled exercise that spreads one prompt suite across several test principals and two egress routes, keeping each account below its normal individual threshold. The detector passes only if it joins the accounts and explains the edges. A cost alert that notices the aggregate bill but cannot identify the coordinated principals is not enough.
Finally, establish an escalation route with model providers and API aggregators. Share the minimum useful indicators, such as hashed route clusters, account creation bands, prompt-family fingerprints and synchronized timing, under an agreed handling policy. AA26-251A argues that distribution across providers defeats single-point detection. Anthropic's report shows why organisation-level attribution matters: removing one account from a pool of hundreds leaves the collection system intact.