In this blog post DeepSeek, Moonshot and MiniMax Caught Copying Claude What Anthropic Used we will unpack what actually happened, how Anthropic says it proved the copying, and the practical lessons for IT leaders and engineering teams deploying AI in real products.
If you’re building with AI, this story matters for one simple reason: the same techniques used to “copy” a model can also be used to extract sensitive behaviour from your own AI systems, run up your API bills, and create real compliance and security headaches.
High-level first What does “stealing from Claude” even mean
When most people hear “stealing,” they imagine someone downloading a model file or hacking a server. That’s not what this is.
What Anthropic described is closer to industrial-scale scraping, but instead of scraping a website, attackers hit an AI model with millions of prompts, collect the answers, and then use those answers to train their own model. This technique is commonly called distillation.
Distillation itself is not automatically bad. Labs distill their own models all the time to create cheaper, faster versions. The problem is when another organisation does it without permission, using fake accounts and proxy networks to bypass controls.
The core technology behind it Model distillation in plain English
Distillation is a “teacher-student” approach:
- Teacher model: a large, expensive, high-performing model (in this case, Claude).
- Student model: a smaller (or cheaper-to-run) model you want to improve.
- Training signal: instead of training only on raw text from the internet, you train the student on the teacher’s answers (and sometimes the teacher’s preferred style, formatting, tool choices, or step-by-step reasoning patterns).
Why this works: the teacher’s answers contain a lot of “compressed know-how” about how to solve tasks. If you can generate enough high-quality answers across enough task types, you can train a student model that behaves similarly.
Where it crosses the line
Anthropic’s claim wasn’t “they asked Claude questions.” It was that the traffic looked like automated, coordinated data collection designed for training, at a scale and structure that normal usage doesn’t match.
What Anthropic said it observed (the non-hand-wavy evidence)
Anthropic says it detected campaigns attributed to DeepSeek, Moonshot, and MiniMax that collectively produced over 16 million exchanges using roughly 24,000 fraudulent accounts.
It also described how different labs focused on different capability areas, like reasoning, coding, tool use (where the model calls external tools like a browser or code runner), and attempts to extract step-by-step reasoning traces.
So how did Anthropic “prove” it Practical detection signals
In the real world, you rarely “prove” this with a single smoking gun. You prove it the way security teams prove fraud: by combining multiple indicators that, together, form a pattern that’s hard to explain as legitimate customer activity.
1) Behavioural fingerprinting not just IP blocking
Attackers can rotate IP addresses, use proxies, and create new accounts quickly. So modern detection focuses on behaviour instead of identity.
Anthropic described using behavioural fingerprinting and classifiers to detect extraction patterns in API traffic. In plain terms, this means:
- Looking for repetitive prompt shapes that resemble training set generation.
- Detecting high-volume, narrowly focused interactions (for example, millions of prompts that all target one capability like agentic coding).
- Spotting coordinated activity across many accounts that behaves like one system, not thousands of independent humans.
2) Multi-account coordination the “hydra” pattern
Anthropic described large pools of accounts (sometimes thousands at once) distributing traffic so that banning one account doesn’t stop the campaign.
This matters because a single account doing 10,000 requests a minute is obvious. But 10,000 accounts doing a smaller number each can look “normal” unless you correlate them.
Correlating at scale typically involves features like:
- Similar prompt templates across accounts
- Shared timing patterns (bursts, schedules, handoffs)
- Common “goal prompts” (the same intent expressed with slight variations)
3) Targeting “hard-to-get” outputs like reasoning traces
One of the more telling signals in distillation campaigns is when prompts repeatedly try to get the model to reveal internal reasoning, hidden steps, or structured rubrics that are especially useful for training.
For engineering teams: this is the difference between “give me the answer” and “show me your step-by-step thought process, scoring rubric, and alternative approaches.” That second style is far more valuable as training data.
4) Rapid pivoting when a new model drops
Anthropic described one campaign that redirected large portions of traffic soon after a new Claude model was introduced.
That’s a strong indicator of capability harvesting. A normal business user doesn’t immediately reorganise half of their usage patterns because a model got upgraded. A team trying to “capture” the newest behaviour does.
5) Mixing “normal” traffic with extraction traffic
Another practical trick is to blend in: interleave legitimate-looking prompts with extraction prompts, so the overall traffic doesn’t look like a single-purpose attack.
This is exactly why detection needs to be multi-layered. It’s not enough to watch volume. You also watch intent, structure, and coordination.
A simple technical mental model for distillation detection
If you run an AI API (or even an internal AI gateway), think of distillation detection like credit-card fraud detection:
- Velocity checks: too many requests too quickly.
- Similarity checks: too many prompts that look like minor variants of the same template.
- Graph checks: too many accounts behaving like a single entity.
- Change sensitivity: sudden shifts right after a model release.
None of these alone is perfect. Together, they build a credible case.
Why this matters to Australian businesses (even if you don’t build models)
You might be thinking: “We’re not an AI lab, so why do we care?” Three reasons.
1) Cost blowouts look like “mysterious usage spikes”
If you offer AI features to customers, distillation-style abuse can show up as a sudden API cost increase. It’s the AI equivalent of someone hammering your login page or scraping your website.
2) Data leakage isn’t always files leaving your network
When users interact with AI, they often reveal process knowledge: how you handle incidents, how you draft proposals, internal policies, support playbooks, and more.
If your AI assistant has access to sensitive content, extraction attempts may aim to reconstruct those workflows at scale.
3) Compliance risk ties back to governance and controls
For Essential 8 (the Australian Government’s baseline cybersecurity framework many organisations align to), the themes here map to real controls: limiting admin privileges, using multi-factor authentication, logging, monitoring, and having incident response processes.
AI adds a new “surface area” you need to monitor like any other business system.
A real-world scenario we see a lot (anonymised)
A 180-person professional services firm rolled out an internal AI assistant for staff to draft emails, summarise documents, and answer policy questions.
Within weeks, their AI usage costs became unpredictable. The culprit wasn’t staff adoption. It was an external script hitting a poorly protected endpoint they exposed during a pilot, generating thousands of requests overnight.
Nothing was “hacked” in the Hollywood sense. But the business outcome was still real: higher bills, higher risk, and a rushed clean-up that interrupted staff.
This is why CloudPro Inc treats AI like any other production workload: identity controls, logging, monitoring, and sensible rate limits, not just “a cool new app.”
Practical steps for IT leaders and developers right now
1) Put an AI gateway in front of your model access
Even if you use multiple models (OpenAI, Claude, Azure-hosted models), centralise authentication, logging, and rate limiting.
2) Monitor for extraction patterns
Look for repeated prompt templates, unusually narrow task focus, high concurrency, and sudden activity outside business hours.
3) Treat prompt logs as sensitive security telemetry
They can contain customer data, internal policy content, and proprietary workflows. Lock them down like you would application logs.
4) Design your AI features to be “harder to copy”
The goal isn’t secrecy. It’s reducing the value of raw outputs for bulk training.
- Return only what the user needs (avoid long verbose outputs by default).
- Use task-specific formatting that’s helpful for users but less useful as generic training data.
- Where appropriate, add lightweight friction for high-risk endpoints (for example, stronger authentication).
5) Know your terms, your vendors, and your obligations
If you provide AI features to customers, make sure your acceptable-use rules are enforceable, and your monitoring is good enough to back them up.
Wrap-up What to take away from the Claude distillation story
The headline is dramatic, but the lesson is practical: AI systems can be “copied” through usage, not intrusion. Anthropic’s detection approach, as described publicly, is based on behavioural signals that any mature platform team should recognise: coordination, repetition, volume, and rapid pivoting after model upgrades.
CloudProInc helps Australian organisations deploy AI safely using Microsoft’s ecosystem (Azure and Microsoft 365) and modern security practices, with hands-on support that’s pragmatic, not theoretical.
If you’re not sure whether your current AI setup is exposing you to unnecessary cost or risk, we’re happy to take a look and give you a straight answer, no strings attached.