What PLC Safety Interlocks Taught Me About AI Agent Guardrails

I spent eight years at Siemens working on PLC programming, SCADA systems, power infrastructure, and industrial safety. I wrote about how that background shapes my software work separately. The first thing that world teaches you is that operators make mistakes and machines fail, so safety cannot depend on either behaving well. It is designed in layers, and most of those layers sit outside the thing they protect.

When I read discussions about guardrails for AI agents, I often see the opposite: the main safety mechanism is a sentence in the prompt asking the model to be careful. In plant terms, that is a laminated procedure taped to the machine. Useful, but nobody would call it a safety system.

Here are the industrial patterns I now use when an agent gets real tools.

Interlocks: enforce in code, not in instructions

An interlock physically prevents an action while a condition holds. A machine will not start while its guard door is open. It does not ask the operator to remember. The wiring makes it impossible.

For an agent, the interlock lives in the tool. If an agent must never publish, give it no tool that publishes. The article agent on this site can only create drafts with the status pending_review. There is no instruction saying "do not publish" because there is nothing to disobey. The same goes for amounts, recipients, and records: a tool that refunds should refuse anything above a limit in code, whatever the model was told.

A prompt instruction is an operator procedure. A check inside the tool is an interlock. You want both, but only one of them holds when things go wrong.

The best interlocks are designed into the data model. EduManage, our school management software, keeps fees and accounting on an append-only ledger: a posted entry is never edited or deleted, and corrections are made with new entries. No staff member, admin screen, or future AI assistant can quietly rewrite a student's fee history, because the operation does not exist.

Permissives: check preconditions before anything starts

A permissive is a condition that must be true before a sequence may begin. A pump will not start without suction pressure, and a turbine will not start without lube oil pressure.

Agents need the same: validated input, a known target, a budget left. My n8n template that turns support chats into WHMCS tickets fetches the list of valid support departments before creating a ticket, so the model can only pick a department that exists. The tool validates first and acts second.

Independence: the protected system cannot be its own safety system

In process plants, the safety instrumented system is kept separate from the control system it protects. If the control logic is what failed, it cannot be trusted to notice.

The same applies to agents. Asking the model to check its own work before a dangerous action is the control system supervising itself. Real checks run outside the model: validation in the application, authorization rules, a second reviewer, or a person. In my article pipeline, the model's output goes through validation code it cannot influence, then through a person who never saw the prompt.

Fail-safe: losing the signal means going safe

Safety circuits are designed to "de-energize to trip." A broken wire, a lost signal, or a dead power supply puts the process in its safe state instead of leaving it running.

For agents, the safe state is usually "do nothing and tell someone." An unparseable response, a timeout, a missing field, or an unexpected tool error should stop the action, not trigger a creative retry or a best guess. On this site, a generated draft with an empty body throws an exception before anything is written. The failure is loud and nothing reaches the database.

Watchdogs: bound every loop

A watchdog timer expects a regular heartbeat from a controller. If the heartbeat stops, the outputs go to a safe state.

Agents need hard bounds for the same reason: they can loop. My article agent runs with a maximum of six steps, a 180-second timeout, and a cap of three uses per tool. These numbers are not tuned for quality. They are there so a confused run ends on its own, on a schedule I chose.

Bypass management: overrides are deliberate, logged, and temporary

Plants sometimes have to bypass an interlock for maintenance. Doing so needs authorization, a record, and a time limit, because a forgotten bypass is how accidents happen.

In software, the bypass is the "just let it run unattended" switch. My scheduled article pipeline exists, but it sits behind a config flag that is off by default. Turning it on is a deliberate change I make after checking results by hand, and it is visible in the configuration rather than buried in a prompt.

The cause and effect matrix: write down who can do what

Safety systems are documented as a cause and effect matrix: every trip condition on one axis, every resulting action on the other. Anyone can review it without reading the code.

Agents deserve the same document. For each agent, list its tools, what each can change, and which need approval. Here is the shape, using two of my agents and one hypothetical billing agent:

If you cannot fill in this table for an agent, you do not yet know what it can do.

Alarm management: too many warnings train people to ignore them

Control rooms learned that alarm floods make operators acknowledge without reading. The same is true for agent approvals and alerts. If every action asks for confirmation, people click "approve" on reflex. Keep gates for the actions that matter, and make each one clear enough to judge in seconds. I cover how to design those gates in Human-in-the-Loop Approval Gates for AI Agents.

My take

In an industrial plant, the operator runs the process and the safety system stops it from causing harm. An AI agent is the operator, not the safety system. Give it a good procedure in the prompt, then build the interlocks, permissives, watchdogs, and independent checks around it in code. None of this is new. It is decades of hard-won engineering practice, and it fits AI agents almost unchanged. It is also how we approach the AI agents we build for clients at VividSol.