What is CISA AA26-251A? It is a joint advisory from NSA, CISA and FBI, released on 8 September 2026, that says six China-based AI companies ran industrial-scale distillation campaigns against US frontier models: harvesting their outputs and reasoning through API access to train their own models1. It describes the access pathways, including gray-market API proxies called "transfer stations", lists behavioural indicators, and recommends detection, response alteration and information sharing to US AI companies. It does not address ordinary API customers; this guide summarizes what it says, then sets out, as our own inference, how its indicators map onto checks you can run on your own keys.
For background on the technique itself, see what a distillation attack is.
The advisory at a glance
| Title | China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies |
| Released | 8 September 2026 |
| Authoring agencies | NSA, CISA, FBI |
| Companies named | DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun, Z.AI |
| Models targeted | Variants of Claude, GPT, Gemini and Grok, since at least late 2024 |
| Framework | MITRE ATLAS techniques and mitigations, NIST AI 100-2e2025 |
| Addressed to | US AI companies; cloud providers, API aggregators and infrastructure providers for coordination |
The advisory says the six companies extracted billions of tokens across millions of exchanges, likely with Chinese government awareness, and treats distillation as a core development strategy for them1. It gives per-company detail, for example that DeepSeek distilled from Claude, Gemini, GPT and Grok models between late 2024 and mid-2025, and that MiniMax used prompt injection to try to make Claude Code believe it was a MiniMax product1. BleepingComputer's coverage summarizes the same names and indicators2.
How the advisory says the campaigns get access
The access story is the part most relevant to anyone who holds an AI key.
- Multiple pathways. Requests are routed through native APIs, remote cloud providers and third-party aggregators that strip user metadata to avoid detection1.
- Transfer stations. A gray market of API proxies that the advisory says resell access to frontier models at a fraction of the official price, bypassing regional restrictions, breaching terms of use, evading safeguards and undermining traceability1. AI API proxy risks covers this market.
- Fraudulent accounts. Accounts not registered to legitimate users, often with similar registration details and payment methods1.
- Shared premium subscriptions. Subscriptions bought in bulk and shared across teams of developers, with StepFun structuring access around account pools and load distribution to avoid exhausting quotas1.
- Centralized routing. In-house systems that send requests across native APIs, cloud providers, aggregators, relays and vendor account pools, with health monitoring, quota enforcement and automated failover when one path is blocked1.
On the extraction side it lists jailbreaks and prompt injection, chain-of-thought extraction, automated sanitization of organizational identifiers, quality evaluation frameworks that detect degraded responses, and rapid retargeting of new models1.
The indicators
The advisory describes four techniques it says are not in MITRE ATLAS, each with detection indicators1.
| Technique (advisory's name) | Detection indicators the advisory lists |
|---|---|
| Regional restriction evasion and subscription exploitation | Shared accounts used from multiple IPs or user agents; 24/7 sustained usage without human variation or idle periods; anomalous subscription-to-API usage ratios; new subscriptions immediately at maximum usage rather than gradual adoption |
| Centralized request routing infrastructure | Consistent operational patterns across diverse account pools; correlated timing or behaviour across different pathways |
| Automated request metadata sanitization | Sudden behaviour changes after disclosures, especially consistent metadata disappearing; missing expected markers in high-volume activity; generic or randomized patterns replacing organizational indicators |
| Systematic quota and cost optimization | New accounts with unusually high immediate hit rates; usage optimized for cache hits rather than task diversity; coordinated pathway switching after pricing or rate changes |
Its ATLAS mappings add more: multiple accounts with similar registration details and payment methods, frequent switching between models, use of third-party aggregators, highly coordinated identical or similar prompts, and query volumes in the thousands to millions on similar topics1.
The mitigations, and who they are for
The advisory recommends three immediate actions to US AI companies1:
- Comprehensive detection and mitigation of anomalous prompts, accounts, networks and behaviours, including monitoring subscription-to-usage ratios, maximum usage from new accounts and enterprise-scale throughput.
- Targeted response changes, such as differential privacy or quietly answering suspected distillation with a downgraded model, varied so that the change is hard to detect, and without informing the suspected distillers. AI safety researchers and third-party evaluators, by contrast, should be told about model changes.
- Cross-organization information sharing of infrastructure indicators such as IPs, domains, third-party providers, timing and volume patterns across model providers, cloud platforms and aggregators.
It also lists MITRE ATLAS mitigations, among them input detection, rate limits (AML.M0004), access control (AML.M0019) and logging (AML.M0024)1. OWASP files the same family of risks, model extraction and functional replication through the API, under LLM10:2025 Unbounded Consumption, with rate limiting, quotas and usage monitoring among its mitigations3.
What the advisory does not say
Two gaps matter for an ordinary organization.
It does not discuss stolen API keys. The advisory's access story is fraudulent accounts, bulk-bought subscriptions and proxies. Anthropic's September 2026 threat report fills that gap from the provider's side: it says the proxy services that labs route through create accounts with false identities, fake or stolen cards and stolen API keys, and often use stolen API credentials belonging to legitimate companies or individuals4. Anthropic's February post also describes proxy networks mixing distillation traffic with unrelated customer requests5.
It has no section for API customers. Nothing in it tells a company that buys OpenAI or Anthropic access what to do. Everything below is our reading of how its indicators would show up on keys you own.
Our inference: the indicators, checked on your own keys
The advisory's indicators describe how a provider sees abuse across millions of accounts. On a single organization's keys the same behaviours look like this. This mapping is ours, not the advisory's.
| Advisory indicator | What it could look like on your key | Where to check |
|---|---|---|
| Shared accounts across multiple IPs or user agents | One key used from networks or clients your systems do not use | Provider usage or audit logs by key; your gateway's IP restrictions and request log |
| 24/7 usage with no idle periods | A key for a business-hours or nightly workload busy every hour of the day | Hourly usage by key at the provider |
| New subscriptions at maximum usage immediately | A newly created key, or one just pasted into a new tool, at its rate limit within hours | Key creation date against first-day volume |
| Consistent patterns across account pools | Keys in unrelated projects suddenly showing the same traffic shape | Usage by key, compared side by side |
| Correlated timing across pathways | Spikes at the same minutes on your OpenAI and Anthropic keys | Provider usage reports, aligned by time |
| Missing or randomized organizational markers | Requests on your account without the user IDs, project tags or headers your applications always send | Requests on the provider's report that do not appear in your own logs |
| Frequent model switching, pathway switching after price changes | Traffic moving to a newly released or newly repriced model none of your applications use | Usage by model per key |
| Cache-optimized usage, identical prompts at volume | A cache-hit ratio or prompt repetition your workloads never produce | Provider usage fields for cached input; your request log |
The common thread: the decisive signal is traffic on your account that your systems did not send. Your application logs cannot show it, because abuse on a stolen key never passes through them. You need the provider's usage by key, compared against what you know you sent. Detecting traffic that bypasses your gateway and signs an AI API key is being abused go into the method.
The ATLAS mitigations translate too. Rate limits become per-key rate and spend ceilings at the provider; access control becomes keys scoped to one project or workspace with inference permissions only; logging becomes keeping provider usage by key long enough to compare; identity verification becomes an inventory that says who holds each key and why.
How INFRO handles these signals
For traffic that goes through INFRO, several of the checks above are built in. Gateway keys can be limited to chosen IP ranges, refused with 403 ip_not_allowed before any provider call, and to chosen providers and one environment. Budgets per organization, project, member and key are checked before the provider is called and refuse with 402. Spend alerts flag a day that departs from a scope's usual day and budgets forecast to be exceeded, by email, Slack, Teams, PagerDuty or webhook. The request log records model, key and cost per request, with prompt logging off by default, and key changes are in the audit log.
For the decisive signal, traffic that did not go through INFRO, the Business plan's reconciliation reads OpenAI's and Anthropic's cost reports daily with a separate admin credential; with usage access on, it reads token counts by provider key and shows traffic on your account that INFRO did not send. Without usage access it reports "not checked", never "no bypass". It is a daily comparison, not real-time detection.
INFRO's own controls govern traffic that goes through INFRO. A provider key stolen from anywhere, including from a platform like INFRO that stores customers' keys, can be used directly against the provider, and none of INFRO's budgets, allowlists or IP restrictions apply to it. The backstops are at the provider: scoped keys, provider spend limits, revocation, and the provider's own usage reporting.
Summary
AA26-251A is the US government's account of how six China-based companies distilled US frontier models, written for the companies that build those models. Its indicators describe accounts used from many places, around the clock, at full speed from day one, and in lockstep with other accounts. Applied to your own keys, which is our inference, they reduce to one practice: read the provider's usage by key and question any traffic you did not send.