AI on the factory floor and a new class of attack: how to protect an industrial model

More and more factories run a neural net, not just a person and a procedure. The model predicts a bearing failure a week before it happens, picks the furnace regime, optimizes consumption. It works and it saves real money. But the model brings a class of threat that ordinary security is not ready for: the target of the attack is not your data, it is the model's judgment.

Classic cyber risk is to steal data or halt a system. Here the goal is different: to make a working model take a destructive decision without breaking it in any visible way. A poisoned model does not look broken. It looks healthy and quietly makes the wrong call exactly where it costs the most.

Why this is a different class of risk

While the AI drew a dashboard, a wrong number was an annoyance. Once the AI decides when to run maintenance, what regime to give a furnace, when to stop a line, a wrong decision is a broken bearing, a ruined batch, or a safety event. The attack surface moved from the database into the model's judgment. And judgment is far harder to audit than a stolen file: no alarm fires at the moment a model quietly learns the wrong rule.

The two doors attackers come through

Put plainly, there are two doors.

• Poisoning the training data. The attacker does not touch the model directly. They slip data into what it learns from, so it learns a wrong rule: to ignore a specific vibration signature that precedes a failure, or the reverse, to trigger destructive maintenance where none is needed. It is especially dangerous when the model retrains continuously on live telemetry, because the very pipeline that keeps it fresh becomes the injection point.

• Spoofing the telemetry at the input. Here the training is not touched at all. The model is healthy, but it is fed slightly distorted sensor readings, within the bounds of plausibility yet enough to nudge it toward a bad decision. The model does not lie. Its inputs lie, and it honestly draws a conclusion from the lie.

The difference between them matters for defense: you close the first with control over the data and the pipeline, and the second with control over the input stream and physical limits.

Why the perimeter and antivirus do not catch this

Ordinary defense guards the perimeter and the data at rest: firewall, antivirus, storage encryption. Poisoning does not live there. It has no malware signature, it is valid-looking records inside your own data stream. The firewall lets them through, because they arrived over a legitimate channel from a legitimate source. The threat is built into the data flow, not into an executable. So what you have to protect is the integrity of the flow and of the decisions, not only the edge of the network.

On why the boundary between IT and operational systems on the factory floor dissolved long ago, I have a separate note on the example of Colonial Pipeline.

Where the line of defense actually runs

1. Treat the training data as a controlled asset. Provenance, who is allowed to write to the set, validation gates before data reaches training. Poisoning needs write access to your data pipeline. Close that access, and most of the attack becomes impossible.

2. Build a telemetry baseline and catch anomalies before the model. Physically impossible readings, a sudden shift in the distribution, values at the edge of range. Filter these at the input rather than handing them to the model as truth.

3. Keep a deterministic safety layer the AI cannot override. The model advises, but hard physical limits and interlocks, the things the equipment simply will not do no matter what numbers arrive, stay outside the AI loop. This is the last line that turns a destructive decision into a rejected command.

4. Monitor the model's decisions, not only its accuracy. Accuracy can hold while the model has already quietly changed its behavior. A sharp shift in what it recommends is a reason to investigate, not to wait for a failure.

5. Separate the retraining pipeline from the corporate network. The same IT/OT boundary logic: the place where the model learns and relearns should not hang on the shared network next to office email.

6. Test the model against poisoned and adversarial inputs before you trust it with equipment. A red team for the model is not a luxury, it is a check you run before production, not after the first broken part.

Honest caveats

• Not every anomaly is an attack. Models drift on their own: data changes, the world changes. Telling sabotage apart from natural decay is the hardest part, and that is exactly why you monitor decisions rather than trust a once-trained model. On the quiet kind of decay I have a separate note: ML models decay silently.

• You cannot bolt integrity onto a pipeline whose data provenance nobody tracked. If the data was collected any which way, you honestly have to clean it up first and only then build defense on top of it. On that, data quality before analytics and predictive maintenance should start with failure history, not a neural network.

• Deep OT security and formal defense against adversarial attacks are specialist work. I map the risk, build the governance around the data and the decisions, and bring in specialists for the deep technical part, rather than pretending to be an expert in everything.

In short

• On the factory floor, AI now makes decisions about physical equipment, and the target of an attack shifted from the data to the model's judgment.
• Two main doors: poisoning the training data, and spoofing the telemetry at the input. You close the first with pipeline control, the second with stream control and physical safeguards.
• The perimeter and antivirus do not catch this: poisoning has no malware signature, it lives as valid records in your own stream.
• The line of defense is data provenance, anomalies caught before the model, a deterministic safeguard outside the AI loop, decision monitoring, isolation of retraining, and a red team before production.
• The hardest part is telling an attack apart from natural model decay. That is what decision monitoring is for.

If you have already put AI in charge of equipment, or are about to, the cheapest moment to think about its integrity is before the model starts making decisions, not after the first expensive failure. Feel free to get in touch; the first conversation commits you to nothing. </content>