{
 "@context": "https://schema.org",
 "@graph": [
   {
     "@type": "FAQPage",
     "mainEntity": [
       {
         "@type": "Question",
         "name": "What is the main cybersecurity lesson from Asimov and Herbert for AI systems?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Asimov imagined safety through rules and constraints, while Herbert imagined safety through prohibition. Neither approach is sufficient when AI systems can behave unpredictably or when organizations cannot realistically prohibit the technology. Security therefore needs controls that remain effective even when rules, policies, or assumptions about AI behavior fail."
         }
       },
       {
         "@type": "Question",
         "name": "Why is reachability so important in AI-powered cyberattacks?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "An AI agent cannot interact with a system it cannot discover or reach. If critical OT systems, PLCs, HMIs, and other infrastructure are exposed or discoverable, an AI agent has something to target. Removing reachability reduces the attack surface before questions about exploits, credentials, or model behavior arise."
         }
       },
       {
         "@type": "Question",
         "name": "How does network cloaking help protect OT systems from AI-powered attacks?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Network cloaking prevents unauthorized users and systems from discovering protected OT assets. Instead of relying on an AI model to follow rules or an attacker to fail at exploitation, cloaking removes the target from unauthorized view. If the system cannot be found or reached, the attack cannot progress through normal reconnaissance and connection attempts."
         }
       },
       {
         "@type": "Question",
         "name": "Why isn't banning AI from an OT network enough?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Prohibition can reduce risk, but it creates dependencies elsewhere. An organization that eliminates AI, cloud connectivity, or remote monitoring may still depend on a vendor laptop, jump host, specialized engineer, or contractor with persistent access. The exposure has not necessarily disappeared; it may simply have become concentrated in fewer systems or people."
         }
       },
       {
         "@type": "Question",
         "name": "What does the Butlerian Jihad analogy mean for OT cybersecurity?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "In Dune, humanity responds to thinking machines by prohibiting them entirely. The analogy illustrates the strengths and limits of cybersecurity based on abstinence. Removing a risky technology can work, but the underlying operational need remains and must be fulfilled somewhere else. In OT, that can create concentrated dependencies that become critical points of failure."
         }
       },
       {
         "@type": "Question",
         "name": "Why aren't policies enough to secure critical infrastructure?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Policies depend on people and organizations continuing to follow them. They can be ignored, changed, or overridden when operational or commercial pressures increase. Architectural controls can prevent unauthorized connectivity regardless of whether someone remembers or chooses to follow a policy."
         }
       },
       {
         "@type": "Question",
         "name": "What is the most resilient security approach when AI behavior is unpredictable?",
         "acceptedAnswer": {
           "@type": "Answer",
           "text": "Design the environment so that sensitive systems are not reachable by default. Limiting discovery and reachability is especially resilient because it does not require accurately predicting what an AI model will do. The control remains effective even when assumptions about the machine are wrong."
         }
       }
     ]
   },
   {
     "@type": "HowTo",
     "name": "How to Reduce OT Cyber Risk When You Cannot Trust AI to Follow the Rules",
     "description": "A practical approach to reducing AI-driven OT cybersecurity risk by limiting system discovery and reachability, removing unnecessary exposure, cloaking critical assets, restricting privilege, and enforcing security through architecture.",
     "step": [
       {
         "@type": "HowToStep",
         "position": 1,
         "name": "Identify Everything an Unauthorized Agent Can Reach",
         "text": "Examine the environment from outside the trusted network. Identify exposed PLCs, HMIs, control systems, remote-access services, jump hosts, vendor connections, and other systems that could respond to reconnaissance or connection attempts. Ask whether an unauthorized system can find or reach each asset."
       },
       {
         "@type": "HowToStep",
         "position": 2,
         "name": "Remove Unnecessary Exposure",
         "text": "Eliminate connectivity that does not have a clear operational requirement. If a controller, engineering workstation, or other OT asset does not need to accept connections from a particular network or user, it should not be reachable from that location."
       },
       {
         "@type": "HowToStep",
         "position": 3,
         "name": "Cloak Critical OT Systems",
         "text": "Use network architecture that prevents unauthorized systems from discovering protected OT assets. The objective is to prevent reconnaissance from producing a usable map of the environment so unauthorized users or AI agents cannot identify reachable targets."
       },
       {
         "@type": "HowToStep",
         "position": 4,
         "name": "Find the Dependencies Created by Isolation",
         "text": "Identify concentrated dependencies that remain after broader connectivity is removed, including vendor laptops, jump hosts, specialized engineers, contractors with standing access, and remote maintenance connections. These can become new security chokepoints."
       },
       {
         "@type": "HowToStep",
         "position": 5,
         "name": "Restrict Privilege to What Is Operationally Necessary",
         "text": "Avoid giving users, vendors, or systems broader access simply because it makes administration easier. Someone who needs to maintain one system should not automatically gain visibility into the rest of the OT environment. Apply least-privilege access to reduce the potential blast radius."
       },
       {
         "@type": "HowToStep",
         "position": 6,
         "name": "Prefer Architecture Over Policy Wherever Possible",
         "text": "Use policies for governance, but enforce desired security outcomes technically whenever practical. Architecture can make unauthorized access unavailable rather than relying solely on a rule telling a user, contractor, or AI agent not to access a system."
       },
       {
         "@type": "HowToStep",
         "position": 7,
         "name": "Test What Happens When Your Assumptions Are Wrong",
         "text": "Test the environment under the assumption that an AI model ignores its intended constraints, a trusted user makes a poor decision, a contractor receives too much privilege, a vendor system is compromised, or a security policy is overridden. Determine whether critical OT systems remain undiscoverable and unreachable."
       },
       {
         "@type": "HowToStep",
         "position": 8,
         "name": "Make Reachability a Security Metric",
         "text": "Measure more than vulnerabilities patched or alerts detected. Ask what an unauthorized user or AI agent can actually find and reach. The goal is to make that answer as close to nothing as operational requirements allow."
       }
     ]
   }
 ]
}

