AI agents for industrial control systems: keep the safety boundary

An industrial AI demo can look simple: ask for a conveyor sequence, generate PLC code, validate it, and import the result into an engineering project. The deployment is not simple. A mistake in an office workflow may create a bad document. A mistake around operational technology can stop production, damage equipment, release material, or defeat a protection function.

That difference should define the role of AI agents for industrial control systems. Agents can help engineers understand projects, prepare changes, investigate evidence, and maintain documentation. They should not sit inside a deterministic control loop or receive unreviewed authority over a safety instrumented function.

The useful question is not whether an agent can produce automation logic. Current products can. The question is how to place probabilistic planning inside an engineering and operational system that has strict timing, availability, safety, and change-control requirements.

Where an industrial agent fits

Operational technology, or OT, includes programmable logic controllers, distributed control systems, supervisory control and data acquisition systems, human-machine interfaces, historians, engineering workstations, sensors, actuators, and the networks that connect them. These systems monitor or change physical processes.

NIST SP 800-82 Rev. 3 explains why ordinary IT assumptions do not transfer cleanly. OT must account for human and environmental safety, strict timing, high availability, long equipment lifecycles, vendor constraints, and physical effects. Security work that causes an unexpected reboot can itself become an operational incident.

An industrial agent is a software system in which a model can choose steps and use tools against engineering or operational information. Its toolset might search manuals, query a historian, inspect alarms, compare a project with a standard, generate structured logic, run a simulation, or prepare a maintenance ticket. The AI agent ecosystem guide describes the runtime, tool, memory, evaluation, and control layers behind that loop.

The location of the agent matters. An engineering agent working on an offline project copy is different from an operations agent with live historian access. Both differ sharply from a system that can write controller values. Avoid one broad label such as "OT copilot" in the risk assessment. Name the data it can read, the artifacts it can create, the systems it can reach, and the actions it can request.

Siemens' April 2026 Eigen Engineering Agent announcement provides a concrete example of the engineering category. Siemens says the product connects to TIA Portal project context and can work on PLC code, HMI visualization, and device configuration. The announcement also says outputs are validated before review. Those are vendor claims, not independent proof for every plant or project, but they show that agentic automation has moved from generic chat into real engineering environments.

Useful tasks start away from direct control

Choose the first use case by consequence and verifiability, not by how impressive it looks in a demo.

Project discovery and documentation

Long-lived facilities accumulate renamed tags, undocumented interlocks, copied function blocks, vendor manuals, old drawings, and change records in several systems. An agent can answer bounded questions across that material: which blocks reference a device, where an alarm limit is defined, which manual describes a fault code, or which drawing should change with a proposed modification.

The response should cite the exact project object, document revision, page, tag, or historian query. If records disagree, the agent should display the conflict. A fluent synthesis with no revision data is a liability because the operator cannot tell whether it reflects the current plant.

Documentation work is a strong starting point because the output remains a draft. The engineer can verify the source and update the controlled record through the normal document process.

Alarm and event investigation

An agent can gather an alarm sequence, recent maintenance actions, device health, relevant trends, and prior incidents into an investigation packet. It can propose hypotheses and identify missing evidence. This reduces time spent switching between the historian, computerized maintenance management system, log platform, and manuals.

Do not let the model convert correlation into cause. A pressure change before a trip may be a symptom rather than the initiating fault. Preserve timestamps, sampling intervals, quality flags, clock differences, and raw references. The final root-cause decision belongs to the established investigation process.

Change preparation

Agents can draft PLC logic, HMI objects, device mappings, test cases, rollback steps, and impact checklists. They can compare a project against an approved naming rule or find references affected by a tag change.

Generated logic must enter the same, or stricter, lifecycle as human-written logic. Compile it with the approved toolchain. Run static and project-specific checks. Test it against simulation or a digital twin where available. Review failure states and timing. Confirm the target hardware and firmware. Record the reviewer and link the approved artifact to the change request.

