Anthropic says Moonshot served Claude as Kimi: one accuser, 300,000 requests, no published indicators

209 indicators, and none for the Moonshot case

Anthropic's September threat report came with a companion file of indicators for defenders. It has 209 rows. We counted them by harm area: 131 cyber operations, 60 influence operations, 10 surveillance, 8 scams and fraud. None belongs to the illicit distillation section, which is where the company makes its most striking allegation: that Moonshot AI, the Beijing lab behind the Kimi models, quietly passed its own customers' requests to Claude and showed them Claude's answers as if Kimi had written them.

That count does not make the allegation false. Indicators for this kind of case would be account identifiers and customer content, which a provider has good reasons not to publish. What the count does establish is narrower and matters more to a buyer: nobody outside Anthropic can yet test the claim. The allegation is specific, it comes from the one party positioned to see the traffic arrive, and it is serious enough that the attribution has started to fall away: Bloomberg's headline ended "Anthropic Says", but versions circulating on news aggregators and social media by 17 September drop those two words and state the routing as fact. It is still one company's account of its own telemetry.

This briefing sets out exactly what the report says, what it leaves out, who has and has not answered it, and why the evidence people will reach for on social media (Kimi calling itself Claude) cannot settle the question either way. It ends with what a UK organisation buying any third-party AI service should now put in the contract, because the underlying risk does not depend on whether this particular accusation is proved.

What Anthropic actually claims

The allegation sits in the final section of Detecting and countering misuse of AI: September 2026, a 154-page report published on Thursday 10 September 2026 covering activity Anthropic says it disrupted between December 2025 and August 2026. The Moonshot case carries Anthropic's internal designator GTG-16002.

The core sentence is plain. Anthropic says Moonshot "silently forwarded customer requests to Claude, instead of processing them using Kimi", and that users "thought they were using a Kimi model, but received responses from Claude instead." The report then makes five further claims:

• Volume. In one instance, over a ten-day period, Moonshot relayed almost 300,000 customer requests to Anthropic, the vast majority to Opus.
• Access. The traffic ran through a proxy service network of 5,380 accounts Anthropic calls fraudulent, most appearing to be located in Singapore and Japan. Anthropic does not serve China.
• Harvesting. Moonshot saved at least a portion of the relayed exchanges and built a pipeline to extract Claude's chain-of-thought reasoning from them for training.
• Evasion. Claude returns a "thinking signature" rather than raw reasoning. Anthropic says Moonshot saved the signature, opened a new session and got Claude to convert it back into the full trace, which the report calls a cross-session replay attack.
• Exposure. Relayed requests contained sensitive customer information. The report describes a user it assesses was likely affiliated with the People's Liberation Army loading CCTV data about one targeted individual, and an engineer at a major state-owned enterprise whose prompts revealed internal code and live credentials.

Separately, the report attributes "over 23 million exchanges" of distillation activity to Moonshot between May and July 2026. That is a total for the campaign, not a count of Kimi users whose requests were rerouted. Several headlines blurred the two.

The Moonshot case on the record: what Anthropic's report states and what it leaves out (report pages 143 to 149, read in full)

Question	Stated in the report	Not stated
Which Kimi product carried the traffic	"Customer requests" from users who thought they were using Kimi	Consumer app, kimi.com, the API platform or a coding tool
When	One ten-day instance; campaign total covers May to July 2026	The dates of the ten days, or whether they fall inside May to July
How many users	Almost 300,000 requests in that instance	Distinct users, their countries, or whether any were in the UK
Which Claude models	"The vast majority" went to Opus	Which Opus version, or what the rest went to
How attribution was made	High confidence attribution to specific PRC labs, stated for the section as a whole	The method for this case, or the evidence tying it to Moonshot
Whether users were told	Anthropic does not know if Moonshot notified customers	Any Moonshot terms, notices or consent text examined
What Anthropic did	Blocks requests and bans accounts when confident, as general practice	The date or scope of action against these 5,380 accounts

The numbers, worked

Anthropic gives three figures for this case. Taken at face value, they say something about how the traffic was shaped.

Arithmetic on the figures in Anthropic's report (our calculations; the report gives only the inputs)

Calculation	Result	What it does not tell you
300,000 requests over 10 days	About 30,000 a day	Whether traffic was steady or bursty
300,000 requests across 5,380 accounts	About 56 per account, or 5.6 per account per day	Whether all accounts were active in those ten days
23 million exchanges over May to July (92 days)	About 250,000 a day	How much of it was rerouted customer traffic
300,000 as a share of 23 million	About 1.3 per cent	Whether the ten days sit inside the 23 million at all
February figure (over 3.4 million) against September (over 23 million)	About 6.8 times larger	Anything about growth: the periods are not the same

