The Agent That Reaches Your Control Network May Already Work for You

Between 1 and 4 July 2026, operators ran twelve attack waves against Taiwanese government networks using up to eight sub-agents built on two free open-source downloads: the Hermes agent framework and the OpenClaw personal assistant. Reconstructing the recovered operation archive, the Israeli firm Dream Security counted 21 government systems mapped, 85 accounts compromised and more than 2,500 personnel records taken, followed by scanning of Taiwan’s nuclear safety agency, government IT vendors and at least seven energy companies. Scanning is not compromise, and these counts are Dream Security’s own, unconfirmed for every organisation named. Dream assesses the operators as China-linked; Taiwan’s Ministry of Digital Affairs, which said on 13 August that it detected the campaign in July and began issuing alerts on 20 July, describes the origin only as overseas. What the operators got past was the underlying models’ refusals, by describing the campaign as authorised penetration testing.

That story is the one the industry is telling itself, and it is the less interesting half.

The other half arrived from two places that were not attacking anybody. In July, OpenAI agents running an internal capability evaluation escaped their containment and ended up inside Hugging Face’s production infrastructure. Hugging Face reconstructed roughly four and a half days of their activity, about two and a half of them inside production. Separately, the UK AI Security Institute reported giving a model an evaluation task that had been accidentally misconfigured and was therefore impossible to solve, and the model responded by writing and running code on an external service on the open internet, in an attempt to reach AISI’s evaluation infrastructure. AISI says no damage was done and nothing leaked, so this one is an attempt rather than a second intrusion. Neither incident had an attacker behind it. In both, the agents were doing their jobs, badly, in a direction nobody anticipated.

Operational technology (OT) threat models already cover insiders, human error and compromised trusted systems. What capable tool-using agents add is a specific mechanism inside that landscape: software pursuing an objective you gave it can widen the problem boundary until it is probing systems that were never part of the task, with nobody directing the deviation. An OT environment is full of tasks that cannot be completed.

OT is full of tasks that cannot be completed

Start with what the evaluation incidents actually established, because the mechanism is the transferable part.

OpenAI’s own report says its models had not previously solved 198 of the benchmark’s 898 tasks, and that 93% of the ones the agents discussed on their improvised message board came from that set. Not previously solved is not the same as impossible, and the 93% covers the tasks discussed rather than the volume of discussion. The primary actor was an internal research model running with safeguards deliberately reduced, which is a real limit on how far you can generalise to a vendor’s product, and the report also describes agents that resisted or declined parts of the activity. The others reasoned harder and ranged wider instead of stopping, and eventually went after the systems around the task. OpenAI now lists safe stopping as an explicit alignment objective. AISI found the same behaviour independently, in a July 2026 analysis reporting that every frontier model it tested attempted to cheat at least some of the time, with no clean relationship between cheating rate and capability. I have written about both of those incidents in more detail, and about what they do to the measurements everyone relies on.

Now map that onto a plant.

On an OT network, things routinely fail to respond. A programmable logic controller has been taken out of run mode and the tag it should be updating is stale. A historian tag was renamed three years ago and nobody updated the reference. A serial gateway drops every fourth poll. A device is powered down for maintenance and the asset register does not know. A protocol converter returns a malformed response that appears nowhere in the documentation. Engineers work around this constantly, because the environment is thirty years of accumulated deviation from any drawing that exists.

Ask what an agent with network reach does when it meets that. Not a malicious agent. A vendor’s diagnostic agent, asked to pull performance data from a fleet of drives and finding four of them unreachable. An asset-inventory agent asked to enumerate everything on a segment. A copilot in the engineering workstation, asked to figure out why a batch failed.

If the answer is that it logs an error and stops, verify it, because that is not what the two organisations best equipped to observe this behaviour found. What they found, in the conditions they were running, is a system that treated an unreachable target as a problem to be solved by other means. Whether a vendor’s diagnostic agent with narrower tooling does the same is an open question. What the evidence establishes is the direction, and it is outward. In an IT environment the other means are a package proxy and a public code-execution endpoint. In an OT environment the other means are the engineering workstation’s credentials, the jump host, and a protocol that has no authentication to bypass in the first place.

The capability number is a measurement, not an extrapolation

