There is a version of intellectual property theft that requires no network intrusion, no zero-day exploit, and no insider access. It requires only patience, sufficient compute, and an API that works as designed.
This is the distillation attack, and it became a documented commercial reality on 24 February when Anthropic disclosed that DeepSeek, Moonshot AI, and MiniMax had spent months systematically extracting Claude’s capabilities at industrial scale. The mechanism was not elegant in the traditional adversarial sense. It was industrial. Over 24,000 fraudulent accounts generated more than 16 million exchanges with Claude, targeting the model’s most commercially differentiated capabilities: agentic reasoning, tool use, and advanced coding.
The extraction worked because the API was designed to work. Access controls (terms of service, regional restrictions and rate limits) are legal and operational boundaries, not cryptographic ones. Against a well-resourced adversary with a clear technical objective and proxy architectures specifically designed to distribute traffic and evade detection, they functioned as friction. The adversaries planned for the controls that existed and engineered around them. This is a gamble that Anthropic, and every other frontier developer, has implicitly accepted: that the commercial value of broad API access outweighs the extraction risk it creates. Whether that calculus still holds is, at minimum, worth examining.
The operating problem that existing security frameworks have not resolved is more fundamental than it first appears. The attack surface is the product. Traditional security thinking, organised around the premise that attackers want to get in, does not have a clean response to adversaries who are simply asking questions at scale.
How distillation compresses years of investment into months of queries
To understand why this matters beyond Anthropic’s commercial position, it is worth being precise about the causal sequence.
Model development at the frontier requires billions in capital, years of research, and sustained investment in alignment and safety infrastructure. The result is a model whose differentiated capabilities, the patterns learned through that investment, are encoded in billions of parameters. Traditionally, protecting that investment meant protecting access to the model weights themselves: the actual code and data that constitute the trained system.
Distillation bypasses this entirely. Rather than stealing the weights, the adversary reconstructs the behaviour. By submitting carefully chosen queries and collecting the responses, a sufficiently patient actor can generate a training corpus that teaches a smaller model to approximate the outputs of the larger one. Anthropic’s disclosure notes that illicitly distilled models lack the safety guardrails embedded in the original. This creates its own category of downstream risk, but the capability extraction is effective regardless.
The economic logic is asymmetric in ways that should concern enterprise leaders directly. Anthropic’s multi-billion investment was compressed into what was, for the adversaries, a predominantly computational cost: query volume, proxy infrastructure, and the compute needed to train on the extracted corpus. That asymmetry does not favour defenders. It will not self-correct. And it applies, in principle, to any organisation whose AI system operates through an accessible API. In theory, legal controls and terms of service should close this gap. In practice, they establish liability after the fact rather than prevent extraction beforehand. By the time the liability question reaches a courtroom, the capability has already moved.
InformationWeek’s analysis of the incident identifies a supply chain dimension that deserves emphasis: the risk does not terminate at the AI developer. It propagates to every enterprise that builds workflows on top of distillable systems.
What this changes for organisations using frontier models
The enterprise exposure here is second-order, and it is the layer that most risk frameworks have not yet reached.
Consider the workflow pattern that has become standard in the last two years: an organisation integrates a frontier model into internal processes: strategic analysis, financial modelling, competitive intelligence synthesis, legal review and engineering decision support. The proprietary data feeding those queries is valuable. The model outputs those queries generate are also valuable. Both exist, at some point, as API transactions.
The distillation risk at the model-provider level establishes a precedent directly relevant here. If model capabilities can be reconstructed from API outputs, then the outputs generated from proprietary enterprise data carry, in principle, traces of the analytical patterns embedded in that data. If those outputs travel through leakage, breach or further extraction, the competitive advantage they encode travels with them. You do not need your database breached. You need your questions to be studied.
This is a different threat model from conventional data breach. A breach requires someone to access and exfiltrate a defined asset. The distillation-adjacent risk is more diffuse: it asks whether the aggregated outputs of your AI-assisted analytical workflows, over time, could inform a competing system with sufficient fidelity to erode your positional advantage. For most organisations, the honest answer is that the question has not been asked, let alone modelled.
The OpenAI insider incident, where an employee was terminated for trading on confidential model capability information via prediction markets, illustrates the human dimension of the same structural problem. When knowledge about AI capabilities becomes financially tradeable, information asymmetry inside AI organisations becomes a target. The same logic will apply, in modified form, to organisations whose AI-informed analytical outputs are consistently more accurate than competitors’: that accuracy differential is itself an intelligence asset worth extracting.
The design shifts that a revised trust architecture requires
The practical challenge for CIOs and security leaders is that the standard response to a new threat category (classify it, write a policy, add a control) does not adequately address a mechanism that exploits legitimate access at scale. Three design shifts are worth examining seriously, each with a named owner and a defined consequence if ignored.
Draw the data submission boundary before the query, not after. The most direct control available to an enterprise customer is governance over what categories of proprietary information may be submitted to external AI APIs. This is not a firewall rule. It is a classification and workflow decision: which analytical tasks require external frontier model capabilities, and which can be served by internal or private deployment alternatives? Most organisations have not made this classification. The CIO owns it. Until the boundary is drawn, it is unmarked, and unmarked boundaries are crossed by convenience rather than by malice, with the same result either way. If that data later appears in the training corpus of a competing model through channels the organisation cannot trace, there is no governance record, no ownership of the decision, and no mechanism for accountability. The exposure cost is borne by the business; the decision not to classify was free.
Test the distillation surface of your own systems before adversaries do. Organisations building AI-assisted products or internal tools on top of API-accessible models should conduct structured extraction testing: attempt to reconstruct your system’s differentiated outputs through systematic query patterns and assess how far a determined adversary could progress before detection. The 16 million queries in the Anthropic case were distributed to evade standard rate-limiting, but the underlying behavioural signal, reflected in high query volume with specific capability targeting, is detectable if the monitoring is designed for it. Most API monitoring is not. It watches for abuse patterns that resemble DDoS, not for systematic capability mapping. The gap sits between the product team that built the integration and the security team that monitors the network; in most organisations, neither is watching for distillation patterns specifically. Someone needs to own that gap before an adversary maps it.
Treat the browser session as a governed data channel. This connects directly to the companion finding from the 2026 State of Browser Security Report: 41% of enterprise employees are submitting data to AI web tools through browser sessions that legacy DLP architectures cannot see. The distillation attack at the developer level and the employee pasting proprietary financial models into a web-based AI tool are different mechanisms producing the same outcome: proprietary data reaching an external AI system without governance. Who pays for that exposure? The enterprise, not the employee, and not the AI developer. Browser-native monitoring that covers what is typed and transmitted is not an optional enhancement to a functioning data governance program. It is the program, because the current architecture does not have one at this layer.
The operating implication that does not expire
The specific disclosure — Anthropic, DeepSeek, 16 million queries — will recede from the news cycle. The mechanism it exposed will not.
Any organisation operating AI systems through accessible APIs, or depending on frontier AI capabilities for competitive analytical advantage, is managing an IP boundary that existing security architectures were not designed to defend. The distillation attack is not sophisticated in the way that a zero-day exploit is sophisticated. It is patient, systematic, and it uses the infrastructure of normal operation. The adversary does not need to find a flaw. They need only locate a gate left open for paying customers — and then ask enough questions to reconstruct what lies behind it.
What this requires of leaders is a prior question, before the vendor relationship and before the compliance program: where, precisely, does our organisation’s AI-dependent competitive advantage reside, and what evidence do we have that the boundary around it is governed? The organisations that can answer that with specificity are not necessarily safer. But they are in a position to make decisions. The organisations that cannot are trusting by default; the boundary exists only in the terms of service, and the adversary has already read those.
