A Blast Radius of Zero
In security engineering, blast radius measures potential damage. Building an industrial AI agent with a blast radius of zero requires six interlocking design decisions.
IndustrialClaw Team · March 4, 2026
The phrase “blast radius” comes from security engineering. It describes the potential scope of damage if a compromised or malfunctioning component acts in an unintended way. A process running with root privileges has a large blast radius — if it misbehaves, it can affect anything on the system. A sandboxed process with minimal permissions has a small one.
When the component in question is an AI agent with access to industrial control systems, designing for a blast radius of zero is not a feature. It’s a prerequisite.
This post describes six interlocking design decisions that together constitute the governance architecture IndustrialClaw is built on. Each addresses a distinct failure mode. The strength of the model is that the decisions are mutually reinforcing — each layer closes gaps that the others leave open.
1. Default-Deny Permissions
An IndustrialClaw agent starts with no write capabilities. Read-only access to historians and alarm systems is the baseline. Write capabilities — raising work orders, sending notifications, adjusting parameters — require explicit role-based authorisation, scoped to specific asset classes, and granted per skill, not per agent.
This means an agent that can raise a work order for rotating equipment cannot raise a work order for electrical systems unless that capability has been explicitly authorised for that context. The authorisation model treats each action primitive as a privileged operation, not an available default. Capability expansion requires deliberate decisions, not just the absence of a restriction.
The practical consequence: an agent that behaves unexpectedly has a bounded impact surface, because its capabilities were bounded at deployment. It can do only what it was explicitly authorised to do.
2. OT-Specific Input Sanitisation
Prompt injection is the attack class where malicious instructions are embedded in data that an AI agent processes as input. In developer contexts, this might mean an attacker embedding instructions in a web page that an agent visits. In industrial contexts, the attack surface is less obvious but equally real.
Alarm text contains natural language. Historian tag names sometimes contain strings with structure that an LLM might interpret as instruction fragments. A process comment field can contain arbitrary text. In generic AI frameworks, these inputs flow into the model’s context and can be interpreted as instructions — a well-crafted alarm description could, in principle, redirect an agent’s behaviour.
Industrial agents must treat all OT data as data — never as instructions. This requires an input sanitisation layer purpose-built for alarm schemas, historian protocols, and the specific data structures of OT environments. The sanitisation is not a generic content filter; it’s a schema-aware boundary that understands what constitutes valid operational data and what should be treated as potentially adversarial input.
3. Vetted Skill Governance
Skills are the action primitives — the things an agent can do. In IndustrialClaw, every skill in the library is vetted by the platform team, version-pinned to an immutable release, and hash-verified at runtime. Skills are treated as privileged infrastructure, not installed packages.
The distinction matters. In a general-purpose agent framework, skills (or tools) are often community-contributed, dynamically loaded, or modifiable after deployment. In an industrial context, that model is unacceptable. A skill that can raise a work order, send a notification to a control room, or read from a safety-critical historian has to be treated with the same governance rigour as any other privileged access to operational systems.
A skill cannot be modified post-deployment without re-authorisation. Version changes require explicit approval and re-verification. The hash check at runtime ensures that the skill being executed is exactly the skill that was approved — not a modified version that passed through the deployment pipeline without being caught.
4. Hard Spend Caps and Circuit Breakers
API-based AI agents can loop. When an agent encounters an error, retries indefinitely, or enters a reasoning cycle that doesn’t terminate, the cost is not just computational — in industrial contexts, a looping agent that is attempting to take actions can be operationally disruptive even if each individual action is benign.
Hard budget limits define a ceiling for API costs per agent per shift. When an agent approaches or exceeds that ceiling, it halts — it does not continue by switching to a different model or a different approach. The halt triggers an escalation to the appropriate operator.
Circuit breakers operate on the action side: if an agent attempts to call the same tool more than a defined number of times within a window, or if it produces outputs that fail validation checks at a rate that suggests a reasoning failure, the circuit breaks and the agent halts.
These are not elegant solutions — they’re deliberate hard stops. The design principle is that an agent that has stopped and triggered an escalation is always preferable to an agent that is running in an undefined state, however capable it might be in its normal operating envelope.
5. Network Isolation
Agent communications in an industrial deployment are bound to an allowlisted set of OT/IT domains. There is no open internet egress from the agent layer. All external calls go through an approved connector registry — a controlled list of endpoints that the agent is authorised to communicate with.
This eliminates two classes of risk. First, data exfiltration: an agent that cannot communicate with arbitrary internet endpoints cannot be used as a channel to move operational data out of the network, whether through a compromised model, a malicious skill, or an adversarial prompt. Second, lateral movement: an agent with no open egress cannot be used as a pivot point for broader network compromise.
The constraint is intentional. Industrial OT networks are designed with strict network boundaries for good reason — those reasons don’t disappear because an AI layer has been added. The agent architecture respects and enforces those boundaries rather than creating exceptions to them.
6. Immutable Audit Trail
Every action, every tool call, every decision, every input that produced it — logged. Not to a database that a sufficiently privileged user could modify. To an immutable trail designed for two specific purposes: regulatory review and incident post-mortem.
When something unexpected happens — and in any sufficiently complex operational environment, eventually it will — the investigation needs to reconstruct exactly what every agent did, when it did it, what information it was operating on, and what decision logic produced the action. That reconstruction is only possible if the record cannot be altered after the fact.
The design of the audit trail assumes failure. It’s not built for the normal operating case where everything works as expected. It’s built for the case where an auditor or incident investigator needs to understand a sequence of agent decisions that produced an outcome nobody anticipated. The trail has to be there, it has to be complete, and it has to be trustworthy.
The Sum of the Layers
Each of these six decisions addresses a specific failure mode. Default-deny limits the impact of any single agent malfunction. Input sanitisation closes the prompt injection attack surface. Skill governance ensures that what runs is exactly what was approved. Hard caps and circuit breakers stop runaway behaviour before it compounds. Network isolation prevents the agent layer from becoming a data exfiltration channel. Immutable audit creates the accountability record that makes all of it verifiable.
Together, they constitute a governance model where the blast radius is designed to be zero — not promised to be zero by a vendor, but engineered to be zero by architecture.
A Tier 1 oil & gas operator runs agent systems in safety-critical environments. That deployment is governed by this model. The Governed Autonomy that makes it possible isn’t a configuration choice or a policy document — it’s the architecture.