# CISA AA26-251A: the AI distillation advisory, explained

URL: https://infro.io/blog/cisa-ai-distillation-advisory-aa26-251a
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-21
Last modified: 2026-10-21
Last reviewed: 2026-10-21 (next review due 2026-11-20)
Topic: Security and governance
Format: Guide

> CISA, NSA and FBI advisory AA26-251A (8 September 2026) says six China-based AI companies ran industrial-scale distillation campaigns against US frontier models through fraudulent accounts, shared subscriptions and gray-market API proxies called transfer stations. It lists detection indicators such as shared accounts across many IPs, 24/7 usage with no idle periods and new accounts at maximum usage, and recommends detection, response alteration and information sharing to US AI companies. It has no section for ordinary key holders; mapping its indicators to your own keys is inference, set out below.

Key takeaways:
- AA26-251A (8 September 2026) names DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI and says they distilled Claude, GPT, Gemini and Grok models since at least late 2024.
- Its indicators are behavioural: shared accounts across many IPs or user agents, 24/7 usage, new accounts at maximum usage at once, uniform behaviour across account pools, cache-optimized usage, coordinated pathway switching.
- Its mitigations are for US AI companies: detection, subtle response alteration, and cross-industry information sharing.
- It does not mention stolen API keys; Anthropic's September report does. Mapping the indicators to your own keys is inference, and still worth doing.
- Most of the checks need the provider's usage by key, not only your own logs, because abuse on a stolen key never passes through your systems.

**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 models[1]. 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](https://infro.io/blog/what-is-ai-distillation-attack).

## 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 them[1]. 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 product[1]. BleepingComputer's coverage summarizes the same names and indicators[2].

## 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 detection[1].
- **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 traceability[1]. [AI API proxy risks](https://infro.io/blog/ai-api-proxy-transfer-stations-risks) covers this market.
- **Fraudulent accounts.** Accounts not registered to legitimate users, often with similar registration details and payment methods[1].
- **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 quotas[1].
- **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 blocked[1].

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 models[1].

## The indicators

The advisory describes four techniques it says are not in MITRE ATLAS, each with detection indicators[1].

| 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 topics[1].

## The mitigations, and who they are for

The advisory recommends three immediate actions to US AI companies[1]:

1. **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.
2. **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.
3. **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 mitigations[3].

## 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 individuals[4]. Anthropic's February post also describes proxy networks mixing distillation traffic with unrelated customer requests[5].

**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](https://infro.io/blog/detect-gateway-bypass-provider-usage) and [signs an AI API key is being abused](https://infro.io/blog/signs-ai-api-key-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.

> **Example: Reading one key against the indicators**
> An organization has a key for a customer-support summarizer that runs from 08:00 to 20:00 on weekdays from two cloud regions. The provider's usage report shows the key active every hour over a weekend, on a reasoning model the summarizer never calls, at a volume forty times its weekday average, and the organization's gateway log for the same period shows normal weekday traffic only. Four of the advisory's indicators line up: around-the-clock usage, a model switch, volume out of pattern and traffic missing the organization's own markers. The key is revoked at the provider and replaced.

## 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.

## Questions

### What is CISA advisory AA26-251A?

A joint cybersecurity advisory from NSA, CISA and FBI, released on 8 September 2026, titled 'China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies'. It describes how six named companies extracted capabilities from US frontier models through API access, with indicators and recommended mitigations.

### Which companies does AA26-251A name?

DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI. The advisory says they distilled models from the Claude, GPT, Gemini and Grok families since at least late 2024, likely with Chinese government awareness.

### Does AA26-251A apply to companies that only use AI APIs?

Its recommendations are addressed to US AI companies, cloud providers, API aggregators and infrastructure providers. It has no section for ordinary API customers. Its indicators can still be applied to your own keys as a way to spot misuse, but that application is your inference, not the advisory's guidance.

### Does the advisory mention stolen API keys?

No. It describes fraudulent accounts, shared or bulk-bought subscriptions and gray-market proxies. Anthropic's September 2026 threat report separately says the proxy services behind such campaigns often use stolen API credentials of legitimate companies and individuals.

## Sources

1. China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies (AA26-251A) — CISA, NSA and FBI. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-251a (accessed 2026-10-21)
2. US says Chinese firms extracted billions of tokens from frontier AI models — BleepingComputer. https://www.bleepingcomputer.com/news/security/us-says-chinese-firms-extracted-billions-of-tokens-from-frontier-ai-models/ (accessed 2026-10-21)
3. LLM10:2025 Unbounded Consumption — OWASP GenAI Security Project. https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/ (accessed 2026-10-21)
4. Countering misuse of AI: September 2026 — Anthropic. https://www.anthropic.com/threat-intelligence-report-september-2026 (accessed 2026-10-21)
5. Detecting and preventing distillation attacks — Anthropic. https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks (accessed 2026-10-21)