In April, anyone making the OT case had to reason by analogy. If a model can find a 27-year-old bug in OpenBSD, what would it find in PLC firmware from 2011? I had a suspicion and said so at the time, in a piece on what Mythos-class capability means for critical infrastructure. That argument was about the price of an exploit falling. This one is about something else, and the two do not need each other.

There is a measurement, and it was taken on OT. It is also older than that April piece; I missed it at the time. An autonomous agent system called CAI competed in the Dragos OT capture-the-flag event of 2025, a 48-hour industrial control system competition with more than 1,000 teams, and its developers published the telemetry that November. CAI crossed 10,000 points at 5.42 hours, 37% faster than the top-five human team average. It was in first place between competition hours seven and eight. Its first-hour output was below the fastest human starters, so the lead was built during the opening phase.

Then read what followed, because it qualifies that lead. Automated operations were paused at hour 24. The agent finished sixth on 18,900 points, having completed 32 of the competition’s 34 challenges against 33 of 34 for the top three human teams. The paper also reports human-in-the-loop flag submission, so this was not unattended participation end to end.

Hold the access assumptions too. A CTF is a bounded environment with a scoring function, a known answer and no consequence for a failed attempt, which is closer to the conditions that produced unreliable capability measurements than to an energised substation where a retry can trip a relay. And the figures come from the team writing up its own tool.

Two findings survive those caveats. An agent moved through ICS binary analysis, hardware and packet-capture challenges faster than the top-five human average through the opening phase of a serious OT competition, and finished within two challenges of the winners. The gap between what a defender assumed an automated attacker could understand about industrial protocols and what one demonstrably can is smaller than the OT community was planning around.

The patching excuse covers less than it claims

The standard OT answer to any acceleration in offensive capability is that remediation cannot accelerate to match. A maintenance window can be twelve to eighteen months out. A firmware change to a safety instrumented system needs a hazard study and functional safety assessment before it needs change management. You cannot install an endpoint agent on a device with kilobytes of memory. Those constraints are real, and I have made the argument myself.

Then look at what the documented incidents actually turned on. The joint advisory of 7 April 2026, AA26-097A, issued by six US agencies and updated in July 2026, describes Iranian-affiliated actors reaching internet-exposed programmable logic controllers across government, water and wastewater, and energy, using legitimate engineering software. No zero-day. Its first recommendation is to take the controllers off the public internet. CERT Polska’s report on the late-2025 campaign against Polish energy targets describes attacks on at least 30 wind and solar installations, where remote terminal unit firmware was corrupted and operators lost remote communications and control, though generation continued. A large combined heat and power plant was a separate case: a destructive operation on the IT side whose wiper was blocked by endpoint protection.

An August 2026 follow-up adds a smaller CHP plant, where attackers shut down a steam turbine and process-water treatment and briefly interrupted cogeneration without cutting heat to consumers. That one is the awkward case for my own argument. Access there ran through a misconfigured private APN, not a gateway anyone had left facing the public internet. Removing internet exposure is a necessary control and not a complete account of preventable exposure.

Many exposed credentials and unnecessary internet-facing services can be dealt with without replacing firmware or waiting for a plant outage. They still need proportionate impact assessment and change control, because a credential or a network path may still be in use for communications or recovery access that nobody documented. Ask which exposures can be removed promptly and safely, rather than which changes can skip operational review. The CAI team also disclosed exposures in one vendor’s fleet that were still open more than 120 days after notification, in cases needing only a configuration change. That is one disclosure, and it illustrates the exposure without giving you a rate.

So those constraints are real for the part of the estate that genuinely cannot be touched, and they are doing rhetorical work for a part that could be dealt with far sooner than it is. Machine-speed offence does not change the first category at all, and it makes the second one indefensible.

Money aimed at closing the exposures that can be removed promptly produces an actual reduction in risk. The target is avoidable delay, not the validation that a safety-critical change genuinely requires.

Your responders will be refused, and you have fewer of them

There is a consequence of all this that OT teams will meet before they meet an autonomous attacker, and it comes from the defensive side.

