A recent Nexus Connect article frames an important concern: frontier AI models are narrowing the gap between identifying a weakness and exploiting it.
Industrial leaders should take that seriously.
But they should not draw the wrong conclusion.
The answer is not to create a complicated new “AI security for OT” program while the environment's fundamentals remain unknown or unfinished.
AI can accelerate reconnaissance, interpret public technical information, identify exposed services, analyze configurations, and help connect weaknesses into plausible attack paths. The 2026 International AI Safety Report notes improving cyber capabilities, including vulnerability discovery, while also recognizing substantial uncertainty in measuring real-world impact.
That changes the speed of the problem.
It does not change the first defensive priorities.
In most OT environments, an attacker does not need a frontier model to benefit from an unowned asset, an exposed remote-access service, a default or overprivileged account, an unnecessary management interface, a flat route between security zones, or a backup that has never been restored.
AI can make those conditions easier to find, understand, and combine.
It does not make basic OT cyber hygiene less important.
It makes the absence of that hygiene more expensive.
The exploitation gap is often a foundation gap
The phrase “exploitation gap” can make the problem sound like an advanced technical contest between sophisticated attackers and equally sophisticated defenders.
Sometimes it is.
But for many industrial organizations, the more immediate gap is simpler: the distance between what the organization believes about its environment and what is actually connected, reachable, trusted, and recoverable.
Do we know every remote connection to the operation?
Can we identify which assets, services, and accounts can reach a controller, engineering workstation, or operator interface?
Have we removed services that no longer serve an operational purpose?
Can a vendor or contractor obtain broad access because it is convenient, rather than because it is necessary and governed?
Can we restore the current configuration rather than merely locate a backup file?
Those are not minor housekeeping questions. They determine whether an ordinary weakness becomes an operational path.
AI may improve an adversary’s ability to investigate that path. The organization’s task is to make the path difficult to find, difficult to traverse, detectable when used, and recoverable if it is compromised.
Do not overthink OT security
This is not an argument for simplistic security.
Industrial environments are complex. They include long-lived assets, proprietary protocols, safety systems, remote sites, specialist support arrangements, aging operating systems, and production constraints that cannot be managed through an IT change window alone.
But complexity in the environment should not become complexity in the first response.
Start with the fundamentals and apply them in the right order.
1. Know the assets and the trust paths
An OT asset inventory is not a spreadsheet of IP addresses.
It should identify the operational function, system owner, firmware or software state, communications, dependencies, remote-support pathway, and safe failure condition of critical assets.
That includes controllers, protection relays, RTUs, HMIs, engineering workstations, remote-access infrastructure, industrial firewalls, gateways, cloud connectors, and vendor-managed components.
Then map how they communicate. The relevant question is not only, “What is on the network?” It is, “Who can reach what, through which path, under which identity, and with what authority?”
Without that answer, advanced monitoring and AI-assisted analysis simply process incomplete context faster.
2. Reduce unnecessary reachability
Every exposed management service, unneeded remote path, persistent vendor connection, and permissive firewall rule is an assumption an attacker may test.
Remote access has a legitimate operational role. Distributed utilities, industrial sites, and critical infrastructure depend on specialized support, engineering coordination, and timely maintenance.
The objective is not to remove every connection.
It is to make every connection explicit, necessary, identity-controlled, time-limited where practical, monitored, and removable when required.
That means removing direct public exposure, disabling unnecessary services, separating administrative and operator functions, enforcing the principle of least privilege, and reviewing remote-access pathways as part of normal operational governance.
3. Build boundaries that reflect process consequences
Segmentation is not only a network architecture exercise.
It is a way to limit the physical consequences of a cyber event.
The appropriate boundary depends on what an asset does, what it needs to communicate with, and what could happen if it is compromised or unavailable.
This is why a protection relay cannot be treated as another endpoint, and why a cloud-connected HMI cannot be treated as only a screen. The operational function, reachability, engineering dependency, and remediation risk all matter.
Security zones, conduits, allowlists, controlled jump paths, and separate identities are not abstract controls. They are the mechanisms that prevent a local compromise from escalating into a broader operational event.
4. Make recovery real
Many organizations have backups. Fewer have proven they can recover a critical OT system under the conditions that will exist during an incident.
Recovery requires more than files. It requires compatible firmware, current configuration copies, licenses, engineering tools, vendor support, trained personnel, clear decision rights, and tested procedures.
It also requires an operational plan for the loss of a remote view, a cloud service, an HMI, or an engineering workstation.
Can the process remain safe? Can operators use independent local indication and established manual procedures? Can the organization restore control without creating a new safety or reliability risk?
Those answers should be tested before an incident, not discovered in its first hour.
5. Use AI as a multiplier, not a substitute
AI can help defenders make better use of scarce expertise. It can assist with documentation review, alert triage, investigation support, configuration comparison, and the prioritization of large volumes of information.
But it cannot compensate for an inaccurate asset inventory, an undocumented trust path, weak access governance, or an untested recovery plan.
And it should not receive authority over an operational system simply because it produces a persuasive recommendation.
The closer AI moves to the physical process, the stronger the testing, identity control, human oversight, and assurance case must become.
The right sequence matters more than the technology
I have made this argument across several recent articles.
In "Why Traditional IT Security Approaches Fail in OT Environments," I argued for an OT-first security approach built on asset visibility, segmentation, passive monitoring, compensating controls, and decisions aligned with safety and continuity.
In A Protection Relay Is Not Another Endpoint, I argued that a vulnerability score cannot determine an operational response without understanding the asset’s function, reachability, dependencies, and remediation risk.
In Private Connectivity, Public Consequences, I argued that private connectivity is not automatically a trust boundary. Each path must be explicitly designed, isolated, monitored, and recoverable.
In Before an AI Agent Enters the Control Room, Find Where It Fails, I argued that operational authority must be matched by assurance.
In the Control Room Test, I asked whether we would still make a cybersecurity recommendation if we were personally accountable for keeping the process safe, available, and running.
These are not separate arguments...They are one operating model:
Asset and trust-path visibility before monitoring. Monitoring before response automation. Governance before autonomy.
The boardroom question has not changed
Boards should absolutely ask whether AI is changing the cyber threat landscape.
But they should also ask a more practical question:
Which known weaknesses could an attacker exploit today, with or without AI, and what prevents that weakness from becoming an operational consequence?
The answer should not be a list of tools.
It should be evidence: named asset owners, current architecture, controlled remote access, tested segmentation, verified backups, restoration exercises, trained operators, and accountable decisions.
That is what resilience looks like in an industrial environment.
Close the basics gap first
Frontier AI may reduce the time between discovery and attempted exploitation.
That is a reason to act with more urgency.
It is not a reason to abandon the disciplined sequence that has always mattered in OT.
Know what you have...Know how it connects...Remove what does not need to be reachable...Limit authority...Preserve safe operation...Prove that you can recover...Then apply AI where it strengthens the team, rather than where it hides unfinished foundations.
AI may be closing the exploitation gap. OT leaders must close the basics gap first.
Sources and further reading
- Nexus Connect, “Frontier AI Models Closing the OT Exploitation Gap”
- International AI Safety Report 2026
- Why Traditional IT Security Approaches Fail in OT Environments
- A Protection Relay Is Not Another Endpoint
- Private Connectivity, Public Consequences
- Before an AI Agent Enters the Control Room, Find Where It Fails