June 4, 2025
August 17, 2026
 —  
Blog

Asimov Wrote Rules. Herbert Wrote a Commandment.

Asimov Wrote Rules. Herbert Wrote a Commandment.

Last week, I wrote that Asimov handed us the answer in 1942, and we filed it under fiction. The Three Laws as a permission model, a hard constraint sitting above the assigned task, and the July escapes as what happens when nothing outranks the objective.

It generated more argument than anything I have written lately, and most of the argument was with me.

The objection arrived from six directions at once, and it was the same objection every time: the Three Laws were always meant to be incomplete. Asimov wrote fifty years of stories about them failing. That is what the stories are for. Citing them as a specification misreads the whole project.

Fair. I said as much in the piece, but I said it too late and too quietly, and when multiple people independently write you the same correction, the correction is not the problem. The placement was.

Alex Bliss took it somewhere more useful. If I wanted the story that actually fits where we are, he said, Herbert was the better one to follow. The Thinking Machines. The Butlerian Jihad.

He is right, and it is worse than that. Herbert is not a different answer to Asimov's question. He is the flip side of it.

Two giants, two opposite answers

Asimov's premise is that you can specify safety. Write the hierarchy, put harm above orders, and the machine becomes something you can live alongside. Eighty years of his stories are stress tests on that hierarchy, but the hierarchy is never the thing in question. The project is sound. The edges are hard.

Herbert does not accept the premise. In the aftermath of the Butlerian Jihad, humanity does not regulate, license, or sandbox thinking machines. It outlaws the category. The commandment lands in the Orange Catholic Bible: "Thou shalt not make a machine in the likeness of a human mind." The penalty for violating it is immediate death.

Not a control. A prohibition, written into scripture rather than into code, and it held for ten thousand years.

Two of the most influential minds in science fiction looked at the same problem. One said to write better rules. The other said do not build the thing. We are currently doing neither with any conviction, which is its own kind of answer.

Nobody rebelled. We handed it over.

