Industrial-Scale AI Model Distillation: The New Security Risk for AI Providers and Manufacturers

Inzonex ResearchPublished Sources checked 12 September 20268 minute read

Distillation is a normal technique: train a small model on a large model's answers. A September 2026 joint advisory describes doing it to models you do not own, at scale, through ordinary queries. The original weights need not be exfiltrated; a surrogate is trained from collected outputs, so the defence is volume and pattern rather than file security. If your company runs its own inspection or engineering model, the same method applies to it.

What the advisory describes

On 8 September 2026 the NSA, CISA and the FBI issued joint advisory AA26-251A. It states that several named AI companies based in China have been systematically extracting the capabilities of US frontier models. This page does not repeat the attribution or the company names; they are in the advisory, and the engineering content stands without them.

The advisory's description of the mechanism is the usable part. According to the advisory the activity routes requests through multiple pathways to obtain access, including native interfaces, cloud providers and third-party aggregators, and uses a grey market of proxies to get around restrictions. It describes prompts designed to make a model reveal its step-by-step reasoning rather than only its conclusions, so that the reasoning itself becomes training material. The stated scale is billions of tokens across millions of exchanges since late 2024.

What kind of statement this is

This is a government advisory, not a peer-reviewed study. Its attribution and intent findings come from that investigation and are not independently confirmed here. The part that is directly usable by any organisation, regardless of what it thinks of the attribution, is the description of technique, the behavioural indicators and the mitigations. Those stand on their own.

Distillation against extraction

Coverage of this advisory uses the word "distillation" for two different things, which is why the story keeps getting muddled. Distillation is a legitimate and widespread method: a smaller student model is trained on the outputs of a larger teacher, and the result is cheaper to run. It is widely used to produce models that cost less to serve. The question is never the technique. It is whose model, under what authorisation, at what volume.

The same technique on either side of a boundary
DimensionLegitimate distillationExtraction campaign
AuthorisationYour own model, or licensed output rightsAccess obtained under terms that forbid it, or through resold and proxied accounts
Volume patternBounded by a stated purposeBillions of tokens across millions of requests; sustained and automated
Query designOrdinary task promptsPrompts engineered to expose reasoning steps, not just answers
Account behaviourHuman rhythm, identifiable organisationMany addresses on one account, no idle periods, immediate maximum usage
ResultA smaller model you are entitled to deployAn imitation of someone else's capability, with the cost of building it avoided
How model capability is copied through an interfaceFour stages left to right: a target model answering queries, an automated query pipeline, captured outputs used as training data, and an imitation model whose behaviour resembles the original although its weights were never taken. Beneath each stage is the control that interrupts it: access control and identity, rate and volume limits, telemetry logging, and limits on output detail.The weights stay put; the collected outputs are the training dataEvery step on this path is a legitimate action performed at an illegitimate scale, which is why volume and pattern are the signal.Target modelAnswers queries throughan interfaceQuery pipelineAutomated, sustained,engineered promptsCaptured outputsAnswers and reasoningsteps as training dataImitation modelBehaviour reproduced,weights never takenAccess control, identityRate and volume limitsTelemetry loggingOutput detail limitsControls follow the mitigations listed in the joint advisory. Diagram: Inzonex.
Capability copied through an interface, with the control that interrupts each stage. Inzonex diagram; the controls follow the mitigations listed in the advisory.

Why NIST treats extraction as a stepping stone

Model extraction is a documented attack class. NIST's adversarial machine learning taxonomy, published in March 2025, lists model extraction as a defined privacy attack requiring only query access, with its own identifier in the taxonomy. It describes the setting plainly: providers train large models on proprietary data and wish to keep the architecture and parameters confidential, and the attacker's goal is to extract information about that model.

The more useful observation is about consequences. NIST notes that model extraction "is often not an end goal but a step toward other attacks", because once architecture and weights are known an attacker can mount the stronger attacks available in white-box settings. Preventing extraction therefore removes the foundation for a set of later problems, which is a better argument for spending money on it than intellectual property alone.

Which industrial models are exposed

A manufacturer reading a frontier-model advisory will reasonably ask what it has to do with a factory. The connection is that industrial companies have become model owners. A vision system trained on years of your own defect images is a proprietary asset whose decision boundary encodes accumulated inspection experience. So is an engineering assistant trained on your specifications, or a maintenance model trained on your failure history.

Not every model needs protecting; these are the ones that do
Model typeWhat it containsWhat copying it would meanProportionate control
Generic assistantBought capability, low uniquenessLittle to copy that is yoursNormal account hygiene
Internal engineering modelTrained on your specifications and drawingsCopying it transfers your design practiceRestrict to named users; log every query
Quality-control vision modelTrained on your defect imagesIts decision boundary is the accumulated inspection knowledgeNever expose raw scores publicly; rate limit
Control-adjacent agentCan read or influence process systemsExtraction is the smaller worry; access is the larger oneTreat as an OT interface, not an app
Which industrial models justify protection against extractionA two-by-two arrangement. The horizontal axis is how much of the model is genuinely yours, from bought capability to models trained on your own data. The vertical axis is the consequence if a competitor could reproduce its behaviour. Quality control models trained on proprietary defect images sit in the corner that justifies the most protection.Protect what is actually yours, not everything with an APIHorizontal: how much of the capability you created. Vertical: what it costs you if someone reproduces it.Higher consequenceLower consequenceBought capabilityTrained on your dataGeneric assistantLow uniqueness, low consequenceQuality-control modelHigh uniqueness, high consequenceEngineering copilotHigh uniqueness, moderate consequencePublic demo modelLow uniqueness, high exposure
Protection should follow uniqueness and consequence, not the presence of an interface. Inzonex analysis.

