How do AI agents and robots change the threat model on an oil rig?

AI agents and robots add a new kind of actor to an oil and gas site: software that reads instructions, decides and acts on equipment. The threat model changes in three ways. The agent holds credentials, its inputs can be manipulated, and its output can reach physical controls. Limit permissions, treat output as untrusted and keep humans on risky actions.

This post does not describe any incident or any specific system. It combines NIST's OT guide, the ISA/IEC 62443 role model and OWASP guidance on LLM output handling. Safety decisions belong to the engineers who own the process.

What is different about an agent?

Traditional automation does what it was programmed to do. An agent chooses steps from a goal, using tools you give it. So you now have to ask who the agent is, what it can touch and what can steer it.

NIST describes OT as programmable systems and devices that interact with the physical environment. An agent connected to those systems, directly or through a maintenance tool, is part of that attack surface.

What are the three shifts?

1. A new identity with real access. An agent needs credentials to read sensor data, open tickets or send commands. If the credential is broad, the agent is a high value target, and so is the platform that hosts it.

2. Inputs you do not fully control. An agent may read work orders, vendor documents, emails, logs or camera feeds. Any of those can contain text written to steer the model. OWASP's guidance on improper output handling describes how a summarizer reading a page with embedded instructions can be led to act on them. A rig has many documents from many parties.

3. Output that becomes action. OWASP says model output passed unvalidated to other components can lead to outcomes including remote code execution and privilege escalation, and recommends treating the model as any other user with a zero trust approach. If an agent's text becomes a command to a controller or a script on an engineering workstation, that guidance applies directly.

What about robots?

A robot adds a body to the same problem. It carries software, firmware and libraries from several suppliers, and it moves in a space with people and equipment. The supply chain questions are the usual ones: what is inside, who patches it and how do you know when a component is flawed. Ask suppliers for SBOMs, and scan what you receive. Safeguard's CLI can scan an SPDX or CycloneDX SBOM against its advisory database, which tells you which components are known to be flawed, not whether they matter on your rig.

How do the 62443 roles apply?

ISA/IEC 62443 separates asset owners, product suppliers, integrators and service suppliers. With agents, add a question to each: who is responsible for what the agent can do? The operator decides its permissions. The supplier documents how the product handles security. The integrator wires it in. Write those answers down before commissioning, not after.

What controls fit?

• Least privilege. Give the agent read access first. Add actions one at a time, each with an owner.
• Zones and conduits. Keep agent tooling out of the control network unless required, and route through monitored, narrow paths.
• Permission modes. Prefer a mode where risky steps need human approval. Safeguard's runner, as an example of the pattern, offers modes ranging from supervised to autonomous, and its one shot command denies anything not pre-approved by default.
• Validate before acting. Parse agent output into a fixed schema, check values against safe ranges and reject anything else.
• Hard limits outside the model. Safety interlocks and range limits live in the control system, not in a prompt.
• Logging. Record inputs, outputs and actions so you can reconstruct events.
• Offline behavior. Remote sites lose links. Decide what the agent does when it cannot reach its model or its approver, and default to a safe state.

What to do

1. List every agent or robot, what it can read, what it can change and who approves.
2. Give each its own credential, scoped narrowly, with an expiry.
3. Map every input source it reads and mark which are untrusted.
4. Add schema and range checks between agent output and any controller.
5. Keep safety limits in the control system.
6. Ask suppliers for SBOMs, scan them and track fixes.
7. Log and review agent actions weekly at first.
8. Run a tabletop exercise where an agent receives a manipulated work order.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA/IEC 62443 series of standards
• OWASP GenAI: LLM05:2025 Improper Output Handling
• Safeguard Local Runner docs

Last reviewed: 18 October 2026.