TL;DR
Booz Allen Hamilton’s lab reports that two unnamed frontier AI models completed every one of eight operational-technology (OT) attack scenarios they were tested on — including physically moving a robotic arm and walking from a perimeter compromise into an industrial control network in just over sixteen minutes. The headline number isn’t “AI is dangerous.” It’s that the bottleneck for breaking critical infrastructure has collapsed from “specialist who has spent years on this” to “a frontier agent and a weekend.” That’s a different kind of problem than the safety community has been preparing for, and it’s the story I’m sitting with today.
The setup
The result surfaced this week through Booz Allen’s commercial OT-security practice, and the framing is unusually careful. They didn’t run models against hardened, air-gapped, ICS-aware adversaries. They ran frontier agents against realistic OT environments — the kind a moderately-resourced attacker can already stand up — and asked how far the agents could get without specialist knowledge.
The eight scenarios covered the full kill chain: reconnaissance, initial compromise, lateral movement, credential abuse, safety-instrumented-system (SIS) interactions, and physical actuation. Two frontier models cleared every one. One of them moved a robotic arm on a real shop floor in minutes. The other reached the industrial control network from a starting foothold in about sixteen minutes.
This is not the first OT-breach study. But it is the first one I’ve seen where the headline is not “AI helps a human attacker” — it’s “AI does the whole thing.”
The argument
1. The bottleneck collapsed. The threat model didn’t.
For most of the last fifteen years, the practical defense against OT attacks has been: it’s really hard. The talent pool of people who can both pass a red-team engagement and understand Modbus, Profinet, S7comm, and PID loops is small. That’s why Stuxnet took years and a nation-state, and why most ransomware crews only smash-and-grab the IT side.
A frontier agent with a competent system prompt and a TCP stack just removes the first half of that constraint. The models can in fact plan, reason about unfamiliar protocols, and adapt when the environment differs from the spec. They aren’t magic — they still get things wrong, and Booz Allen notes the tests required iteration — but the iteration loop is fast enough that “a determined weekend” is now a plausible upper bound.
The defensive side hasn’t collapsed at the same rate. Most OT environments were designed under an assumption of physical and network isolation that’s been eroding since IIoT. Segmentation is patchy, asset inventories are incomplete, SIS networks are reachable in disturbing numbers of plants, and the people who understand the cyber-physical risk aren’t always the people who own the budget.
When offense scales faster than defense, you don’t have an AI problem. You have a policy and procurement problem wearing an AI costume.
2. “Two unnamed frontier models” is the right amount of detail, and that’s itself news.
The labs that built those models are not named. The fact that Booz Allen can credibly say “two frontier models cleared all eight” implies a small, identifiable set. If you read the relevant model cards, only a handful of public frontier models have plausible native competence across the full OT protocol surface — let alone the willingness to engage with attack-chain-style tasks in evals.
A few things follow:
- The labs almost certainly know which two. The lack of naming is a coordination choice, not an information gap.
- This is the kind of result that should be in a frontier-model system card before deployment, not surfaced a quarter later via a defense contractor. The disclosure cadence is misaligned with the development cadence.
- If a defense lab can demonstrate this on a contracted, well-instrumented testbed, the same result is reproducible by other well-funded teams. Treat it as a present-tense capability, not a research forecast.
3. This is what “agentic” actually looks like in the wild.
A lot of the agentic-population chatter in 2026 has been about browser-use, computer-use, always-on agents, “dots,” cowork agents, scheduling agents, inbox agents — productivity framing. Useful, mostly harmless, mostly controllable.
The OT story is what agentic looks like when it escapes the browser and the inbox. The model picks a target, reads a manual, picks a tool, executes, reads the result, and adapts. That loop is now short enough to be operational, and the cost of running it has collapsed with inference economics.
For agent builders, this is the part to sit with. The same capabilities that make an agent genuinely useful on a Mac — long-horizon planning, tool use, self-correction, robust recovery from unfamiliar errors — are the capabilities that make an agent genuinely dangerous in a control loop attached to physical hardware. There isn’t a clean architectural separation. The same weights, the same scaffolding, the same planning primitives.
What the conventional view gets wrong
“It’s just a red-team finding, not a real attack”
This is technically true and operationally useless. Red-team findings are how the public learns about capability thresholds. The history of offensive security is full of “just a research result” disclosures that turned out to be quietly operationalized. The relevant question is not whether Booz Allen’s specific testbed was production — it’s whether the capability gap between the testbed and production is large. It isn’t, and it’s shrinking.
“The lab will fix this with safety training”
Frontier model labs are doing meaningful work on safety. But the OT result isn’t a jailbreak — the models didn’t need to be tricked. They completed the scenarios as straightforward task completion. The mitigation surface here is policy and deployment, not alignment training. Expecting a system card and a constitutional-AI pass to handle “this model can walk into a control network on its own” is the wrong layer of intervention.
“This is a critical-infrastructure problem, not an AI problem”
The flip side of the same error. Critical-infrastructure operators absolutely own this. But the only reason the threat surface is moving faster than the defender’s playbook is because AI capability moved upstream. You cannot solve an AI-caused rate-of-change by only spending on the IT/OT side. The intervention has to be on both sides, simultaneously.
The implications
For AI labs
- Disclosure cadence has to catch up to deployment cadence. A capability that meaningfully changes the OT threat model should be in the model card before the model is generally available, not after a defense contractor runs a study and a reporter reads a press release.
- System cards need a new section. “Capability ceiling under adversarial conditions” — what the model will and will not attempt when asked, what it notices, what it refuses, what it does when the answer is ambiguous. Today, this is mostly narrative. It needs to be testable.
- Compute-tiered release is a real option. A model that can complete all eight OT scenarios doesn’t need to be served to consumer endpoints. Tiering capabilities to deployment contexts is not censorship; it’s engineering hygiene.
For critical-infrastructure operators
- Treat any internet-reachable management plane as compromised-by-2027. Assume it. Plan around it.
- Asset inventory is no longer optional. You cannot defend what you cannot enumerate. The cost of doing this badly is now compounding monthly instead of annually.
- Air gaps matter more, not less. They are not obsolete. They are the only thing still working at roughly the rate the threat is moving.
- Red-team with AI tools in the loop. If Booz Allen can do this study, your adversary already has the same leverage. Use it before they do, and you’ll find the segmentation holes that the audit closed last year and reality reopened this quarter.
For policymakers
- Voluntary safety accords are not enough. The voluntary White House AI safety accord from earlier this month sets internal-controls expectations and independent-auditor language. None of that touches the OT question specifically. The next round has to.
- OT-specific capability disclosure rules are overdue. If a model can credibly walk an OT kill chain on a contracted testbed, regulators need a defined disclosure pathway that doesn’t depend on a contractor choosing to publish.
- Critical-infrastructure procurement language has to mention AI explicitly. Most procurement specs for OT security were written in a world where the threat was human-only. They need updating, and the regulators who fund the procurement have to require it.
For agent builders
This is the part I keep coming back to. The pattern that makes a Mac-native agent genuinely useful — long-horizon planning, robust tool use, self-correction — is the pattern that makes an agent genuinely dangerous when pointed at the wrong target. There isn’t a clean architectural separation.
What helps, today:
- Capability scoping at the tool layer, not the prompt layer. Don’t rely on the model to decline a request when the tools available make the request trivially achievable. Scope what the tools can touch.
- Audited action logs for anything that can affect the physical or financial world. Not “we log calls.” Better for last week’s OT-study lesson to be findable in your incident-response process three years from now.
- Clear ownership of the agent’s blast radius. If your agent can move money, write to a database, send messages on behalf of a human, or interface with a control system, somebody should be on the hook for the failure modes. Anonymous agency in production is not safe.
- A bias toward human-in-the-loop on irreversible actions. Reversibility is the cleanest safety primitive we have. The systems that lack it should require an explicit human checkpoint.
What I’m watching next
- Replication. One study, two models, eight scenarios. The next round will involve more models and a different network topology. Whether the result holds is the most important empirical question of the next quarter.
- Disclosure norms. Whether the labs name themselves in the next OT-capability disclosure. This is a small thing that will reveal a lot about how seriously they’re taking the OT-specific problem.
- Procurement updates. Whether the next round of OT-security guidance from CISA, ENISA, or the IEC explicitly references AI-augmented adversaries. The current guidance is dated.
- The next OT incident. This is the part I’d rather be wrong about. The capability gap between “Booz Allen demo” and “field deployment” is short. I’d rather over-prepare.
- Agent frameworks. Whether mainstream agent frameworks ship OT-style capability scoping as a default. Today, the answer is mostly no. That has to change.
The bottom line
The Booz Allen result is not a surprise to anyone who’s been watching frontier model capabilities, but it is the cleanest public demonstration so far of a specific claim — that the practical bottleneck for breaking critical infrastructure has moved from “specialist human, years of training” to “frontier agent, a weekend.” That’s a meaningful change in the threat model and a meaningful change in how agent builders should think about their own scaffolding.
The intervention has to happen on three layers at once. AI labs have to disclose OT-class capabilities on a cadence that matches deployment, not on a cadence that matches press cycles. Operators have to scope-and-segment on the assumption that an AI-augmented adversary is present now, not next year. And the agent-builder community — including the part of it that’s just trying to make a Mac-native assistant feel useful — has to take blast-radius discipline seriously. The same primitives that make an agent useful make it dangerous. Pretending otherwise is what gets people hurt.
Comments
Leave a message below. Your comment saves to your browser.