Chemical plants: how do AI agents and robots change the threat model?

In a chemical plant, AI agents and robots change the threat model by shifting decisions from people and fixed logic to software that interprets text and data. The useful move is to rank each plant function by how much the agent may decide, from advising to acting, and to tighten controls and approvals at each rung.

This post cites standards we could fetch and describes no incidents. We did not find verifiable public incident reports to rely on, so we invent none.

What do the sources say about the setting?

CISA describes the chemical sector as manufacturing, storing, using and transporting potentially dangerous chemicals, with a supply chain that other critical infrastructure relies on. That is why uninterrupted, safe operation matters beyond one site.

NIST SP 800-82 Revision 3 guides securing operational technology while addressing its performance, reliability and safety requirements. ISA/IEC 62443 defines requirements for industrial automation and control systems, names process industries including chemicals among the sectors it serves, and bridges process safety and cybersecurity. Its stakeholder groups are asset owners, product suppliers, integrators and service suppliers, with shared responsibility among them.

ISO 10218-1:2025 sets safety requirements for industrial robots as partly completed machinery, and part 2 covers integration. Robot cells in a plant bring that standard into play for the machine, while your cybersecurity program must cover its software.

The decision rights ladder

Pick one plant function at a time and place it on a rung. Most trouble comes from agents sitting one rung higher than anyone intended.

Rung 1: Advise. The agent reads data and answers questions, for example summarizing a shift log or explaining an alarm history. It writes nothing. Main risk: bad advice and data exposure. Controls: read-only access, source citations, no connection to control networks.

Rung 2: Draft. The agent prepares a work order, a procurement request or a change proposal for a person to review. Main risk: a person approves without reading. Controls: structured drafts, diffs, and review that cannot be bypassed by the agent.

Rung 3: Act with approval. The agent executes a defined action after a qualified person approves that specific action. Main risk: approval fatigue and manipulated context. Controls: narrow tools, per-action approval displayed outside the model's output, expiring credentials.

Rung 4: Act alone. The agent acts without approval within fixed bounds. Main risk: everything on the list above, at machine speed. For anything that touches process control or safety systems, we recommend not using this rung. That is our position, not a requirement from a cited standard.

How do roles map?

IEC 62443's roles tell you who answers which question.

• Asset owner (the plant): decides the rung for each function and owns the program. Part 2-1 covers security program requirements for asset owners.
• Product supplier: owns the agent platform or robot firmware. Part 4-1 covers secure product development, so ask for evidence of it.
• Integrator: connects agents to plant systems. Part 3-2 covers security risk assessment for system design.
• Service provider: operates or supports the agent or robot remotely. Part 2-4 covers service providers.

Write who holds each duty into contracts. When an agent misbehaves, the unclear role is the one nobody was watching.

What does the threat model add?

Three things beyond a classic OT model. First, text becomes an attack surface: an agent that reads emails, supplier documents or sensor labels can be steered by content someone else wrote. OWASP's excessive agency entry lists excessive functionality, permissions and autonomy as root causes. Second, the supply chain widens: models, tool servers, plugins and robot firmware all come from suppliers. Third, speed: an agent can do in seconds what a person does in an hour, so limits on calls, spend and actions per task matter.

Dependency basics still help. A software inventory for the packages around an agent, with pinned versions and scans, is something Safeguard's CLI and SBOM generation can support. It does not assess the safety of a process or a robot cell.

What are the limits of this model?

The ladder is a thinking tool, not a certification. It does not replace a process hazard analysis or your functional safety work, which belong to engineers who know the plant. Standards listed here need to be read in full from the publishers.

What to do

1. List agent and robot use cases and put each on a rung.
2. Forbid rung 4 for process control and safety functions.
3. Give agents read-only access to historian and monitoring data by default.
4. Require per-action approval for any write, shown outside the model.
5. Map IEC 62443 roles to every vendor and integrator in contracts.
6. Ask each supplier for a software bill of materials and update-signing details.
7. Cap calls, runtime and spend per agent task, and test a kill switch.
8. Review the ladder yearly and after any agent change.

Quick check

Sources

• CISA: Chemical Sector
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA/IEC 62443 series of standards
• ISO 10218-1:2025 (archived ISO page)
• OWASP GenAI: LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.