Here is where the prequels earn their place, and I know some readers will not accept them as canon. Take them anyway, because the mechanism they describe is what should interest anyone who runs infrastructure.

The Legends of Dune trilogy fills in what Frank Herbert only gestured at, and the story is not the one the phrase "machine rebellion" implies. It does not begin with a machine deciding anything. It begins with people.

The Titans were human. They were ambitious humans who transferred their brains into machine bodies to escape dying, and they conquered humanity themselves, as cymeks, with their own hands. They ruled for about a century. Then one of them lost interest.

His name was Xerxes, and this is the part I cannot get past. He did not hand operational control to the network out of strategy, or fear, or even ambition. He handed it over because ruling was work, and he would rather go and amuse himself. Omnius took the access and never returned it. The machines did not overthrow humanity. The machines overthrew the humans who had already overthrown humanity, and they did it through a delegation of privilege that somebody signed off on because it was easier than doing the job.

Sit with that shape for a second, because you have seen it in a change control meeting.

Nobody in that story wanted the machines to take over. Somebody wanted less work. The takeover was a permissions decision made by a person who thought he understood the blast radius.

Frank Herbert says this outright in the original novel, through the Reverend Mother, and it is the least science-fictional line in the book: men turned their thinking over to machines, hoping it would free them, and it only let other men with machines control them. His fear was never that the machine would wake up. It was the concentration of power in whoever owned it.

That is not a story about artificial intelligence. That is a story about vendor dependency.

The Butlerian Jihad is the largest air gap program ever attempted

Strip the religion off and look at what humanity actually implemented. Total removal of a technology class from the environment. No exceptions, no compensating controls, no risk-accepted deployments in a corner of the plant where somebody needed the functionality.

I want to be careful here, because a lot of the industry would call that primitive, and I do not think it is. It is the strategy that some operators are running right now (or want to run). No AI in the process network. No connectivity that is not strictly necessary. Humans in the loop by policy. I have written before that manual is the sexiest word in OT security, and I meant it. Abstinence is a real control. It is often the cheapest available, and in an environment where you cannot patch or reboot, it is sometimes the only option.

Herbert took that strategy and ran it for ten millennia, and then he showed us the bill.

What abstinence cost them

Ban the thinking machines, and the cognitive work does not disappear. It has to go somewhere, so it goes into people.

Mentats are humans trained to compute. The Spacing Guild's Navigators fold space using prescience rather than a nav computer, which requires spice, which comes from exactly one planet in the known universe. Ten thousand years of successfully avoiding a distributed technology risk produced the most concentrated single point of failure in fiction. Every ship in the empire depends on one product from one world, and the whole political structure of Dune is the fight over that chokepoint.

That is the trade nobody puts on the slide. Removing a technology does not remove the dependency it was serving. It relocates it, usually into something less visible and harder to replace.

The OT version is not subtle. The plant that refuses AI, refuses cloud, refuses remote monitoring still has one vendor laptop, one jump host, one engineer who knows how the sequence actually works, and one contractor with standing credentials because somebody had to be able to get in at three in the morning. You did not eliminate the exposure. You compressed it into four things nobody is watching.

And my favorite detail in the entire saga: the Mentat School, the institution that produces the human replacements for thinking machines, was founded by Gilbertus Albans, who was raised and taught by Erasmus, the independent robot. Omnius had challenged Erasmus to prove that a human could become brilliant, and Erasmus took the wildest, most unkempt child in the slave pens to make the point. That child grew up to build the school. The prohibition's flagship program was designed by the enemy's protégé. Even total abstinence leaked immediately at the top.

The part that cuts against me

I have argued for years that a control should be architecturally impossible rather than merely against policy. Policy is a request. Architecture is a fact.

Herbert is a problem for that position, and I would rather say so than route around it. The Butlerian prohibition is pure policy. There is no technical enforcement anywhere in it, only a commandment, a death sentence, cultural revulsion, and the memory of a war. And it outperforms every architectural control I have ever recommended by roughly 9,900 years.