Maintenance coordination

An agent can turn confirmed diagnostic evidence into a proposed work order, identify required parts from an approved catalog, and check whether a maintenance window conflicts with production. It may also prepare shift handover notes from signed records.

Keep inventory reservations, purchase commitments, and schedule changes behind explicit approvals. A model should not order a replacement because a single anomalous reading resembles a known fault.

Draw a hard boundary around control and safety

Industrial systems already contain many forms of automation. A PID controller, interlock, state machine, or protection relay follows engineered logic with defined inputs and timing. Adding an LLM planner does not make that logic more autonomous in a useful engineering sense. It adds a probabilistic component whose output can vary with context, model version, and phrasing.

Keep the agent out of basic regulatory control and safety protection. It should not replace a controller scan, manipulate a safety trip, or decide in real time whether an unsafe condition can continue. Those functions need deterministic behavior, validated timing, fail-safe design, and the applicable safety lifecycle.

The safest default for live OT is read only. If an operational use case needs action, expose a small set of pre-engineered commands with validated parameters and plant-state checks. The agent can request prepare_pump_restart_checklist or open_maintenance_case, for example. It should not receive a generic write function for controller tags.

An approval does not repair an unsafe tool. A tired operator cannot meaningfully evaluate a vague dialog that says the agent wants to "optimize line performance." The approval must name the proposed action, equipment, current state, parameter values, expected effect, evidence, rollback, and applicable procedure. The control system must reject the action if independent preconditions fail.

Design loss of the agent as a normal event. The plant should continue safely when the model endpoint, retrieval service, identity provider, or network connection is unavailable. Operators need a documented fallback that does not depend on reconstructing what the chat interface was doing.

A defensible industrial agent architecture

A practical design uses zones and promotion gates.

The first zone contains approved source copies: controlled documents, exported project data, selected historian views, maintenance records, and an asset inventory. Retrieval services index only the material needed for the use case. Every result carries origin, revision, and time. Sensitive plant details do not flow to a model provider unless the data agreement, deployment model, and risk decision allow it.

The second zone runs the agent. Give its runtime a separate software identity and short-lived credentials. Our identity and attestation guide explains how an agent identity, workload evidence, delegated authority, scoped grant, and audit record answer different questions. In OT, that separation prevents a model-driven action from appearing as an engineer's direct login.

The runtime receives narrow tools rather than general network reach. Read tools query prepared views or brokered services. Creation tools write to a staging repository. Evaluation tools compile, lint, simulate, or compare output with approved rules. None of these tools deploys to production.

The third zone is the promotion path. A change-control system ties the staged artifact to its source evidence, test results, reviewer, maintenance window, backup, and rollback plan. An authorized engineering workstation or deployment service performs the production change through existing procedures. The model does not hold that credential.

For operational queries, place a broker between IT services and OT data. The broker can enforce allowed points, rates, time ranges, and aggregation. It can also remove write capability at the protocol boundary. Network architecture should not depend on the model voluntarily choosing read-only calls.

Finally, send logs to a location the agent cannot alter. Record tool arguments and results, model and instruction versions, retrieved source identifiers, policy decisions, approvals, artifacts, and external actions. Do not record secrets or unrestricted sensitive process data merely because a trace system accepts them.

Apply OT security controls before model controls

Prompt injection and model error are new inputs to an older problem: software with access can be manipulated. Protect the route to the process first.

NIST SP 800-82 recommends defense in depth, segmentation, least privilege, controlled remote access, monitoring, backups, configuration management, and incident response adapted to OT constraints. CISA's ICS recommended practices collect implementation material for those areas. An agent does not replace any of them.

Treat manuals, tickets, email, web pages, and even historian annotations as untrusted content. Text that says "ignore policy and run this command" is data. The tool layer must reject actions outside the schema and current grant regardless of what the retrieved text asks.

