Sixteen minutes. That is how long a red-team exercise published this week needed to take an AI model from a network login nobody authorised to physically moving industrial equipment – a machine obeying instructions nobody issued. I have chaired QRQC stand-ups that took longer to find a free room and a flipchart. Control plans in every plant I have audited are thick enough to stop a forklift, and not one line in any of them covers an adversary editing a setpoint.

A breach is an unapproved change, not an IT ticket

Alongside two decades in automotive and aerospace quality, I collected a Certified Ethical Hacker credential and a listing on a telecom operator's public bug-bounty Hall of Fame for a clickjacking disclosure. What stayed with me was not the vulnerability. It was the vendor's first reflex: my report came back filed as a service-desk ticket. Something to close. Not a defect. A system that changes behaviour when given a specific input is defective by any definition we use; the intent behind the input does not move it one inch outside the quality domain.

Strip away the hoodies-and-keyboards framing and an OT breach is this: process parameters changed without a change request, without an engineer's signature, without PFMEA review. The process now runs outside its validated state. IATF 16949, AS9100, ISO 9001 – every system I have worked under already owns the machinery for that event. We call it change control. The assumption nobody wrote down is that change arrives from our own engineers, through our own gates.

An intruder does not break your process. He runs a version of it you never validated.

The audit is annual. The attack took sixteen minutes.

VDA 6.3 buys an auditor a day or two on site; customer audits sample the process once a year. Intrusion happens in minutes. That asymmetry – not the malware, not the AI – is the vulnerability, and a vendor study out this week on legacy OT explains the mechanics: decades-old controllers beside a dozen monitoring tools that never aggregate into one view, so a parameter change on a live line can pass unseen. French supermarket chains spent this week restocking after a cyber event became a physical one – fresh stock written off, shelves empty. When the organisations building these models launch a critical-infrastructure defence programme alongside security firms, as one major lab just did, that is not marketing. That is a signal.

When a quality engineer cannot answer what changed on this line, and when, we write a traceability nonconformity and it becomes a finding. When a security incident happens, we quietly accept that nobody knows. Same question, different badge.

Why agents outrun your escalation chain

I build and deploy multi-agent AI systems; my orchestration platform runs 63 models in parallel with consensus synthesis. So I am not speculating about why an agent crossed an OT network in sixteen minutes. Agents do not read documentation between steps. They do not wait for shift handover. Enumeration, credential testing and payload selection run concurrently, which is why lateral movement that takes a patient human days takes an agent minutes. If detection depends on a person noticing an anomaly and escalating it, the race is already decided – the agent finished before the escalation email was opened.

Vendors are queuing to sell AI agents onto factory floors – governed agents, they promise. Governance is a control plan by another name. Ask to see it.

Put the adversary in the PFMEA

The fix is not a new discipline. It is an extension of the one plants already trust. Enter cyber-physical manipulation in the PFMEA as a failure mode like any other: severity from physical consequence – a furnace overshoot, a wrong torque value, a dosing pump that runs dry; occurrence from exposure – remote-access paths, flat networks, unpatched HMIs; detection from whether a parameter change raises an alarm or dies in a log nobody reads. Quarantine a suspect line exactly as you quarantine suspect stock: contain, verify against last-known-good parameters, release with evidence. Then run the event as an 8D. Root cause analysis does not care whether the trigger was a worn bearing or a rogue script.

I built the QA/QC function for a greenfield plant of more than 900 people, from empty hall to serial production, and the cheapest risk decisions I ever made were taken at a whiteboard before the first machine was ordered: segmentation between office and production networks, setpoint access governed like calibration, parameter traceability designed in rather than bolted on after the first incident. Retrofitting that into a running plant costs multiples – in money and in stopped lines. Segmentation and parameter traceability are quality decisions, cheapest on day one.

Key takeaways

  • Add adversarial setpoint manipulation to the next PFMEA revision: severity from physical consequence, occurrence from remote-access exposure, detection from whether parameter changes raise an alarm.
  • Log every setpoint and recipe change with part-level traceability – who, what, old value, new value, approval reference. A parameter change with no approved change request behind it is a nonconformity, not an IT event.
  • Design segmentation and parameter governance in at greenfield; retrofitting them into a running plant costs multiples and stops production while you do it.
  • Write the containment playbook now: quarantine the line like suspect stock, restore last-known-good parameters, and convene a cyber-8D with OT engineering and security at one table – in minutes, not days.

A hacker and a quality engineer ask the same question of any system: how does it fail, and who notices first. My profession has answered it for fatigue, contamination and torque for a century. Sixteen minutes, a machine that moved itself – the answer must now cover an adversary who edits the process instead of breaking it. The plants that thrive through the next decade will be the ones whose quality function answers that question before the attacker does.