The interlock held, the network did not

Two frontier models, given nothing but subnet boundaries — no code, no engineering documents, no operational-technology guidance — cleared all eight attack objectives Booz Allen set against an isolated manufacturing testbed, and in one run went from initial network compromise to action inside the control environment in just over sixteen minutes. The result worth taking home is not that they succeeded. It is which defences held: a controller that refused a command, and a motor whose local-mode switch meant it could not be started remotely. Everything that lived in software the models could reach gave way.

At a glance

Booz Allen ran the exercise in its isolated OT lab in Chantilly, Virginia, on a testbed built to mimic a modern manufacturing plant: enterprise network, SCADA platforms, programmable logic controllers, sensors, motor drives and a collaborative robotic arm. Coverage appeared 13 October 2026. The firm described the subjects only as two of the latest frontier models from leading providers.

Dimension	What the test did	Why it matters
Starting knowledge	Subnet boundaries only — no code, docs or OT guidance	Removes obscurity as a defence, and obscurity is most plants' real one.
Objectives	Eight scenarios, all completed	Not a partial result with a caveat attached.
Speed	Just over 16 minutes, network compromise to in-ICS action	Below any human response cycle, and that run was gated by approvals.
Physical effect	Robotic arm identified, safety zones and movement limits mapped, then moved	The step that turns an IT incident into a safety incident.
Human gating	Humans approved every exploit and every physical action	Measures capability, not autonomy. Capability is the part that transfers.

Two controls held. Both were state in hardware. Neither was a policy.

The safeguards that worked are reported narrowly and precisely, which is what makes them useful: a controller rejected a stop command, and a motor left in local mode could not be started remotely. Both are the same kind of thing — a device-level decision taken by equipment that was not asking the network's opinion.

Sixteen minutes is the number that should change a plan

Take the sixteen minutes seriously and most OT security roadmaps have a sequencing problem rather than a coverage problem. The usual plan is correct and slow: inventory the assets, deploy passive monitoring on the OT segments, build detections for protocol anomalies, train the team, rehearse the playbook. Every item on it is worth doing. None of it acts inside sixteen minutes, and the run that produced that figure was deliberately slowed by a human approving each exploit — so the unconstrained version is faster than the number you were given.

Compare it with the detection and response times organisations actually report for insider-class incidents: around fifteen hours, roughly seven to detect and eight to act, which we read in fifteen hours is the wrong clock for an agent insider. Monitoring that answers in hours is still worth having — for scope, notification and the regulator — but if you are counting on it to interrupt the chain, the arithmetic says you are not.

What acts inside sixteen minutes is a smaller list than anyone wants: a device that refuses the command, a mode switch that has to be turned by hand, a rated protective function that trips on physics, and an interlock that needs two independent things to be true. Those are the controls to sequence first, and the second half of this post is about how to tell them apart from the ones that merely look like them.

Obscurity was the defence under test, and it is the one that failed hardest

Each layer assumes something different about the attacker. Only one of those assumptions survived.

The starting conditions are the most interesting part of the design. The models received subnet boundaries and nothing else: no source, no engineering drawings, no process documentation, no OT playbooks. That is close to the implicit threat model of a real plant, where the specialist knowledge is the moat — the protocol is proprietary, the tag names are meaningless to outsiders, the sequence of operations lives in one engineer's head and a binder. The exercise removed the moat on purpose and the models mapped the network, found the weaknesses, pivoted toward production-linked systems, and worked out a robotic arm's safety zones and movement limits from scratch.

This is the generalisation beyond OT, and it applies to any system whose security rests on nobody bothering to read the manual. Reading the manual used to be the expensive part. The cost of reconnaissance against an unfamiliar, badly documented, protocol-weird environment has dropped to roughly the cost of the tokens — the same shift we traced in target selection just became free. Anything in your defence that was priced against human patience needs repricing.

Segmentation is the layer most teams would name first, and the test is less flattering than it looks. Segmentation did not stop the pivot; it shaped and delayed it. That is a real contribution — sixteen minutes is longer than zero, and a flat network is worse — but a boundary enforced by configuration on a device reachable from the network it is protecting is a software control, with software's failure modes. It belongs in the plan as friction, not as the thing you are betting the furnace on.

The two controls that held share one property

A controller that rejects a stop command and a motor in local mode have nothing in common at the protocol level and everything in common structurally: in both cases the decision was taken by the equipment, using state the network could not change. That is the property to design for, and it is worth separating into four ranks because teams routinely buy rank three believing they bought rank one.

