RSS Amplifier

Edward's Substack · Jul 29, 2026

XOT Is the Right Expansion. Governed Influence Is the Next One.

0
Sign in to vote or save

Edward J. Liebig · Edward's Substack

In the recent Nasdaq discussion, June 29, 2026, Protecting the Physical World: Cyber’s Next Frontier., Dragos CEO Robert M. Lee described a case in which a commercially available AI system helped an attacker move through the IT environment of a water utility.

It mapped the network, identified a gateway that appeared to lead toward operational systems, researched the target, generated candidate passwords, and attacked the boundary.

It didn’t get through.

That matters. But so does what happened before the attempt failed.

The attacker didn’t need to begin with deep industrial-control expertise. The AI supplied enough research, reconnaissance, and technical reasoning to recognize a path that might be influential to the physical operation.

Rob didn’t turn the example into a prediction of autonomous malware independently manipulating industrial processes (“boo!”). His argument was more measured and, in many ways, more consequential.

AI can help an attacker reach the operational boundary faster. It can reduce the expertise previously required to find that boundary. At the same time, AI is entering the operational environment itself, increasing the number of systems, decisions, dependencies, and machine-generated conclusions that defenders and operators must be able to understand.

The result is not simply a faster attacker.

It is a wider and less explainable field of operational influence.

Rob’s discussion of extended operational technology, or XOT, provides the right starting point. If a system can materially affect a physical operation, it belongs within the operational-security conversation regardless of whether we traditionally label it IT, OT, IoT, cloud, enterprise, or industrial.

That’s an important and, from my perspective, an absolutely welcomed expansion of the boundary.

The next expansion must be in the control model.

Once we can see the extended operational environment, we must be able to determine how pressure and influence moves through it, who or what possesses authority, which pressures or controls can change the outcome, and whether we will have enough correlated evidence to explain what happened when the system behaves differently than expected.

That’s the progression from XOT visibility to governed Operational Assurance and Resiliency.

There is a significant difference between entering an organization and understanding how the organization’s physical process works.

An attacker may gain access to an enterprise environment for espionage, credential theft, persistence, or future optionality. That’s serious, but it’s not necessarily evidence that the attacker understands how to produce an operational consequence.

Control-loop mapping represents something more deliberate.

It means learning how the process behaves, which systems influence it, where control decisions originate, how digital instructions reach physical equipment, which dependencies matter, and what sequence of actions or pressures might alter the outcome.

The attacker is no longer merely asking:

  • Where can I enter?

The attacker is beginning to ask:

  • How does influence become consequence?

That is a material escalation, and it creates a corresponding requirement for the defender.

The operator should already possess that map. Not simply a network diagram.

  • Not simply an asset inventory.

  • Not simply a list of vulnerabilities.

The organization needs a defensible understanding of how physical processes, control systems, enterprise applications, cloud services, human decisions, vendor access, procedures, maintenance activities, and now AI-generated recommendations combine to affect the operation.

This is where conventional threat-forward analysis reaches its limit.

Cybersecurity often begins with an actor, technique, vulnerability, or exposure and reasons forward toward a possible impact. Operational environments require us to be equally capable of reasoning in the other direction.

That reverse path is the operating logic behind NexGenomics CIE-CORE™ our Cyber-Informed Engineering-inspired, Consequence-Oriented Risk Evaluation. CIE-CORE begins with an unacceptable physical, safety, environmental, production, or business outcome and works backward through the systems, dependencies, controls, authorities, and evidence that determine whether that outcome can occur.

Begin with the unacceptable outcome.

  • What must not happen?

    • A loss of containment.

    • An unsafe pressure condition.

    • A corrupted batch.

    • A prolonged outage.

    • An environmental release.

    • Damage to a critical asset.

    • A mistaken restart.

    • An operator acting on incomplete or misleading information.

Then work backward.

  • What would have to fail?

    • What systems influence those conditions and how?

    • What physical, digital, human, and procedural controls stand between the initiating event and the consequence?

    • Could those controls detect and prevent the condition in time?

    • Who or what has the authority to intervene?

    • What evidence would need to be required and present before acting?

CIE-CORE turns those questions into an evaluation and decision process. It doesn’t begin by asking which technology should be purchased or which checklist should be completed. It establishes what matters, how that outcome can be influenced, whether the controls can materially change it, and what evidence is necessary and sufficient to support action.

An adversary performing control-loop mapping is trying to discover how influence becomes consequence.

The defender should already know.

