CISA, NSA and FBI allege that six China-based AI companies used industrial-scale knowledge-distillation campaigns to extract capabilities from U.S. frontier AI models. Their September 8 joint advisory says the activity used millions of requests, fraudulent accounts and compromised credentials across multiple product channels. Reuters independently confirmed that the agencies issued the accusation; it did not independently verify the underlying conduct.
Distillation itself is a legitimate method for training a smaller model from the output of a larger one. The agencies' allegation concerns automated extraction that they say violated access restrictions and provider terms. For defenders, the durable lesson is about authorization: an API key that still works is not proof that every request made with it is expected or permitted.
What the agencies allege
The joint advisory names DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI. It says the companies extracted billions of tokens across millions of exchanges with U.S. models, including Claude, GPT, Gemini and Grok, since at least late 2024. It further says proxy infrastructure, resellers, fraudulent identities and compromised accounts were used to distribute requests and avoid ordinary controls.
Those are official U.S. government assessments, not independently proven findings about every named company. The advisory's statement that the activity occurred likely with Chinese government awareness is also an assessment. Public reporting available at publication does not provide the complete evidence set or responses from every company named, so this article preserves attribution rather than presenting the allegations as adjudicated fact.
Google provides independent context for the broader technique. GTIG says it regularly observes coordinated distillation campaigns against Gemini, some exceeding 100 million prompts, with queries rotated across thousands of compromised credentials and fraudulent accounts. That supports the operational pattern, but it does not independently establish each CISA attribution or quantity.
A shared API key collapses identity and accountability
When several people, brokers or workloads reuse one key, the provider loses a clean way to distinguish a legitimate customer action from resale, automation or account takeover. The owner also cannot revoke one route without interrupting every legitimate user. An apparently low-risk shortcut therefore becomes both a security problem and an incident response delay.
- Issue one identity per workload or customer. Avoid organization-wide API keys shared across teams, scripts and resellers.
- Limit what each credential can do. Apply model, endpoint, quota, network and environment restrictions where supported.
- Use short validity where possible. Prefer exchanged or brokered temporary access over indefinitely reusable bearer keys.
- Watch behavior, not just authentication. Detect abrupt volume changes, repeated structured prompts, coordinated account creation, proxy rotation and the same workflow appearing across unrelated accounts.
- Keep ownership evidence. Record who approved a credential, which service received it and how it can be revoked—without storing the plaintext value in the ticket.
Recover from suspected API-key abuse in the right order
- Preserve the request trail. Export relevant identity, token-issuance, billing and API telemetry before retention or attacker activity removes useful context.
- Disable abusive paths. Revoke affected sessions, tokens and intermediary accounts; do not rely on a new key while an attacker can still mint another one.
- Find every copy. Search approved secret stores, CI/CD variables, developer workspaces, support tickets and reseller systems for the exposed credential.
- Create a narrower replacement. Reduce privileges, quota, allowed origins and lifetime instead of reproducing the same broad credential.
- Deliver it outside the suspect path. Verify the recipient and use a clean device and separate channel for the replacement.
- Monitor both keys during cutover. Confirm the old key stops working and the new one exhibits only the expected workload pattern.
Use Secretus for the narrow handoff, not as an API-security control
Secretus can reduce persistent plaintext when an incident owner must deliver a replacement API key or recovery code to a verified operator. A short-lived, one-time encrypted link is preferable to placing the value in a permanent chat or ticket history. For especially sensitive material, the delivery link and the recipient's identity should be verified through separate channels.
Secretus does not identify distillation traffic, validate whether a customer is entitled to model output, enforce API quotas or remediate a compromised account. Those controls belong at the identity, gateway and model-service layers. Secure delivery helps only after the credential's scope, owner and destination are trustworthy.
What remains unknown
The public advisory does not disclose all indicators, the full evidentiary basis for each attribution, the proportion of requests made with compromised rather than fraudulently created accounts, or the technical effect on each targeted model provider. Reuters reports the agencies' accusation, while Google independently describes similar abuse against its own systems. Neither source converts every government assertion into an independently confirmed fact.