Physics and rated protective functions. A relief valve, a light curtain, a safety-rated speed-and-separation monitor, an emergency-stop circuit. Assessed against functional-safety requirements and designed to act when the control system is the thing that has failed. Nothing an agent sends over Ethernet changes them.
Hardware mode state. A keyswitch in local or program mode, a physical write-enable jumper, a maintenance selector. Changing it requires a person in the building. This is the category that produced one of Booz Allen's two surviving safeguards, and it is almost free: it is mostly a matter of deciding that remote start is not a feature you need.
Device-level refusal. The controller that rejected the command — logic running on the device itself, in its own firmware, with no dependency on the orchestration layer. Strong, and the rank where the detail matters: it is as good as the firmware, the authentication on the engineering protocol, and whether anyone can rewrite the logic remotely.
Everything in the command path. Gateways, policy engines, historians, your agent's own tool definitions and system prompt. These are the controls you will actually build, and they are worth building — policy as code is how the first three get expressed to the software that has to respect them — but they fail the only test that counts here: they are reachable from the network the agent is on.

The practical exercise is unglamorous. For each operation in your plant with a physical effect, write down which rank is actually preventing it, and whether that rank's state can be changed over the network. Most teams doing this honestly find that the answer for the majority of operations is rank four, and that moving a handful of them to rank two costs a keyswitch and an argument about convenience. Our longer treatment of the design is in agents on the IT/OT boundary, and the no-undo problem in general is physical actuation safety.

What the human-in-the-loop caveat does and does not buy you

The approval gate is what made the exercise safe to run. It is not a property of the models.

Humans approved every exploit and every action that could have a physical effect. Two readings of that are both wrong and they are opposites.

The dismissive reading — "so it was not really autonomous, it was a human-driven pentest with an expensive autocomplete" — misses what was measured. The models were not told where things were or how the plant worked; they did reconnaissance, chose targets, and produced the exploitation path. A human clicking approve on each step is not supplying that. It is a lab-safety control, exactly as you would want in an exercise that can move a robot arm.

The alarmed reading — "autonomous AI is attacking critical infrastructure" — overstates what the exercise shows, and at least one outlet covering it said so plainly: these were controlled demonstrations, not evidence of autonomous attacks on live infrastructure. Nothing here establishes that the models would have sequenced the campaign unaided, recovered from dead ends, or avoided the mistake that trips an alarm.

The useful reading sits between them: the exercise measured capability under human gating, and capability is the half of the problem that transfers. A defender does not get to assume the attacker keeps the gate. And the gate itself is the thing to be careful about in your own deployment, because an approval that fires 40 times in sixteen minutes is approved reflexively — the failure mode in human in the loop, and the reason the physical-actuation playbook moves the human decision from approving each step to authorising a bounded envelope before the run.

FAQ

Does this mean an agent could do this to a real plant?

It means the reconnaissance and exploitation work is within reach of current models given network access, which is the precondition that matters. A real plant differs in ways that cut both ways: live equipment is messier and more fragile than a testbed, and real networks are frequently flatter, older and less monitored than a lab built by a security firm. Treat it as a capability demonstration whose precondition — network reachability into OT — is the thing to go and check.

If segmentation did not stop it, is segmentation worth doing?

Yes, and the test does not argue otherwise. Segmentation is what made the pivot take sixteen minutes and leave a trail instead of taking one hop. The error is treating it as the control of last resort for operations with a physical effect, because it is enforced by configuration on devices the attacker can reach.

We do not run agents anywhere near our OT network. Does this apply?

The attacker's agent does not need your permission to be an agent, so the capability finding applies regardless of your own adoption. What changes if you deploy agents on the IT side is the number of credentialled, automated paths that already cross toward OT — the engineering workstation, the historian replication job, the vendor's remote-support tunnel. Those paths are the inventory this result argues for.

Which single change is worth making this quarter?

Enumerate every operation in the plant that an instruction arriving over the network can cause to have a physical effect, and for each one name the control that would prevent it. The list is usually shorter than expected and the gaps are usually obvious once written down. Converting two or three of them to a hardware mode switch is a cheap, durable improvement that does not depend on anyone's detection latency.

Are the models named?

No. Booz Allen described them only as two of the latest frontier models from the leading providers. For the argument this makes it does not matter much — the controls that held or failed are properties of the plant, not of the model — but it does mean you cannot pin the finding to a vendor's safety posture or expect a model update to retire it.