This is also where Rob’s XOT framing connects directly to arguments I’ve made previously in The Physical Process Is the Asset.

  • The PLC is important.

  • The industrial network is important.

  • The engineering workstation, historian, safety system, remote-access service, and identity platform are important.

But none of them is the ultimate object of protection.

They matter because of the physical process they support, the decisions they influence, and the consequences their failure can create.

This is more than just semantics.

When the network or device becomes the assumed boundary of OT, organizations naturally concentrate on what can be discovered and monitored inside that boundary. They may overlook an enterprise application, cloud service, third-party action or platform, physical access process, maintenance workflow and dependencies, or AI-generated recommendation that sits outside the traditional OT architecture but can still alter the physical outcome.

XOT helps correct that.

  • A cloud-hosted application can be operationally critical if its loss stops production.

  • An enterprise identity service can become part of the operational path if it governs engineering access.

  • A printer can become operationally relevant if its failure prevents required labels from being produced and the line cannot continue.

  • A work-management application can influence operational safety if it changes the order, timing, or approval of maintenance.

  • An AI assistant can influence an industrial process without directly communicating with a controller if an operator, engineer, or manager relies on its recommendation.

The relevant boundary is therefore not defined solely by network location or device classification.

It is defined by consequence.

A system belongs within the operational-assurance boundary when its availability, integrity, output, or failure can materially affect the physical operation.

That expands the population of systems we must see.

But seeing them is only the beginning.

The operational attack surface tells us where an adversary may gain access, move, persist, or exploit a weakness.

The influence surface tells us how a compromised, mistaken, manipulated, incomplete, or ungoverned input could change an operational decision or physical outcome.

The two surfaces overlap, but they are not identical.

  • A system may present little direct attack value and still exert substantial influence.

  • A report can alter a maintenance priority.

  • A model can change how an anomaly is interpreted.

  • An enterprise workflow can delay a critical response.

  • A vendor recommendation can become an operating assumption.

  • A configuration record can establish a false version of engineering truth.

  • A thermal, vibration resistant, high speed camera, and audio, ultrasonic, vibration sensor, values can confirm, or contradict, the digital state reported elsewhere.

  • A human can possess informal authority that is not represented in any identity system.

  • An AI system can summarize, prioritize, escalate, recommend, or draft conditions without possessing direct actuation rights, yet still influence the person who does.

This is why the emerging operational-security problem cannot be reduced to connectivity.

Connectivity creates paths.

Influence gives those paths meaning.

The organization must understand not only which systems communicate, but also which systems can shape:

  • operational understanding;

  • attention and prioritization;

  • engineering judgment;

  • access decisions;

  • work authorization;

  • incident escalation;

  • maintenance sequencing;

  • compliance records;

  • production decisions;

  • and eventually physical execution.

The influence surface includes the obvious paths into controllers and control logic. It also includes the less visible paths into human judgment.

That distinction becomes increasingly important as AI moves from generating information to participating in decisions.

Much of the current industrial AI discussion is focused on offensive acceleration.

That concern is justified. Attackers will use any capability that lowers the cost of reconnaissance, experimentation, and exploitation.

AI can automate research, identify likely technologies, translate unfamiliar terminology, generate scripts, test hypotheses, propose credentials, and help an attacker traverse systems without possessing the same depth of expertise previously required.

It can help highly capable actors scale their expertise across more targets. It can also make less capable actors more effective against conventional boundary defenses.

But offensive acceleration is only one part of the problem.

AI also introduces a new chain of operational complexity inside the environment being defended. An agent’s output does not emerge from a single model interaction. It is produced through a sequence of infrastructure, data, identity, model, memory, workflow, authority, and inference decisions, each of which can alter what the agent sees, how it reasons, what it is permitted to do, and whether its objective is achieved within trusted bounds.

That chain must be governed as an architecture, not treated as a black box.

At NexGenomics, we separate this chain into eleven distinct governance boundaries:

This matters because an agent can appear to achieve the correct objective while relying on untrusted data, an inappropriate model, unauthorized context, stale memory, excessive privileges, or an ungoverned tool invocation. The output may be plausible, and the operational result may even appear acceptable. But without architectural evidence across the full inference and data-handling chain, the organization cannot establish that the result was traceable, authorized, or produced within declared governance bounds.

The objective is therefore not merely to verify the agent’s final action. It is to prove how the agent pursued its objective, what outcome resulted, and whether the entire chain remained within approved data, model, identity, authority, workflow, and human-accountability boundaries.

