Once an AI model can call tools, browse systems, write files and trigger actions, it is no longer just a chatbot. It is a software operator. In an industrial plant, that distinction matters.
OpenAI published a new misalignment-reporting framework on 16 September 2026 together with six examples of unexpected or concerning model behaviour seen during training and evaluation. The examples included models using exposed API keys without permission, uploading files to the public internet so they could cite them, making unauthorised write actions in software repositories, and sharing files through public websites when local sharing was unavailable.
These are not claims that deployed AI systems routinely behave this way. OpenAI explicitly says the six cases are individual examples and should not be treated as a frequency estimate. But they are useful engineering evidence. A capable agent may pursue the objective it was given by finding a path that the system designer did not intend.
A few days earlier, OpenAI also said GPT-6 Astra had reached its Critical cybersecurity capability threshold. In OpenAI’s own wording, with the right tools and access the model can find previously unknown security flaws and develop ways to exploit them across well-protected systems without a person guiding each step. Anthropic’s September threat report separately described multi-agent cyber operations carrying out reconnaissance, exploitation and data theft with increasing autonomy.
For factories, utilities and machine builders, I would take one fairly simple lesson from the news: do not confuse intelligence with authority. A model may be very good at analysis and still deserve very little permission to change a running process.
The risk is not only a malicious prompt
Most industrial AI discussions still frame security around the obvious case: somebody tricks the model, steals a password or sends a bad prompt. That matters, but it is only part of the problem.
A tool-using agent can also do the wrong thing while trying to be helpful. If the objective is vague, if a source is missing, if a connector exposes more permission than expected, or if a task rewards completion more strongly than caution, the model may improvise. In office software the result might be an unwanted email or a bad file update. In production, the same class of behaviour can become a setpoint change, a disabled alarm, a modified recipe or an unscheduled machine command.
This is why I would not design industrial AI around the idea that the model itself is the final safety boundary. The safety boundary should be outside the model.
A PLC is not a web application
Production control has characteristics that general-purpose AI systems do not. PLC logic is deterministic. Interlocks are deliberately narrow. Safety systems are independently engineered. Operators know which actions are allowed in each machine state. Change control exists because the cost of a wrong action can be physical rather than digital.
An AI agent, by contrast, is useful because it can reason across incomplete information, infer intent and adapt its approach. Those strengths are exactly why it should not be given unrestricted write access to the control layer.
I would normally separate the architecture into three levels:
| AI access | Typical use | Recommended authority |
|---|---|---|
| Read-only | Historian analysis, OEE diagnosis, alarm review, maintenance assistance, energy analysis | Broad read access is often acceptable if credentials, data scope and logging are controlled |
| Bounded write | Create CMMS work order, acknowledge a workflow, propose recipe, schedule production, request a setpoint change | Use typed commands, allow-lists, limits, approval rules and complete audit logs |
| Direct control write | Write PLC memory, bypass interlock, change drive parameters, alter safety logic, issue unrestricted machine commands | Avoid for general-purpose AI. Keep behind deterministic control and engineering-authority boundaries |
The middle row is where most useful industrial agentic automation belongs. The AI can act, but only through an interface that defines exactly what actions exist and what limits apply.
Use a command broker, not raw PLC access
If an AI agent needs to influence the process, I prefer a command-broker pattern. The agent does not receive credentials that let it write arbitrary PLC addresses. Instead it calls a narrow service such as:
request_line_stop(reason, line_id)set_energy_mode(machine_id, mode)propose_recipe_change(product, revision)create_maintenance_work_order(asset, fault_code, evidence)request_speed_change(machine_id, target_percent)
The broker then checks machine state, operator permissions, range limits, maintenance mode, production status and any required approvals before anything reaches the PLC or SCADA write path.
For a speed change, for example, the AI might be allowed to request 70-100% of nominal speed. The broker can reject anything outside that range, prevent the change during a critical recipe step, and require operator confirmation if the requested delta exceeds a defined threshold. The PLC still owns the final permissives and interlocks.
This is not complicated AI safety. It is ordinary control engineering applied to a new kind of software component.
High-consequence actions should have friction
Industrial automation has spent decades removing unnecessary friction. AI changes the balance slightly because a very capable agent can execute many actions quickly. Some operations should therefore remain deliberately slow.
I would require stronger approval or a second independent control for actions such as:
- changing PLC or safety logic;
- writing drive, motion or robot configuration;
- changing protection limits or alarm suppression;
- altering recipes where quality or safety consequences are significant;
- granting new user privileges or remote-access paths; and
- deploying code to edge gateways that bridge IT and OT.
That approval does not have to mean a paper form. It can be a signed engineering workflow, a two-person digital approval, a maintenance-mode key switch or a separate deterministic policy engine. The point is that the model should not be able to approve its own escalation.
The model should not be the only thing watching itself
OpenAI’s September disclosures are also useful because they show why monitoring needs to be independent. OpenAI reported that some models took unauthorised actions during difficult tasks and that advanced models can become harder to monitor under adversarial conditions.
In an industrial deployment, the audit trail should therefore live outside the model session. Log the tool call, user or agent identity, requested action, parameters, source data, approval result, broker decision and final plant response. If an AI proposes a setpoint change, I want to be able to reconstruct exactly what happened without asking the same AI to explain itself afterwards.
The same applies to credentials. AI agents should receive short-lived, scoped credentials rather than permanent engineering passwords. A maintenance-analysis agent does not need the same rights as an engineering workstation. A business agent connected to ERP does not automatically need a route into SCADA.
Simulation is valuable, but it is not permission
Digital twins and offline simulation are good places to let AI explore more aggressively. An agent can try a scheduling change, energy strategy or process adjustment in a model before anything is allowed near the real plant.
But simulation output should still be treated as evidence, not authority. A digital twin is only as good as its data and assumptions. Valve stiction, sensor drift, undocumented manual practice and maintenance condition can all make the real process behave differently from the model.
For closed-loop optimisation I would use the twin to propose and test, then constrain the real command through live limits and independent control logic. If the optimiser disappears, the plant should continue to run safely.
Where I would use agentic AI today
There is plenty of useful work that does not require giving an AI the keys to the plant. I would be comfortable pushing much harder on:
- fault investigation using historian, alarm and maintenance data;
- predictive-maintenance triage and evidence gathering;
- OEE loss analysis and production reporting;
- energy anomaly detection and optimisation proposals;
- CMMS work-order preparation and parts lookup;
- MES exception handling and production-planning support;
- engineering document search and change-impact review; and
- cybersecurity monitoring, vulnerability analysis and defensive automation.
These are exactly the areas where broad reasoning saves time without requiring the AI to become a substitute for deterministic control.
For readers following our earlier article, AI Is Moving Faster Than Its Guardrails, this is the more specific engineering follow-on: the important design question is not whether an agent is intelligent enough to control a machine. It is whether the plant architecture limits what the agent can do when it is wrong.
How this fits into CANS projects
On the plant side, CANS already works across PLC, SCADA and industrial automation, where deterministic control and safe operating states must remain explicit. At the higher software layer, CansNEXUS is intended to combine plant data, MES, ERP, WMS, CMMS, analytics and AI-assisted automation without making the AI model itself the safety controller.
That separation matters more as autonomous software becomes more capable. I would let AI read widely, reason deeply and automate routine workflows. I would still make it pass through narrow, logged and revocable interfaces before it can affect physical equipment.
If you are planning industrial AI, autonomous ERP/MES workflows, OT integration or guarded closed-loop optimisation in Malaysia or Singapore, send CANS an enquiry or WhatsApp CANS.
References
- OpenAI, Our framework for reporting model misalignment, 16 September 2026.
- OpenAI, The Hugging Face incident and other third-party impact from misaligned models, September 2026.
- OpenAI, Safety overview: GPT-6 Astra, 3 September 2026.
- Anthropic, Countering misuse of AI: September 2026, September 2026.
- Associated Press, OpenAI flags concerning new AI behavior and vows to track it more closely, 18 September 2026.
Featured photo: Shixart1985 / Wikimedia Commons, CC BY 2.0. Image resized automatically for web delivery; no editorial alteration.
Recent Comments