The per-account figure is the interesting one. About five or six requests per account per day looks more like an individual user than a bulk harvester. Our inference, not a claim in the report: if the numbers are right, spreading live customer traffic thinly across thousands of accounts is exactly how you would avoid per-account rate and abuse thresholds. It is also, awkwardly, what legitimate reselling would look like from the provider's side, which is why the attribution method matters and why its absence from the public record is the central gap.

In its February disclosure, Anthropic did say how it tied an earlier campaign to Moonshot: request metadata "matched the public profiles of senior Moonshot staff." The September report gives no equivalent for GTG-16002. It may use the same technique. It does not say so.

Who says what, and who has not answered

Two days before Anthropic published, on Tuesday 8 September, the NSA, CISA and the FBI released joint advisory AA26-251A, naming DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun and Z.AI as running industrial-scale distillation campaigns against US models "likely with Chinese government awareness." It is easy to read that as corroboration. On routing, it is not: the advisory describes Moonshot extracting data from US models to train Kimi, and says nothing about Kimi customers being served another company's answers.

Every public position we could find as of 17 September 2026, read at source except where marked

Source	What it says	What it does not say
Anthropic report, 10 September	Moonshot served Claude to Kimi users and kept exchanges for training	Attribution method, product, dates, indicators
NSA, CISA, FBI advisory AA26-251A, 8 September	Moonshot distilled Claude Fable 5 data into Kimi-K3 and GPT-4o data into Kimi-K2	Anything about rerouting live customer requests
China's Ministry of Commerce, 9 September	US distillation accusations have no factual or legal basis; countermeasures if firms are suppressed	Moonshot or Anthropic by name
Moonshot, Weibo statement, 12 September (via Beijing News)	Online claims about its founder and employees are fabricated; reported to police	Anything about Anthropic, Claude or routing
Moonshot to Bloomberg, 10 September (secondary)	Did not immediately respond outside business hours	Any denial or explanation
Independent researchers	Kimi K3 sometimes calls itself Claude (July testing)	Anything about routing (see below)

No court filing, regulator action or terms-of-service dispute on the public record involves this case. The only enforcement described is Anthropic's own: blocking requests and banning accounts. China's Commerce Ministry answered the US advisory, calling distillation a common, neutral industry practice, and did not address the specific claim that paying customers were misled about which model answered them. That is a different allegation from distillation, and it is the one that matters to a customer.

Why "Kimi says it is Claude" proves nothing about routing

Expect screenshots. In July, The Register reported testing by MATS research fellows in which Kimi K3 said it was Kimi in 6 of 10 unprompted runs and Claude in 4 of 10. Its unprompted Claude claims disappeared after 20 July, which the researchers speculated was a server-side change. They wrote that the finding "is not proof of a distillation".

It is weaker still as evidence of routing. Moonshot published Kimi K3's weights under its own licence, so anyone can run the model on their own hardware, where it cannot forward anything anywhere. A model trained on text that contains Claude transcripts, whether from deliberate distillation or from a web corpus full of them, learns to answer "I am Claude" some of the time. Self-identification tells you something about training data. It tells you nothing about where a given request was served.

The reverse also holds, and the July testing illustrates it. If a server-side change can make a hosted model stop calling itself Claude overnight, then a service that really was routing to Claude could equally strip or rewrite any self-description. Absence of "I am Claude" is not evidence of clean serving.

What would, and would not, prove routing

Routing is a claim about serving infrastructure, so the evidence that settles it comes from infrastructure: logs, contracts, and the traffic itself. Here is how the kinds of evidence people will cite actually rank. This is our analysis, not a method from Anthropic's report.

Evidence for secret model routing, and its limits (pk-sharma.com analysis)

Evidence	What it can establish	What it cannot establish
Model calls itself Claude	Claude-labelled text probably reached training	Routing; open-weight copies do not route
Similar outputs or benchmark scores	The models behave alike	Why: shared data, distillation and routing look the same
Latency, usage counts or error text that track another provider	A live upstream model is plausible	Proof, without controls; selective routing can miss your test
Outages that coincide with the other provider's incidents	Shared dependency is plausible	Which model served which request
Upstream provider's telemetry (Anthropic's position)	Content arriving from a source at volume	Independent confirmation, until the method is shown
Vendor's own logs, contracts, audit or regulator findings	Which requests went where, when, on whose decision	Nothing material; none public here