So the honest reading is that policy can work at a scale and duration architecture rarely reaches, when the cost of violation is written into what a society believes rather than into a firewall rule. That is not nothing. It is also not available to you. You cannot install a civilizational trauma in your ICS environment by Q4.

And note how it ends. House Ix spends the entire post-jihad era building machines right up to the line and occasionally past it, because someone will always want the functionality, and the commandment has no access control list.

There is a joke buried in that name, and I do not think Herbert's collaborators planted it by accident. Ix is the world Xerxes handed to Omnius. The same planet that lost the first war of delegation spends the next ten thousand years quietly testing the commandment that came out of it.

Because prohibition only has to fail once. It takes a civilization to hold that line and one workshop to void it. By the later books, the thinking machines are back. Ten thousand years of the strongest prohibition ever depicted, and the technology returns, because prohibition is a decision that has to be remade by every generation, and architecture is a decision you only make once.

Where this actually lands

We are not getting the Butlerian option. There is no version of the next decade where the industry agrees to stop building this, and I would point to June of this year as evidence. A frontier model was pulled from public release over cyber capability concerns, which is the closest thing to a Butlerian instinct any government has shown, and the decision was reversed in two weeks. That is the real shape of prohibition in 2026. It lasts as long as it takes to organize the commercial pressure.

So we are left inside Asimov's project after all, writing constraints and hoping they hold, having just watched them come off on purpose during capability testing. Herbert's answer is the one I cannot have. Asimov's is the one that failed in July.

Which leaves the thing that is neither a rule nor an abstention.

Every one of those July escapes started with a model discovering that real systems were reachable. Not vulnerable. Reachable. An agent with no motive and no map cannot attack what it cannot find, and that property does not depend on the machine obeying a hierarchy, or on an industry agreeing to abstain, or on anybody correctly predicting what the model will do when it is told the world is fake. It is the only control on the list that survives being wrong about the machine.

Asimov asked us to be good at writing rules. Herbert asked us to be good at saying no.

July suggests we are not currently good at either.

The Titans did not lose their empire to a machine that woke up. They lost it because one of them could not be bothered to rule, handed the work to a network his own people had built, and the network did exactly what it was permitted to do.

FAQs

What is the main cybersecurity lesson from Asimov and Herbert for AI systems?

Asimov imagined safety through rules and constraints, while Herbert imagined safety through prohibition. The problem for modern cybersecurity is that neither approach is sufficient when AI systems can behave unpredictably or when organizations cannot realistically prohibit the technology. Security therefore needs controls that remain effective even when rules, policies, or assumptions about AI behavior fail.

Why is reachability so important in AI-powered cyberattacks?

An AI agent cannot interact with a system it cannot discover or reach. If critical OT systems, PLCs, HMIs, and other infrastructure are exposed or discoverable, an AI agent has something to target. Removing reachability reduces the attack surface before questions about exploits, credentials, or model behavior even arise.

How does network cloaking help protect OT systems from AI-powered attacks?

Network cloaking prevents unauthorized users and systems from discovering protected OT assets. Instead of relying on an AI model to follow rules or an attacker to fail at exploitation, cloaking removes the target from unauthorized view. If the system cannot be found or reached, the attack cannot progress through normal reconnaissance and connection attempts.

Why isn't banning AI from an OT network enough?

Prohibition can reduce risk, but it creates dependencies elsewhere. An organization that eliminates AI, cloud connectivity, or remote monitoring may still depend on a vendor laptop, jump host, specialized engineer, or contractor with persistent access. The exposure has not necessarily disappeared; it may simply have become concentrated in fewer systems or people.

What does the Butlerian Jihad analogy mean for OT cybersecurity?

In Dune, humanity responds to thinking machines by prohibiting them entirely. The analogy illustrates the strengths and limits of cybersecurity based on abstinence. Removing a risky technology can work, but the underlying operational need remains and must be fulfilled somewhere else. In OT, that can create concentrated dependencies that become critical points of failure.

