Agents on the IT/OT Boundary

Enumerate the crossing paths before you argue about controls.

The common objection — "our agents are nowhere near OT" — is usually true and almost never the relevant question. An agent does not need OT access; it needs access to something that already has it, and every plant has a short list of those. Write yours down before anything else, because the rest of this page is scoped by that list.

• The engineering workstation. Holds the project files, the programming software and, frequently, a saved credential for the controllers. A coding agent or desktop assistant running on it inherits the most privileged OT position in the building — the exposure catalogued in agents on developer workstations, with physical consequences attached.
• The historian and its replication job. The sanctioned, documented, usually bidirectional pipe from OT to IT. Read access to it is the legitimate use case your agent will be built on; the question is whether the same account can write.
• The vendor remote-support tunnel. Standing, rarely reviewed, usually terminating deep in the process network, and increasingly an automated path rather than a human one. Treat it as the third-party risk it is — third-party model and vendor risk.
• The MES/ERP integration. Work orders, recipes, schedules and setpoints flowing from business systems into production. This is the one that matters most for agents, because an agent with ordinary ERP permissions can change what the plant makes without touching a single OT protocol.
• The cloud OT platform. A vendor's monitoring or optimisation service with an outbound connection from the plant and an API on the internet. The agent calls the API; the API has the plant.

Four control ranks, and the only question that sorts them.

The question is not how strong the control is. It is whether an agent that has compromised the network can change the control's state. That one test produces four ranks, and teams routinely buy rank three while writing rank one into the risk register.

• Rank 1 — physics and rated protective functions. A relief valve, a light curtain, a safety-rated speed-and-separation monitor, an emergency-stop circuit. Assessed against functional-safety requirements, designed to act when the control system is the thing that has failed. Nothing sent over Ethernet changes them.
• Rank 2 — hardware mode state. A keyswitch in local or program mode, a physical write-enable jumper, a maintenance selector. Changing it requires a person in the building. This is the cheap rank and the under-used one: it is mostly a decision that remote start is not a feature you need.
• Rank 3 — device-level refusal. Logic on the controller itself that rejects an out-of-range or out-of-sequence command. Strong, and exactly as strong as its firmware, the authentication on the engineering protocol, and whether the logic can be rewritten remotely. Booz Allen's other surviving safeguard was here.
• Rank 4 — everything in the command path. Gateways, policy engines, brokers, your agent's tool definitions, its system prompt. These are the controls you will actually build and they are worth building — policy as code for agents is how ranks 1 to 3 get expressed to software that must respect them — but they are reachable from the network the agent is on, so they are friction.

Segmentation deserves a specific note because it is the control most teams name first. Zones and conduits in the ISA/IEC 62443 sense, and the layered Purdue/ISA-95 model they are usually drawn on, are genuinely valuable: the sixteen minutes in the lab run exists because there were boundaries to cross, and it left a trail. But a boundary enforced by configuration on a device reachable from the side being defended is rank 4 with good intentions. Budget it as the thing that buys you time and evidence, and then ask what the time is for, which is step 4.

Give the agent a read path; make the write path a different system.

Almost every genuinely useful plant agent — anomaly triage, shift summarisation, maintenance prediction, energy optimisation, root-cause narration — is a read workload. The temptation that follows is to give the same agent, with the same credential, the ability to act on what it found, because the demo is so much better. Resist it structurally rather than with policy: the write path should be a different system with a different identity, and the agent's output into it should be a request, not a command.

# The shape that fails: one identity, one protocol, both directions.

agent ──▶ OPC UA client ──▶ controller
          read + write on the same session
          a prompt-injected summary becomes a setpoint

# The shape that holds: read is live, write is a work order.

agent ──▶ historian replica  (read-only account, no write grant anywhere)
      └─▶ CMMS work order    (queued, named human executes it in the plant)
                              ▲
                              └── rank-2 mode switch still required
                                  for anything that moves

Three details decide whether this holds up in practice. The read account must be read-only at the server, not read-only by convention in the client config — an agent that can call a write method will eventually be asked to. The work-order queue must carry the agent's run id and the evidence it based the request on, so the human executing it is reviewing a claim rather than obeying one; this is the decision receipt pattern with a technician as the reader. And the queue must be boring: if the latency of a human picking up a work order makes the use case pointless, that is a signal the use case needed a rank-1 or rank-2 control and an authorised envelope, not a faster approval — the structure argued in physical actuation safety.