The DeepSeek case in the same report shows why spot testing is fragile. Anthropic says DeepSeek checked strings in inbound requests to tag users of coding harnesses such as Claude Code, the Claude Agent SDK and OpenCode, and relayed only selected tagged users to Claude Opus. If that is accurate, a buyer probing a service from a clean test client would see the vendor's own model every time. The report does not say what selection, if any, Moonshot applied.

Method, motive and politics

Separating method from accusation means saying three uncomfortable things at once.

Anthropic has a commercial interest. Moonshot is a direct competitor: kimi.com presents K3 as built for agentic programming and knowledge work, which is squarely Claude's market. A finding that a rival's product was partly Claude is valuable to Anthropic. That does not make the finding wrong, and Anthropic is the party that could see the traffic, but it is a reason to want the method on the record.

The timing is political. The report followed a US government advisory by two days, and Beijing framed both as suppression of its AI industry. Readers in the UK should weigh the specific, checkable claims on their own merits rather than as a proxy for that dispute.

The provider read the content. The PLA-linked CCTV example and the engineer's credentials are in the report because Anthropic's investigators examined what arrived through the relayed accounts. Those users had no relationship with Anthropic. Whatever you think of the accounts they were sent through, the lesson for a buyer is blunt: content sent to an AI service can be read by trust and safety staff at every provider it passes through, including ones you never chose.

One further point cuts the other way. The US advisory recommends that AI companies "subtly alter responses for suspected malicious distillation attempts" and avoid telling suspected distillers they have been switched to a downgraded model. That advice targets distillers, and the advisory says safety researchers and third-party evaluators should be told. But it means silent changes to what model answers a request are now recommended practice on the provider side too. The model name on an API call is a label, not an attestation, in both directions.

What it means for a UK buyer

Set Moonshot aside. The general risk this case illustrates is that the model you think you are paying for is not the only party that sees your data. Anthropic's report says that across DeepSeek, Xiaomi and Moonshot, many relayed exchanges came from users of third-party model routing services "commonly used by users in the United States and Europe", and contained names, email addresses and company data of hundreds of end users. It does not break that down by lab, and it does not mention the UK.

UK GDPR already covers the principle. Article 28(2) says a processor "shall not engage another processor without prior specific or general written authorisation of the controller", and under a general authorisation must tell the controller about added or replaced processors so it can object. Article 28(3)(h) requires the processor to allow for and contribute to audits. An upstream model provider that receives your prompts is a sub-processor on any ordinary reading. Two caveats: whether a given AI vendor is your processor or an independent controller depends on its terms, and many consumer and developer terms reserve rights to use content to improve models, which pushes towards the latter.

This is where the friendly-name fallacy bites. The Kimi Open Platform privacy policy, which shows a last update of 30 April 2025 and so, on its face, was the version in force through the period Anthropic describes, says services are provided by Moonshot AI Pte. Ltd. in Singapore, that data is stored on servers in Singapore, and that it shares information with "service providers", listing categories that end with "other information technology providers". It names no model provider. A category list is not a sub-processor list, and a storage location is not an inference path: data can be stored in one country and sent for processing somewhere else. We are not saying the Open Platform was involved; the report does not identify the product. The policy is simply a typical example of wording that would not tell a customer either way.

Contract terms a UK buyer of a third-party AI service should require, and the gap each one closes

Term	What to require	Gap it closes
Named sub-processors	Every model provider that may receive prompts, named per product and endpoint	"Service providers" as a catch-all category
Change notice and objection	Advance notice of new or replaced model providers, with a right to object (Article 28(2))	Silent addition of an upstream model
Model provenance warranty	The named model serves every request; no fallback to another provider's model without consent	A brand name standing in for an attestation
Per-request attestation	Response metadata or logs recording the model, version and serving region for each call	No way to check serving after the fact
Inference location	Where prompts are processed, not only where data is stored	Storage clauses that say nothing about processing
No training on your data	Explicit bar on using prompts and outputs for any model training, by the vendor or its sub-processors	Your content becoming someone's training set
Audit rights	Right to audit or receive independent assurance covering routing, with evidence (Article 28(3)(h))	Assurance that stops at the vendor's front door
Incident notice	Notice if prompts reach an undisclosed party, treated as a personal data breach where personal data is involved	Finding out from a competitor's threat report

What to do, in order

The question that exposes the gap

Anthropic's allegation may well be proved. It may never be tested. Either way, the case shows that a customer of an AI service generally cannot see, from the outside, which model answered a request or who else read it. The only people who knew that Kimi users' prompts, including live credentials, were reaching Claude were the company allegedly doing it and the company receiving it.

So the question for every AI supplier on your register is this: if your service sent our prompts to another company's model tomorrow, what in our contract would oblige you to tell us, and what in your logs would let us check?

Key facts