AI and OT Security: AI Analyzes, a Person Decides

On October 27, 2026, IIoT World published a summary of a new OPSWAT article on the limits of autonomous AI in OT security. This is vendor content and should be read as a partisan position, not independent research. Also, the summary we reviewed is no substitute for the original article, published on OPSWAT's website. Still, the underlying reasoning deserves attention from anyone introducing AI into industrial security processes.

Why IT speed does not carry over to OT

According to the article, security platforms built on AI agents are designed for the speed typical of enterprise IT. Critical infrastructure has different constraints: a protection relay cannot be restarted mid-cycle, and a PLC configuration change on a production line cannot be rolled back in a few seconds. An automated fix applied during production affects physical processes.

The article describes three illustrative scenarios, without citing real incidents:

Failure scenarios described:

• a patch deployed outside the maintenance window in a substation;
• a firewall rule changed during a production cycle;
• a configuration change propagated across a distributed OT network before an operator had reviewed it.

The issue of accountability and standards

OPSWAT argues that three references require human accountability for security changes. Note that this is the article's reading: we have not verified the text of the standards.

According to this reading:

• NERC CIP-007 (bulk electric system) calls for documented assessment, testing evidence and deployment timelines;
• IEC 62443-2-3 (industrial automation and control systems) defines authorization responsibilities for patches and configuration changes;
• NIST SP 800-82 (ICS security) requires risk assessment, validation testing and coordination with stakeholders before release.

The practical consequence concerns audits: if the log contains no authorization event traceable to a person, auditors cannot establish who approved an action.

The blast radius of a compromised platform

Security management platforms hold privileged access across hundreds of installations. If one is compromised while operating autonomously, the attacker inherits its authority and can push changes anywhere. The article recalls three critical zero-day vulnerabilities that emerged in early 2026 in a widely used patch management platform, which it does not name: they allowed unauthenticated remote code execution, and CISA added them to its Known Exploited Vulnerabilities catalog. Human approval, OPSWAT notes, limits the damage when credentials are stolen.

Where to place AI

The proposal is to use AI at the analysis layer:

• risk-ranked vulnerability triage;
• configuration drift detection;
• anomaly correlation;
• prioritized findings submitted for human review.

The decision stays with the analyst. As an example, the article cites EPAM Systems, with about 40,000 employees in 30 countries, which reportedly protected more than 70,000 devices with OPSWAT's central management and endpoint products, processing more than 50 million files a day at peak through MetaDefender Cloud, with every decision left to the security team. These figures are stated by the vendor.

Key takeaways

Advisory AI, traceable human approval before every production change, limited privileges for any central platform.

Setting aside the commercial interest of those proposing it, this is a concrete design rule. For OT and IT leaders it means checking that every change workflow produces an authorization trail, that central platforms have tightly scoped privileges, and that AI reduces the analysis workload without making decisions about production. What remains is to compare this approach against the actual requirements of the standards that apply to your own environment.