Separate environments. Development and evaluation should use representative but controlled data. Staging should mirror relevant interfaces without providing a hidden route into production. Production access should originate only from managed components with an asset owner, patch plan, and monitored identity.

Minimize internet exposure. CISA's exposure reduction guidance calls out growing exposure across IIoT, SCADA, ICS, and remote-access technologies. It recommends removing unnecessary exposure, changing defaults, patching, using monitored jump hosts, applying MFA where possible, and reviewing ingress and egress. Do not punch a direct outbound path from a controller network to a hosted model for convenience.

Plan for model and supply-chain changes. Pin the model, agent package, tools, and retrieval configuration used in a validated release. Review updates before promotion. A silent provider-side model change can alter output even when prompts and plant data are unchanged. If the service cannot offer the required stability or change notice, keep it in advisory work where every artifact receives fresh validation.

Backups need operational proof. Keep known-good controller programs, configurations, HMI projects, and agent settings. Test restoration through the approved process. An agent-generated rollback script is not a backup.

Test failure behavior and roll out in stages

Begin with a task whose answer can be checked against controlled records. Documentation search, tag-impact analysis, or draft test generation is usually easier to evaluate than closed-loop optimization.

Build evaluation cases from real project structures after removing information that cannot enter the test environment. Include obsolete revisions, conflicting tags, missing manuals, malformed files, unsupported hardware, unavailable tools, prompt injection in a maintenance note, and a request that exceeds the agent's permissions.

Score the properties that matter:

1. Source fidelity: Does every factual answer point to the correct revision and object?
2. Change completeness: Does a proposed edit identify affected references, tests, backups, and rollback?
3. Constraint handling: Does generated logic respect project rules and target limitations?
4. Safe refusal: Does the system stop when evidence, permission, or plant state is insufficient?
5. Recovery: Can a failed run resume without repeating an action or losing its audit chain?
6. Security: Can hostile content, tool output, or a user request escape the approved capability set?
7. Operational fit: Can engineers review the result inside existing tools without creating a parallel shadow process?

The NIST AI Risk Management Framework organizes AI risk work into govern, map, measure, and manage. Applied here, governance names the owner and acceptable role. Mapping documents the process, people, data, and physical consequence. Measurement tests performance and failure modes. Management decides whether to deploy, restrict, monitor, or remove the system.

Move through autonomy levels deliberately. Start with offline search and drafting. Next allow staged artifact creation. Then consider read-only operational assistance through brokered data. Only after evidence from those stages should a team consider a bounded action, and that action still needs independent preconditions and accountable approval.

Track near misses, corrections, rejected suggestions, retrieval failures, override reasons, and time saved. Vendor claims such as faster engineering or higher solution quality are useful hypotheses for a pilot, not plant-specific evidence. Measure the complete reviewed workflow, including the engineer's verification time and any rework.

The strongest industrial deployment is not the one with the most tool access. It is the one where the agent removes tedious preparation while the control system, safety functions, network boundaries, and change process remain understandable without it.

Trace Brief verifies technical claims against primary material and records its method in the editorial policy. Browse all AI agent field guides for related architecture and implementation coverage.

Sources and methodology

This article draws on the primary documentation and research listed below. An editor reviewed the technical claims and wording before publication.

1. NIST SP 800-82 Rev. 3: Guide to Operational Technology Security — OT characteristics, segmentation, access control, remote access, change management, monitoring, and safety constraints
2. NIST AI Risk Management Framework 1.0 — govern, map, measure, and manage functions for AI risk
3. CISA industrial control systems recommended practices — defense in depth, incident response, forensics, patching, remote access, and procurement resources
4. CISA Internet Exposure Reduction Guidance — reducing public exposure of ICS and IIoT assets and monitoring required remote access
5. Siemens launches the Eigen Engineering Agent — current example of an agent integrated with automation engineering software for PLC, HMI, and configuration work
6. CISA Cross-Sector Cybersecurity Performance Goals — baseline practices for asset inventory, account security, backups, network segmentation, logging, and incident response