Price your response clock against the trajectory, not against the shift.

The sixteen-minute figure is the one that should reorder an OT roadmap, and it is generous to the defender twice over: the run was gated by a human approving each exploit, and the testbed was instrumented by the firm that built it. Set it against the detection and response times organisations actually report for insider-class incidents — around fifteen hours, roughly seven to detect and eight to act — and the conclusion is arithmetic. Passive OT monitoring that answers in hours is worth having for scope, notification and the regulator. It is not in the loop.

Two consequences follow, and both are cheap relative to a monitoring deployment.

• The gate must be synchronous. Any agent action with a physical effect gets a policy decision before it executes, in the request path, failing closed on evaluator error. An asynchronous check is a report. The failure-mode choice is explicit in fail closed and fail open, and in a plant the default is closed.
• The stop must be out of band. A kill switch that revokes the agent's token through the same platform the agent is driving is not a stop. It needs a path that does not traverse the compromised plane and an owner who can pull it without a meeting — kill switches, and the authority question in accountability and roles.

Detection still earns its place, with a narrower target. Generic behavioural baselining fails on agents because an agent is anomalous by construction, but OT gives you the rare signals that do discriminate: a write to a tag no business process writes to, a mode change outside a maintenance window, an engineering-protocol session from an address that is not the engineering workstation. Those are deterministic, low-volume and nearly free — the discriminating-signal argument in detecting agent compromise applied to a domain that happens to have a very short list of legitimate writers.

Log what makes an incident reconstructable, and treat the plant as untrusted input.

After a physical event the question is always the same and is almost never answerable: which instruction caused this, who or what issued it, and on whose authority. In a plant the evidence is scattered across three systems that do not share a clock, which is why this needs deciding before the first incident rather than during it.

• Every tag write and every mode change, with the issuing identity, the agent run id if any, the previous value, and a monotonic timestamp from one source. "Operator changed setpoint" is not evidence when the operator account is what the integration uses.
• The agent's trajectory alongside it, retained at least as long as your incident-investigation window — the retention trade-off in trace sampling and retention. A sampled trace is the one thing you cannot reconstruct later.
• The authorisation record: which envelope this run was operating under and which named human signed it. Without it, liability resolves onto whoever deployed the agent — the gap in insurance and liability for agent actions.

The direction nobody plans for is inbound. Sensor readings, alarm text, device descriptions, tag comments and vendor documentation all flow into the agent's context, and all of them are writable by someone — a contractor, a vendor's firmware update, an attacker who got to the historian first. An alarm description is a string an agent will read as an instruction, which makes the plant a prompt-injection surface and makes telemetry as untrusted input load-bearing rather than theoretical. Obscurity will not help: the lab models worked out a robotic arm's safety zones and movement limits with no documentation at all, so a plan that depends on an attacker not understanding your process is a plan priced against human patience in a market where reconnaissance now costs tokens.

The drill, and the number that tells you where you stand.

Three exercises, in order, none of which requires new procurement.

• The rank census. List every operation in the plant that an instruction arriving over the network can cause to have a physical effect. For each, name the control that would prevent it and its rank. Done honestly, most plants find a large majority at rank 4, and find that moving two or three of them to rank 2 costs a keyswitch and an argument about convenience. That argument is the real work.
• The attended trial. Run the agent read-only against live data for a month and have an engineer grade its conclusions before anything is wired to a work order. This is the tier that finds the agent confidently misreading a tag whose name has meant something different since 2017.
• Fault injection at the conduit. Drop the historian, stall the broker, return stale values, and watch what the agent does — the discipline in fault injection for agents. An agent that treats a stale reading as current is an agent that will recommend an action for a state that ended an hour ago.

The number to report upward is the share of physical-effect operations whose prevention is rank 1 or rank 2. It is uncomfortable the first time and it is the only metric on this page that does not degrade when the model changes, the vendor ships an update, or someone adds a tool in a hurry.