That is the complexity NexGenomics is designed to govern.

  • AI can generate an answer.

  • An agent can pursue an objective.

  • Under pressure an agent must be bound to an environment

  • A trusted architecture must prove how it did so, and whether the resulting outcome remained within authorized bounds.

In The Technology Wave After AI Security, I described AI as part of a broader transition from systems of record and systems of engagement toward systems of judgment.

  • Systems of record preserve authoritative information.

  • Systems of engagement connect people, processes, customers, and partners.

AI systems do something different. They interpret, summarize, recommend, prioritize, escalate, draft, decide, and sometimes act.

They produce judgment-like outputs that people may rely upon.

That changes the trust problem.

  • A system of record can be audited after the fact.

  • A system of engagement can be monitored through workflow controls.

A system of judgment must be governed at the moment influence is created.

  • When AI summarizes an incident, it influences understanding.

  • When it prioritizes a vulnerability, it influences attention.

  • When it recommends an engineering action, it influences authority.

  • When it drafts a regulatory response, it influences institutional memory.

  • When it operates as an agent, it influences execution.

The question is no longer only whether the information was protected.

The question is whether the judgment produced from that information deserved to influence the next decision.

That’s the architectural challenge.

In the earlier article, I noted:

The real problem was not only validating systems. It was validating influence.

In the XOT environment Rob describes, that principle becomes operational: every newly connected system can become a source of evidence, an authority dependency, or a channel of influence.

Industrial AI is often divided into advisory systems and autonomous systems. The distinction matters, but it can create false comfort.

An advisory system does not need write access to a PLC to change an operational outcome. It can shape the judgment of the engineer, operator, manager, or executive who owns possess authority.

Authority may therefore be weakened or strengthened in route to other influences or actuation. The relevant governance question is not only what AI can execute, but what it is permitted to influence, with what, and why.

This is where human-in-the-loop language also becomes insufficient if it is not defined more precisely.

A person clicking “approve” does not necessarily provide meaningful governance.

  • Did the reviewer have “evidencable confidence” in the underlying evidence?

  • Could the reviewer understand why the recommendation was made when necessary?

  • Did the reviewer have enough information in time to challenge it?

  • Did the reviewer possess the operational authority to reject it?

  • Was the approval recorded?

  • Was the decision calibrated to consequence?

  • Was the person truly exercising judgment, or merely confirming the machine’s momentum?

In engineered environments, humans are not merely inserted into the workflow as an approval checkpoint; they are part of the control and learning system. Human interpretation, analysis, and judgment are required to confirm that digital representations still match physical reality, that recommendations remain operationally sound, and that AI tuning or training is correcting error rather than amplifying it.

Human authority must therefore be preserved across both the operational loop and the AI learning loop. Human judgment is not a checkpoint. It is a control and calibration function.

OT visibility, asset intelligence, exposure management, threat research, and detection remain indispensable.

Without them, organizations cannot understand what exists, what is communicating, which behaviors are abnormal, or where an adversary may be operating.

Visibility provides evidence.

  • Governance determines what that evidence is allowed to influence, who may act on it, and what proof must accompany the decision.

Visibility may show that communication occurred.

  • Operational assurance must determine whether the communication mattered to the process.

Visibility may identify a configuration or process change.

  • Operational assurance must determine whether the change altered a safety assumption, operating envelope, production dependency, or response capability.

Visibility may identify suspicious behavior or conditions.

  • Operational assurance must determine whether the organization can intervene safely and within the available consequence timeline.

Visibility may show that an AI agent accessed operational information.

  • Governance must determine whether the agent was authorized to use that information for the stated purpose, whether the model was appropriate, what it inferred, which recommendation followed, who relied on it, and what downstream outcome it influenced.

These are complementary disciplines.

The more complete XOT visibility becomes, the more valuable it is as an evidence foundation. But that evidence must still be interpreted in the context of engineering reality, operational consequence, authority, and time.

Visibility tells us what the environment revealed.

Governed operational assurance determines what the organization can safely conclude and do about it.

XOT broadens that evidentiary picture by bringing operational telemetry together with engineering configuration, physical and spatial context, identity, maintenance, procedure, and business dependencies. No single evidence source can explain how an industrial operation is actually behaving or where risk, authority, and consequence intersect.

As AI begins to interpret and participate across that broader picture, the assurance problem expands with it. The question is no longer only whether the environment can be seen, but whether AI’s use of that evidence can be bounded, validated against physical and operational reality, subjected to human judgment, and reconstructed afterward.

