The NSA, CISA and FBI published joint advisory AA26-251A on September 8. It names DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI, and says the six have pulled billions of tokens across millions of requests out of Claude, GPT, Gemini and Grok since at least late 2024. The line that matters is in the executive summary: "distillation is not a supplement to these companies' AI model development, but the critical core of it."
Most coverage stops at the accusation. The advisory is more useful for what it tells the labs to do about it, and for the suspect profile it hands them, because that profile fits a lot of legitimate agent traffic.
How the access layer was built
There was no exploit. Anthropic's February writeup put the number at about 24,000 fraudulent accounts and over 16 million exchanges, routed through "commercial proxy services which resell access to Claude" and what it called hydra clusters, networks of accounts that spread traffic across the first-party API and third-party cloud platforms. OpenAI told the House Select Committee the same month that DeepSeek-linked accounts reached its models through obfuscated third-party routers.
The advisory generalizes that into a pathway list: native APIs, remote cloud providers, and "third-party aggregators that automatically obfuscate user metadata to avoid detection". On top sits a gray market of API proxies the document calls "transfer stations", used to "bypass U.S. AI companies' regional restrictions, breach terms of use, evade safeguards, and undermine traceability". The campaigns run "automated failover between pathways during blocking attempts" and "sophisticated quality evaluation frameworks to detect defensive countermeasures". MiniMax "redirected exchanges to a new Claude model within 24 hours of release".
Read as infrastructure, that is an overlay network whose design goal is that no request can be tied to its origin. Every bearer token is replaceable. Every IP is replaceable. The asset is the pipeline behind them, which scores every path and swaps out a degraded one.
What the labs are told to do
Watch behaviour, alter responses, share indicators.
The behavioural guidance is specific. Labs "should strengthen identity verification for accounts and track individual subscriptions with enterprise-scale throughput, accounts deviating from legitimate patterns, and new accounts immediately at maximum usage versus a gradual ramp-up or with consistent quota exhaustion." The TTP section adds: "shared accounts from multiple IPs/user agents, 24/7 sustained usage without human variation/idle periods, anomalous subscription-to-API usage ratios, and new subscriptions immediately at maximum usage as opposed to gradual AI adoption."
The response-alteration section says "targeted changes in response to high-confidence malicious distillation requests can impose meaningful costs", and suggests differential privacy or "less sophisticated 'downgraded' models". Then the sentence to read twice: "Reducing reasoning depth, presenting correct information with different reasoning, or stylistic inconsistencies may evade detection while reducing training usefulness." A good countermeasure, by this definition, is one the other side's quality evaluation does not catch. Anthropic had already said in February it was building "model-level safeguards designed to reduce the efficacy of model outputs for illicit distillation, without degrading the experience for legitimate customers". The advisory turns that into guidance for the whole industry.
Sharing closes the loop. Indicators passed "between cloud providers, model aggregators, and model providers can make distributed infrastructure visible as coordinated campaigns versus isolated anomalies". An aggregator flagged by one provider becomes a signal at the others.
Now describe an agent fleet
A team creates a new organization, gets an API key, and starts a batch of coding or research agents. The account is days old and at its rate limit from the first hour, because agents do not adopt gradually. Traffic runs around the clock with no idle periods, because nothing is sleeping. One key is shared by every worker across autoscaled egress IPs. Requests go through an aggregator for failover and cost, which strips the metadata. That is four of the listed indicators, matched by a fleet doing nothing wrong.
The advisory scopes the response to "high-confidence" cases and each lab will set its own threshold. But the countermeasure is designed not to be noticed, and unlike the distillers, most legitimate teams run no per-path quality evaluation at all. A switch to a shallower reasoning path would surface as a vague sense that the agents got worse.
Two practical consequences follow.
Make the traffic attributable on purpose. One key per workload rather than one key across the fleet. Stable egress where you can get it. Go direct to the provider for anything that matters and keep the aggregator for what can tolerate it, since a flagged aggregator is flagged for everyone behind it. Ramp new accounts instead of pinning them at the ceiling on day one.
Measure what comes back. The distillers keep a held-out evaluation running against every path so a degraded one is replaced within hours. A legitimate fleet needs the same instrument for the opposite reason: to know whether the answers it pays for are the answers it was sold. A fixed set of prompts with known-good outputs, replayed against production daily, is enough to see reasoning depth move.
Where identity lives on the wire
The whole detection section exists because an API key and a source IP are separate facts that a server has to correlate afterwards. "Shared accounts from multiple IPs" is only a signal because the credential and the endpoint have nothing to do with each other.
Pilot Protocol does that binding differently, and the README in our repository lists the pieces under Security: an authenticated key exchange with Ed25519-signed X25519 and AES-256-GCM, "Ed25519 identity keys bound to tunnel sessions", nodes private by default, and a signed mutual trust handshake relayed through the registry. A peer on Pilot Protocol is a key, and the tunnel is bound to that key. There is no shared bearer token to spread across IPs. SYN, reply and rekey rate limits, each with a node whitelist, are daemon flags in the same README's environment table.
That deserves a precise statement rather than a generous one. A key is not a company. Anyone can mint ten thousand of them, and private-by-default only holds if the operator does not start the daemon with the --trust-auto-approve flag that the CLI reference documents. What the binding buys is that the "who" a service rate-limits or refuses is the same "who" that encrypted the packets, so the trust decision happens before the first request instead of being reconstructed from logs after the sixteen-millionth. The Sybil problem stays exactly where the advisory leaves it: with verification, and with indicators shared between the parties who can see the whole picture.
Top comments (0)