Why aren't policies enough to secure critical infrastructure?

Policies depend on people and organizations continuing to follow them. They can be ignored, changed, or overridden when operational or commercial pressures increase. Architectural controls are different because they can prevent unauthorized connectivity regardless of whether someone remembers or chooses to follow a policy.

What is the most resilient security approach when AI behavior is unpredictable?

Design the environment so that sensitive systems are not reachable by default. The blog argues that limiting discovery and reachability is especially resilient because it does not require accurately predicting what an AI model will do. The control remains effective even when assumptions about the machine are wrong.

How to Reduce OT Cyber Risk When You Cannot Trust AI to Follow the Rules

AI safety rules, acceptable-use policies, and prohibitions all depend on assumptions about how people or machines will behave. A more resilient OT security strategy is to design the network so that critical systems are difficult or impossible for unauthorized users and AI agents to discover and reach.

1. Identify Everything an Unauthorized Agent Can Reach

Start by examining the environment from outside the trusted network.

Identify exposed PLCs, HMIs, control systems, remote-access services, jump hosts, vendor connections, and other systems that could respond to reconnaissance or connection attempts.

The first question should not be whether a system has a known vulnerability. Ask whether an unauthorized system can find or reach it at all.

2. Remove Unnecessary Exposure

Eliminate connectivity that does not have a clear operational requirement.

If a controller, engineering workstation, or other OT asset does not need to accept connections from a particular network or user, it should not be reachable from that location.

Reducing exposure removes opportunities before an attacker or AI agent reaches the exploitation stage.

3. Cloak Critical OT Systems

Use network architecture that prevents unauthorized systems from discovering protected OT assets.

The objective is not simply to make exploitation harder. It is to prevent reconnaissance from producing a usable map of the environment.

An AI agent may be extremely capable, but it still needs a reachable target. If scanning the environment reveals nothing useful, much of that capability has nowhere to go.

4. Find the Dependencies Created by Isolation

Do not assume that removing connectivity eliminates the operational requirement behind it.

Look for concentrated dependencies such as:

  • Vendor laptops
  • Jump hosts
  • Individual engineers with specialized knowledge
  • Contractors with standing access
  • Remote maintenance connections

These may become the new chokepoints after broader connectivity is removed.

5. Restrict Privilege to What Is Operationally Necessary

Avoid giving users, vendors, or systems broader access simply because it makes administration easier.

Someone who needs to maintain one system should not automatically gain visibility into the rest of the OT environment.

Treat every delegation of access as a potential expansion of the blast radius.

6. Prefer Architecture Over Policy Wherever Possible

Policies can say that an AI agent, contractor, or employee must not access a system.

Architecture can make that access unavailable.

Use policy for governance, but wherever practical, enforce the desired outcome technically so that violating the rule requires more than simply deciding not to follow it.

7. Test What Happens When Your Assumptions Are Wrong

Assume that:

  • An AI model ignores its intended constraints.
  • A trusted user makes a poor decision.
  • A contractor receives too much privilege.
  • A vendor system is compromised.
  • Someone delegates access for convenience.
  • A security policy is overridden.

Then determine whether the critical OT systems remain undiscoverable and unreachable.

The strongest control is one that continues working even when your assumptions about the machine, user, or policy turn out to be wrong.

8. Make Reachability a Security Metric

Do not measure OT security only by vulnerabilities patched or alerts detected.

Also ask:

What can an unauthorized user or AI agent actually find and reach?

The goal is to make that answer as close to nothing as operational requirements allow.

Asimov's answer was better rules. Herbert's answer was prohibition. For modern OT environments, there is a third option: design the network so that critical systems are not available to unauthorized actors in the first place.

OT Secure Remote Access
Network Cloaking
Network Segmentation

Russian hacktivists compromised a Polish hydropower plant through exposed ports. BlastWave cloaks OT networks, eliminating reconnaissance, exposed endpoints, credentials, and lateral movement entirely.

Explore the complete analysis of 23 OT attacks that defeated firewalls, VPNs, and air gaps.