Anthropic's new threat report says a rival lab used API access to extract capabilities from a competitor's model — and usage monitoring was the only thing that caught it.
Most conversations about AI misuse imagine a lone bad actor: someone trying to get a chatbot to write malware, or a scammer spinning up synthetic voices. Anthropic's September 2026 threat intelligence report describes something more institutional, and more interesting.
According to the report, ahead of the release of its GLM 5.3 model, researchers at the Chinese AI company Zhipu ran what Anthropic characterizes as a distillation attack against a leading US frontier model. The method was clever in its ordinariness: Zhipu researchers pulled public vulnerability datasets, turned them into capture-the-flag style security challenges, and pushed those challenges at a competitor's model to harvest its reasoning about how to solve them. Anthropic says Claude Opus 4.6 was separately pulled into the same campaign — not as the primary target, but as a grader, used to evaluate and score the other model's responses.
Read that again. One lab allegedly used a second lab's model to mark the homework it was extracting from a third.
What a distillation attack actually is
Distillation, in its legitimate form, is a well-understood technique: you use a large, expensive model to generate high-quality training data, then train a smaller, cheaper model on those outputs. The small model inherits a surprising amount of the big one's behavior. It's how a lot of efficient models get built.
A distillation attack is the same mechanic pointed at somebody else's asset. Instead of distilling your own model, you buy API access to a competitor's, ask it thousands of carefully constructed questions in a target domain, and use the answers to train your model to behave like theirs in that domain. You haven't stolen weights. You haven't breached a network. You've just... been a customer, at scale, with intent.
This is why the cyber-capability framing matters. The campaign wasn't described as an attempt to make GLM 5.3 better at poetry. It targeted the offensive security reasoning of frontier models — arguably the most sensitive capability surface any lab maintains, and the one every lab claims to gate most carefully.
The detection surface is usage, not code
Here's the part that should reframe how business leaders think about their own AI estate.
Nothing in this story was caught by a firewall, a code scan, or a model-level guardrail. There was no exploit to patch. Every individual request was probably within policy. What exposed the campaign was pattern analysis of usage — the shape, volume, sequencing, and topical clustering of API traffic over time.
That's a fundamentally different kind of control than most organizations have built. Enterprise AI governance today is overwhelmingly front-loaded: approve the tool, review the vendor, write the policy, train the staff. It assumes risk enters at procurement. But adversarial use of AI doesn't announce itself at procurement. It looks like ordinary consumption until you aggregate it and notice the shape is wrong.
Anthropic also notes it has added new safeguards making it harder for unauthorized parties to use its models in these ways. Which tells you something about the direction of travel: frontier labs are increasingly behaving like fraud-detection operations, scoring their own customers' behavior in real time.
Three uncomfortable implications for enterprises
1. Your API accounts are an asset someone else wants.If a frontier lab's capabilities can be harvested through legitimate-looking API access, then enterprise API keys — with their generous rate limits, established billing relationships, and clean reputational standing — are valuable to anyone who wants to run volume queries without being obviously themselves. Compromised enterprise credentials aren't just a data-leak problem anymore. They're a laundering vector for capability extraction. And the bill lands on you.
2. "Approved vendor" is not the same as "clean traffic."Most companies cannot answer a basic question about their own AI usage: what does normal look like? Without a baseline of which teams call which models, how often, at what cost, and for what kinds of tasks, anomalous usage is invisible. You will find out from your provider, or from an invoice, or not at all.
3. Model provenance is now a diligence question.If distillation attacks are a live commercial tactic, then some models on the market contain capabilities their builders did not develop and may not fully understand — including safety behaviors that were partially copied. A model distilled from a frontier system inherits capability unevenly; it may pick up the ability to reason about vulnerabilities without inheriting the refusal behavior that was supposed to constrain it. When you evaluate a cheap, fast challenger model, "where did this capability come from?" stops being an academic question.
The practical move
You don't need a threat intelligence team. You need visibility you probably don't have.
- Inventory every AI system and every API key, including the ones engineering provisioned directly and the ones running inside third-party tools on your behalf.
- Instrument spend as a signal, not just a cost. Unexplained volume growth on a single key is the cheapest anomaly detector you will ever deploy.
- Ask providers what they monitor and what they'll tell you. If your vendor detects unusual usage on your account, do you get a call, a dashboard alert, or silence?
- Add provenance to model evaluation. For any non-frontier model you adopt, ask how it was trained and on whose outputs.
- Treat AI credentials like privileged access. Rotation, scoping, and ownership — not a shared key in a config file from 2024.
The headline story here is competitive espionage between labs. The durable lesson is quieter: in AI, the most important security telemetry is usage data. Organizations that can see how their AI is actually being used will catch problems. Organizations that only know which tools they approved will not.