On 12 February 2026, Google's threat intelligence team disclosed that someone had questioned Gemini more than a hundred thousand times with a specific purpose: to reconstruct its reasoning logic and train a competing model on what came back.
The number is not the interesting part. What is missing from the story is. There was no intrusion. No stolen credentials, no malware, no compromised server. Nobody crossed a perimeter. Intellectual property began walking out through the front door in the form of questions, answered politely by the system itself.
Google attributed the campaign mainly to commercially motivated actors — AI companies and research institutions chasing competitive advantage — and called it intellectual property theft. That framing is the part that belongs in the boardroom of any organisation running an AI capability in production.
At a glance
- Distillation extracts a model's knowledge by querying it systematically, without compromising any system.
- You do not need to be Google: any organisation exposing an AI capability through an API or inside a product has the same surface.
- What leaks is not the model weights but the judgement that makes it valuable — and often traces of the data it was fine-tuned on.
- Perimeter controls cannot see it, because technically nothing anomalous happens: these are legitimate requests from an authenticated customer.
What distillation is, for the people who decide
A language model is, at bottom, encoded judgement. Money, data and time went into making it answer the way it does. That judgement is the asset.
Distillation exploits the fact that the model answers. Whoever wants to copy it asks a great many questions, methodically covering the ground that interests them, collects what comes back and uses that material to train their own model — smaller, far cheaper, and behaving in a similar way. The original is not copied; it is learned from until it can be approximated.
The analogy that works in a boardroom is the employee who leaves for a competitor. They do not take the servers, they take the judgement. The difference is that this process can be automated, scales to a hundred thousand queries and leaves no trace of a break-in.
It is worth being clear about what this is not. It is not a software defect you close with a patch, nor a vulnerability with a CVE attached. It is a consequence of the system behaving normally, which is precisely why there is no complete fix: a model that stops answering stops being useful.
Why this is not only a big tech problem
The instinctive reaction is to file the Gemini case under «problems of giants». That is a misreading, and three scenarios from ordinary companies undo it.
You have exposed an AI capability in your product
A classifier deciding whether a transaction is fraudulent, an assistant answering your customers with your company's judgement, an engine scoring applications. If a competitor can query it — simply by signing up as a customer — they can approximate its behaviour without having paid to build it.
You have fine-tuned a model on your own data
Here the risk changes in kind and gets worse. When a model is tuned on internal documentation, case histories or records, some of that material is reflected in how it answers. Academic work has been documenting for some time that targeted queries can surface fragments of the tuning data. This is no longer about intellectual property: it is personal or confidential data leaving through a channel nobody classified as a data egress point.
Your supplier is the target, not you
If your operation depends on a third party's model, their exposure is your exposure. A supplier whose model is distilled loses competitive advantage, and with it the viability of the service they sell you. That is classic third-party risk with a new asset class, and it belongs inside the third-party risk management you should already be running.
Why your existing controls miss it
The reason this goes unnoticed is that it does not look like an attack. There is no failed login, no privilege escalation, no traffic to a suspicious destination, no file for an endpoint agent to flag. There is an authenticated customer, contract in order, doing exactly what they were granted access to do.
The firewall has no objection. Nor does the EDR. And data loss prevention watches the files that leave, not the judgement inferred from thousands of correct answers.
It is the same blind spot we described in LLMjacking, where abuse also wears the costume of legitimate use, and the one that makes shadow AI so hard to bound.
What to watch: the signals that do separate
Each individual request may be legitimate while the set is not. The patterns that separate a customer from an extractor live in the aggregate, not in any single query:
- Volume out of proportion to the contracted use case. A customer querying a thousand times more than their business justifies is doing something else.
- Systematic coverage instead of real usage. Legitimate use clusters around a few patterns; extraction sweeps the input space methodically, including cases nobody cares about in production.
- Queries built to reveal the process, not the result. Requests that push for step-by-step reasoning, justification or confidence levels rather than the answer the product exists to give.
- Machine-like regularity. Constant cadence, without the peaks and troughs of a working day, sustained across days.
- Concentration from one account or address range. Particularly where the account is recent or on an entry-level plan.
None of these is conclusive on its own. Combined, and set against a baseline of what is normal for each customer, they allow someone to raise a hand in time. This is continuous detection work, not a static rule.
Defence: what actually helps
No single measure prevents this outright, and anyone selling one as a cure is overstating. What does exist is a set of decisions that make the operation considerably more expensive and detectable sooner.
- Return only what is needed. The more information accompanies an answer — internal scores, alternatives, explicit reasoning — the cheaper the judgement is to copy. If the product does not need it, it should not be exposed.
- Quotas and volume-based pricing tiers. The point is not revenue; it is that assembling the necessary material should cost money and time.
- Per-customer baselines, not global ones. The aggregate hides the extractor; behaviour measured against a customer's own history exposes them.
- Explicit contractual terms. Prohibiting the use of outputs to train models does not prevent the act, but it converts an unsolvable technical problem into an enforceable breach.
- Access control over model artefacts. Weights, checkpoints and tuning sets are concentrated intellectual property. They deserve crown-jewel treatment, with minimal access and full traceability.
- Care over what goes into fine-tuning. If the tuning set holds personal or confidential data, that risk travels with the model. It is a design decision, not a configuration setting.
These are the decisions we examine in an AI agents and MCP security audit and the ones that hold up an AI security programme that amounts to more than a written policy.
Where this fits in the frameworks you already use
There is no need to invent a category. The OWASP GenAI project lists model theft among the risks for applications built on language models, and its more recent revision folded it in alongside unbounded consumption, precisely because extraction and resource exhaustion share signals. Its incident round-up for the first quarter of 2026 gives a sense of how often this shows up in the wild.
On the regulatory side, the EU Artificial Intelligence Act requires AI systems to be governed with transparency, risk management and human oversight. A model from which judgement or tuning data can be extracted is, in governance terms, a system whose risk is not managed. And if it was tuned on personal data, the problem moves into data protection territory.
ISO/IEC 42001 provides the management framework for ordering this, which we develop in how to choose an AI compliance platform and in our ISO/IEC 42001 implementation and EU AI Act compliance services.
The conversation the board needs to have
The most expensive framing error is treating this as a technical matter. Presented as an API problem, distillation gets solved with a rate limit and forgotten.
Framed properly, it is a question of intellectual property: what the judgement encoded in that model is worth, what would happen if a competitor held it at a fraction of the cost, and what we are prepared to do to make copying it expensive. That conversation is not led by the head of security; it is led by whoever owns the asset.
And there is a prior question almost nobody has asked: do we know which AI capabilities we have already exposed, who consumes them and at what volume? In most organisations that start looking, the incomplete answer is the first finding.
What the case leaves behind
What matters about the Gemini episode is not that it happened to Google, but that the mechanism is old and familiar: ask a great deal and learn from the answers. What is new is that there are now assets whose entire value consists of knowing how to answer.
As long as security keeps measuring what comes in, it will keep failing to see the most expensive thing you built walking out. In a company that has invested in artificial intelligence, that is no longer a metaphor — it is a line on the balance sheet.