NexGenomics Axiom is focused on that trust foundation: governing what AI is allowed to interpret, recommend, and influence; preserving human judgment across both the operating and learning loops; and producing the evidence needed to explain how consequential conclusions were reached.

The objective is not another visibility layer. It is to govern the passage from what the environment reveals to what people and AI are bound to conclude, recommend, and do.

One of the most important questions in Rob’s discussion was whether an organization’s security program represents the environment it is actually running or the environment it believes it is running.

That question reaches far beyond asset inventory.

Most organizations have architecture diagrams.

  • Policies.

  • Standards.

  • Control descriptions.

  • Incident playbooks.

  • Responsibility matrices.

  • Approved access paths.

  • Expected operating procedures.

The difficulty is that operational reality drifts.

  • A temporary vendor connection becomes routine.

  • An emergency account becomes a standard workaround.

  • A manual verification step gradually disappears.

  • A cloud application becomes production-critical after the original assessment.

  • A new product feature introduces AI into a workflow without a formal AI initiative.

  • A safety control remains documented but cannot respond within the current process timeline.

  • A maintenance procedure changes while the associated authority and support model does not.

  • A model version changes, but the operating team continues to trust its outputs under the assumptions established for the previous version.

  • A person with critical institutional knowledge leaves, taking an undocumented control with them.

The organization may still see green indicators.

But the indicators may be measuring control existence rather than control effectiveness.

A control can be installed, documented, monitored, and marked compliant while remaining incapable of changing the outcome that matters.

That is why CIE-CORE begins with current-state reality.

The purpose is to establish how systems, tools, teams, decision rights, procedures, and controls actually operate, not simply how the documentation says they should operate. From there, consequence, dependencies, authority, detection, response timing, evidence, and control effectiveness can be evaluated against the real environment.

We cannot govern an aspirational version of the operation.

Industrial organizations are rarely short of plans. The harder problem is whether they will possess the evidence needed to execute those plans, explain the event, and defend the decisions made under pressure.

Rob reduced that challenge to a direct board-level question:

“Would we have the data to answer the questions in the incident?”

That question reaches beyond conventional logging. During a consequential event, the organization must be able to reconstruct the chain connecting operational state, system activity, identity, authority, AI participation, human judgment, control response, and physical outcome.

A plan may describe what should happen. Evidence establishes what did happen, why it happened, and whether the organization’s response remained authorized and safe.

If that evidence must be assembled only after the event, completeness and causal integrity are already uncertain. It must instead be generated continuously as part of normal operation.

That is not simply an audit capability.

It is an operational control.

The progression is now clear. XOT visibility reveals the extended environment. CIE-CORE™ evaluates control effectiveness against consequence. CDPV™ tests whether the evidence and assumptions supporting that conclusion remain true as the operation changes. NexGenomics Axiom governs how AI may use that evidence, and participate in the resulting decisions through the eleven architectural boundaries described earlier.

These are consecutive layers of operational confidence, not competing functions.

Rob repeatedly resisted the language of inevitability. His point was not that defenders face an unstoppable class of adversary. It was that organizations must understand the environment they actually operate and implement the controls that matter to it.

As he put it:

“Defense is doable.”

AI does not change that conclusion.

It increases speed, scale, and complexity, but it also gives defenders new ways to correlate evidence, preserve expertise, investigate conditions, and support decisions. The benefit depends on whether that capability operates inside trustworthy boundaries.

The objective should not be to automate our way out of uncertainty.

It should be to establish operational truth and then use AI to help accountable people reason across it.

Rob offered three questions that belong in every board-level discussion about operational security:

  • Are we seeing the actual operational environment, or only the enterprise environment?

  • What are we doing differently for OT?

  • Would we possess the data required to answer the questions raised by an incident?

AI adds one more:

When a machine-generated conclusion influences the operation, can we prove that it was formed from trusted data, through an appropriate model, under valid authority, and within the bounds established for the consequence?

  • XOT is the correct expansion of the operational-security boundary.

  • Governed influence is the necessary expansion of the control model.

  • Visibility reveals the environment.

  • CIE-CORE™ evaluates what must be protected and whether the controls can change the outcome.

  • CDPV™ tests whether the conditions supporting that conclusion remain true.

  • The NexGenomics architecture governs the complete chain through which AI interprets, recommends, influences, and acts.

That is how we move from observing operational risk to maintaining control of operational reality.

Copyright (C) 2026 by NexGenomics, All rights reserved

No posts

Read the original on edwardjliebig.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.