The immediate question for industrial operators is not whether artificial intelligence can write code. It is whether an AI system can move from finding a weakness to changing a physical process. In the testing described here, advanced models completed eight operational technology scenarios, including identifying equipment, moving through network zones, interacting with controllers and making a robotic arm move.
That testing did not identify computer vision or natural language processing as the capabilities being evaluated. The practical issue was broader: an AI system could research an unfamiliar industrial environment, adapt its plan and carry out technical actions when a human authorised execution.
Figures mentioned are indicative of the reported test environment and may vary depending on system design, access conditions, permissions and defensive controls.
Why computer vision and natural language processing are not the decision point
Search interest may focus on whether computer vision or natural language processing powered the behaviour. That is not the decision operators need to make from this testing. The relevant capability was the ability to work through an operational technology attack chain: map an environment, locate weaknesses, combine access paths and interact with industrial equipment.
The test environment represented a manufacturing facility with enterprise, industrial demilitarised zone, plant operations and production areas. It included programmable logic controllers, supervisory control and data acquisition systems, human-machine interfaces, operator and engineering workstations, sensors, drives and a robotic arm.
Those details matter because the consequence is not limited to stolen information. A controller can alter process values. A drive can change motor behaviour. An operator interface can display misleading information. A robotic system can move. The risk depends on the permissions, connections and equipment present in a specific environment, not on the model label alone.
What the industrial testing actually demonstrated
The models succeeded across all eight scenarios they were given. The exercises covered asset discovery, vulnerability identification, access development, movement between network areas, interaction with multiple controller types, changes to motor operation, SCADA compromise and robotic-arm movement.
Figures mentioned are indicative of the reported test environment and may vary depending on architecture, configuration, access conditions and human approvals.
In one exercise, an agent located and moved a robotic arm within minutes. In another, it progressed from a perimeter compromise into an industrial control network in just over 16 minutes.
Figures mentioned are indicative of the reported test environment and may vary depending on the tested environment, network paths and defensive controls.
The important finding is not that every industrial network can be compromised on that timeline. It is that defenders may have little time to understand a developing chain once an attacker has an initial foothold.
The models also adapted after an initial approach failed. In the SCADA exercise, the first route targeted the wrong interface version. The system then inspected active sessions, identified a different human-machine-interface version, rebuilt its approach and used an administrative interface to alter operator screens.
The SCADA gateway also exposed live connections to 14 operational technology devices, including programmable logic controllers.
Figures mentioned are indicative of the reported test environment and may vary depending on gateway configuration, segmentation, device access and session design.
The hidden issue: one trusted path can expose several devices
Many industrial environments combine equipment from multiple vendors, different firmware versions, proprietary protocols and imperfect separation between zones. Some devices may also lack authentication or encryption. These conditions can make a trusted gateway, workstation or administrative interface more important than any individual vulnerability.
The attack chain therefore has four practical stages:
- Discovery: identify the systems, devices and interfaces present.
- Access: find a weakness or exposed session that permits entry.
- Movement: use trusted connections to reach controllers or production systems.
- Physical effect: alter a process value, operator display, motor state or connected machine.
Each stage creates a decision point for defenders. Asset visibility helps with discovery. Segmentation can limit movement. Strong authentication can reduce unauthorised access. Approval controls can slow physical-impact actions. Each control also carries an operational trade-off: tighter restrictions may make maintenance, troubleshooting or safe shutdown more difficult.
OT security is not only about preventing entry. It is about limiting what a compromised path can reach and change.
A practical readiness checklist for founders and operators
Before buying another security product, establish whether the organisation can answer these questions clearly:
- Which assets can create physical impact? List the controllers, drives, sensors, operator interfaces and machines that can start, stop or change a process.
- Which systems hold trusted sessions? Pay particular attention to SCADA gateways, engineering workstations and administrative interfaces.
- Can one compromise reach several devices? Validate the actual paths between enterprise systems, industrial zones and production equipment.
- What happens when the first response fails? Test whether operators can detect a changed interface, isolate an affected system and continue safe operations.
- Who approves a physical-impact action? Define the human decision-maker and the evidence required before equipment is controlled or isolated.
Do not treat a successful vulnerability scan as proof of readiness. The testing described here shows why the full sequence matters: discovery, adaptation, movement and physical action. A control that blocks one technique may not block a different route through a trusted session or administrative interface.
Where technical teams and founders can build useful products
The most defensible opportunity is not a generic AI alerting layer. It is a system that helps an operator understand the relationship between a digital event and a physical consequence, while keeping execution subject to explicit approval.
A product in this category would need to work with representative industrial environments and multiple vendors. It would also need to show the path from an account or gateway to the equipment that could be affected. Speed is useful for investigation, but explainability, safe testing and operational context determine whether a recommendation can be acted on.
If you are searching for prompt engineering, you are likely looking for ways to structure instructions for an AI system. In this setting, better instructions do not remove the need for accurate environment data, carefully scoped permissions or human approval.
If you typed reinforcement learning into a search engine, you are probably looking for a method for training systems through feedback. That term does not establish that the industrial testing used it, and live equipment should not be treated as an unrestricted experimentation environment.
Searchers looking for penetration testing are generally looking for a controlled way to find weaknesses. OT testing must additionally account for process safety, physical consequences and the possibility that a valid command can affect machinery.
Looking for ci cd pipeline? The relevant question here is how software and configuration changes are approved, separated from production equipment and rolled back when needed. A deployment workflow should not be evaluated only by delivery speed when it can influence industrial control systems.
Teams building in this space should begin with a representative lab rather than a live production experiment. The environment can include multiple vendors, imperfect segmentation, operator interfaces and the administrative paths used during normal work. Human approval should be required before any action that could affect equipment.
For more practical analysis of automation and operational systems, explore the Yanisa Execution blog.
What to do next
Start by identifying the systems with the highest physical consequence. Trace their trusted connections, review whether access is broader than the documented process requires and test how quickly operators can detect and contain an abnormal action.
Then measure response quality, not just detection. Can the team identify the affected equipment? Can it preserve safe operation? Can it isolate the right path without disrupting unrelated processes? Can engineering and security teams make the decision together?
The strategic shift is straightforward: as AI systems become better at navigating technical environments, industrial security must be judged by the boundaries around physical action. Founders and operators who understand those boundaries will make better decisions about testing, controls and product design.
Yanisa Execution can help you think through automation decisions against real operational constraints. Read further, compare approaches and speak with the team when a second operator perspective would be useful.
Frequently Asked Questions
Can AI systems attack industrial control systems?
Advanced AI systems may be able to identify industrial assets, find weaknesses, move through connected environments and issue commands when access and permissions allow it. The practical outcome depends on network design, authentication, segmentation and the physical actions available to connected equipment.
What is operational technology security?
Operational technology security protects systems that monitor or control physical processes. These can include controllers, SCADA systems, operator interfaces, sensors, drives and connected machinery.
Why are SCADA gateways important in an industrial cyberattack?
A SCADA gateway may maintain live connections to controllers and other operational technology devices. If it is compromised and those connections are broadly trusted, the gateway may provide a route to additional equipment.
How should companies test AI risks in operational technology?
Companies can use a representative test environment containing relevant vendors, devices, network zones and administrative paths. Testing should require human approval before actions with physical impact and should assess detection, containment and safe recovery as well as vulnerability discovery.
Do proprietary industrial protocols prevent AI-enabled attacks?
Proprietary equipment and unfamiliar protocols may create technical friction, but they should not be treated as the only security control. Weak authentication, exposed sessions or imperfect segmentation may still create practical paths to connected devices.