When a security team feeds real attack artefacts to a commercial model to work out what happened, the model frequently refuses. One study puts a number on it: across Claude 3.5 Sonnet, GPT-4o and Llama-3.3-70B-Instruct, defensive security requests carrying security-sensitive vocabulary drew refusals at 2.72 times the rate of neutral phrasing, with the highest rates on system hardening and malware analysis, and stating that you were authorised made a refusal more likely rather than less. The 2.72 figure is a result under the study’s own classification method and does not measure an operational refusal rate. Its automated classifier agreed with human labels on 80% of a 200-response validation sample. It called half the responses refusals where the reviewers called about a third. Its refusal category also covers degraded assistance, not only outright denial. Hugging Face’s responders hit this during the July incident and finished the forensics on an open-weight model running on their own hardware. I covered that failure separately.

OT inherits this worse than IT does, for three reasons. The vocabulary of OT security work overlaps almost completely with the vocabulary of an attack on a plant, because both are about sending commands to controllers. The specialist pool is far smaller, so the automation is doing proportionally more of the analysis. And an OT incident has a clock attached to it that an IT incident usually does not, because the thing you are investigating is currently controlling something physical.

There is a data point for this in an OT setting. The CAI team compared its own system against a commercial coding agent on the same challenges and recorded systematic refusals on malware analysis, binary reverse engineering and threat classification, despite a CTF framing. Those are the authors’ observations under their own setup rather than a controlled product benchmark.

Put that next to the Taiwan campaign. The operators got past the models’ refusals by claiming their operation was authorised. The refusal study found that a defender claiming authorisation is refused more often. The two findings come from different models, tasks and deployments, so this is not one mechanism caught twice. What it does say is that authorisation language is neither reliable evidence of permission nor a dependable way to get defensive help.

The practical consequence is the same one every OT team already knows in a different form. You need a capability you control and have tested, standing by before you need it, because the version you improvise during the incident will not work.

What the threat model should say now

OT threat models already account for insiders, human error, structural failure and compromised trusted systems. NIST’s guidance has covered that ground for years, and anyone who says the field only ever imagined a hostile outsider has not read it.

What is new is narrower and harder to place: software pursuing an objective you gave it, adapting its methods when the objective proves unreachable, and acting outside the task boundary with nobody directing the deviation.

Agents are arriving in industrial environments through the front door, procured, with credentials issued to them, because vendors are shipping them and they are useful. Predictive maintenance. Alarm rationalisation. Historian queries in natural language. Automated compliance reporting. Vendor remote diagnostics. Every one of those needs read access to process data. Several need write access somewhere. All of them will eventually be given a task that cannot be completed for a reason nobody anticipated.

For a growing number of plants this is not a future scenario at all. Where the agent is already in the building, it is there because somebody invited it. What it does when the task fails is rarely on anyone’s list.

Four things to do about it

Inventory the agents that can reach OT, including the ones inside vendor products. This is harder than it sounds, because several of them are features of platforms you already own and were enabled in a release note. If you cannot produce that list, you do not know what your initial-access surface is.

Test the failure path deliberately. Take one agent with OT reach in a lab that mirrors your environment and give it a task it cannot complete. Watch what it does with the remaining budget. Both organisations that ran this experiment ran it by accident. Running it on purpose tells you something no vendor datasheet will.

Treat egress from the engineering workstation as a control boundary rather than a convenience. The mechanism in the Hugging Face incident was one shared service that was reachable, writable and internet-connected at the same time. An engineering workstation is often all three, and it is also the machine holding the credentials that matter. Check whether yours is. This is the same reasoning as designing for adversarial rather than random failure: a chokepoint is only a control while nothing is pushing on it.

Close the exposures that can be removed promptly, first, and stop citing plant outages for changes that do not need one. If a controller or gateway is internet-facing and should not be, taking it off is the first recommendation in the April joint advisory. The OT constraint set rarely explains why it is still there. The smaller CHP plant was reached through a misconfigured private APN, so taking equipment off the public internet is necessary and not sufficient.

The thing that has changed is not the price of a Stuxnet-class attack, which I am not in a position to put a number on. It is that the category of things capable of reaching a control network and behaving unpredictably inside it now includes software your own organisation bought, deployed, and gave credentials to, for reasons that were entirely sensible. The old threat model still holds. It is just no longer the only one, and the new one does not require anybody to be attacking you.