One boundary deserves separating clearly. Extraction copies what a model does. Reconstruction and membership inference, which are separate classes in the same NIST taxonomy, aim at what the model was trained on. Losing the first costs a competitive advantage. Losing the second can expose the underlying records, which for an industrial company may include customer drawings or process data held under contract.

Detection indicators

Because every individual request is legitimate, detection has to work on shape rather than content. The advisory's indicators are directly reusable by any organisation exposing a model: one account used from many addresses and user agents; sustained round-the-clock usage without the idle periods human work produces; an odd ratio between subscription activity and programmatic use; and new subscriptions that begin immediately at maximum usage.

The mitigations it recommends have the same ordinary character: limit query volume and rate, control who can reach the model, log telemetry, constrain how much detail outputs expose, degrade responses to activity assessed as extraction, limit what model artefacts are released publicly, and share indicators with peers. None of this requires new technology. It requires deciding that a model is an asset with an access policy rather than a feature with a URL.

A question for your own logs

If a competitor made ten thousand well-chosen queries against your inspection or engineering model over a month, would anyone notice, and would you still hold anything they did not? If the answer to both is no, the model is public in practice and should be treated that way in commercial planning.

What this means for manufacturers

  1. Inventory the models you actually own

    Separate bought capability from models trained on your own data. Only the second group is worth protecting, and most companies have never listed them.

  2. Give each owned model an access policy

    Named users or services, scoped keys, and a stated purpose. Standing broad access to a proprietary model is the equivalent of leaving drawings on a public server.

  3. Log queries, not just outcomes

    Volume, source, timing and pattern are the only evidence that extraction is happening. If the logs hold only results, the question cannot be answered afterwards.

  4. Rate limit by default

    Set limits from legitimate use plus a margin. This is the single control that makes bulk copying expensive without affecting anyone doing real work.

  5. Do not publish more than the answer

    Confidence scores, ranked alternatives and reasoning traces are far richer training material than a plain result. Expose them internally if useful, externally only with a reason.

  6. Write it into supplier contracts

    Where a vendor hosts a model trained on your data, establish who may query it, what is logged, and what you are told if abnormal usage appears.

Limits and open questions

  • Attribution is the agencies'. The identification of specific companies and the assessment of government awareness come from the issuing agencies and are not independently verified here.
  • Effectiveness is unquantified. Nothing published states how closely an extracted model matches its target, so the commercial damage cannot be measured from these documents.
  • Detection indicators produce false positives. Legitimate automated evaluation also runs continuously without idle periods. Indicators are a reason to look, not a verdict.
  • Defences trade against usability. Rate limits and reduced output detail also constrain legitimate users, and no published guidance sets the right level for an industrial model.
  • No cost data exists. There is no public basis for what these campaigns cost their targets or what protection costs, so any figure in circulation is an estimate rather than a measurement.

Models trained on proprietary industrial data are assets that can be copied through their own interfaces, without any breach in the traditional sense. Deciding which of yours are worth that treatment is a half-day exercise, and most companies have not done it.

Questions

Is distillation itself illegitimate?

No. Training a smaller model on a larger model's outputs is a standard and useful technique, and it is how many efficient models are produced. What the advisory describes is doing it to someone else's model without authorisation, at scale, and in breach of the terms under which access was granted.

Is this the same as stealing the model file?

No. The original model weights need not be exfiltrated; a surrogate is trained from collected outputs, so file-level protection does not apply. The behaviour of the model is reproduced by querying it many times and training on the answers. The weights stay where they are while the capability is copied.

Does this matter to a manufacturer that is not an AI company?

It matters to any company that exposes its own model through an interface: a visual inspection model trained on your defect images, an engineering assistant trained on your specifications, a maintenance model trained on your failure history. Those models are proprietary assets, and the same method applies to them at a smaller scale.

How would anyone notice it happening?

By usage shape rather than content. The advisory points at indicators such as sustained round-the-clock use without the idle periods human work creates, one account used from many addresses, and new subscriptions that begin immediately at maximum usage. Those are patterns any provider can look for in its own logs.

Is stealing the model the same as stealing the training data?

No. Extraction copies what the model does. Reconstruction and membership inference aim at what the model was trained on. They are separate attack classes in the NIST taxonomy with different consequences: one costs you a competitive advantage, the other can expose the underlying records.

Sources

Suggested citation: Inzonex Research (2026), Industrial-Scale AI Model Distillation: The New Security Risk for AI Providers and Manufacturers, published 12 September 2026. Technique, scale, indicators and mitigations are attributed to joint advisory AA26-251A. The attack classification is from the NIST adversarial machine learning taxonomy. The comparison tables, both diagrams and the industrial exposure assessment are Inzonex analysis.

Related industrial AI analysis