The air gap was an illusion before AI: what changes when models and agents live inside the loop

In June 2025 the Russian security journal itsec.ru published a piece by an adviser at one of the country's largest cryptography vendors: Cyber resilience in the power sector: how to avoid illusions (in Russian). I read it with a feeling that is rare for industry texts: I agreed with almost all of it. Which is exactly why I want to continue it rather than retell it.

The points of the piece, briefly. Absolute isolation of digital systems is an illusion in today's world. Protection has to be designed in, not bolted on. Requirements split into mission critical, where people, the environment and the state are at stake, and business critical, where it is about profit and efficiency. Under the Russian government decree that governs investigation of grid accidents, IT and security specialists are not mandatory members of the investigating commission. The vocabulary is fragmented: cyber immunity, constructive security and cyber resilience live side by side. Large power companies need competence centres of 10 to 15 people at the junction of power engineering, IT and security.

All true. My addition is a single one: artificial intelligence appears in the piece twice, as a hypothetical robot with an eternal battery and as a technology gradually taking over the programmer's job. By 2026 the model and the agent already sit inside the very loop he is writing about. Not in the future but on operating assets: predictive maintenance, set-point optimisation, an agent that raises work orders and prepares set-point changes by procedure. And that changes every point on the list.

Where I agree, and why it is not news

I wrote about the air gap being an illusion in 2012, when I went through Stuxnet: ICS segmentation stopped being optional. Stuxnet entered an isolated network on a USB stick. Since then the list of ways across the gap has only grown: a contractor's laptop, a vendor's maintenance VPN, a 4G modem in the automation cabinet installed for commissioning and forgotten. In 2021 Colonial Pipeline showed that a process network can be stopped without entering it at all: it is enough to take down the corporate side it depends on.

The author's example of a robot that needs no maintenance for a hundred years and is still vulnerable through its interfaces and the people around it illustrates the same thought more elegantly than my notes. An isolated system still lives in a world of people, contractors and removable media. The gap reduces the flow of threats, it does not zero it.

That conclusion was correct for 2025. For 2026 it is incomplete.

What changed: the loop has a participant that makes decisions

Inside the gap, things used to be deterministic. A controller, a SCADA, protective relays. Their behaviour is documented, the logic is known to the engineer, and any deviation is either a fault or an attack. The entire apparatus of industrial security, from segmentation to firmware integrity checks, rests on that assumption: we know how the system is supposed to behave.

A model behaves differently. It has no known behaviour, it has a distribution of answers that depends on the data it was trained on and the data it sees now. An agent built on a model receives a goal and chooses its own tools to reach it. This is a third type of entry into the system. The first two, through the network and through media, the gap at least partly closes. The third, through data and through judgement, crosses the gap legitimately, because the data comes from your own sensors and the judgement forms inside the loop.

Two consequences I consider the main ones.

• The gap protected against code from outside. A model is attacked with data from inside. Poisoning the training set and quietly tampering with telemetry at the input need neither a USB stick nor a VPN. Altered sensor readings look like normal traffic to the perimeter, and the model uses them to make a decision that is destructive for the equipment. I covered this class of attack in AI on the factory floor and a new class of attack; here I will only repeat the conclusion: the line of defence runs through data provenance and anomaly checks before the model, not through antivirus.

• The agent stops being an interface and becomes an actor. While a human operator sat in the loop, an instruction in a contractor's email passed through that person's head. An agent given access to the work-order system or to set-point preparation reads the same email and carries out the instruction if it is phrased as part of the task. That is prompt injection, and for an agent in a process loop it means a path around the gap laid with text rather than code.

Mission critical and business critical: the model crosses the line unnoticed

I like the author's split into two types of requirement, because it gives an owner plain language for a conversation about money. Mission critical is closed fully and without exception; business critical is weighed against the economics.

The problem with AI is that a model crosses that line without changing its name. The typical path looks like this. A set-point optimisation model was installed as business critical: it saves fuel, an engineer looks at its output and decides whether to apply it. A year later the engineer is tired of confirming the same thing, and the output is fed to the set-point directly, with a limiter. A year after that the limiter is widened, because the model "has never been wrong". Formally the system is the same, its register entry carries the same category, but in fact it controls equipment, and its error has become a matter of human safety.

Hence a rule I propose adding to his split: classify the decision path, not the system. Where does the model's output reach, which actions are taken on it automatically, where does a human stand and where does a deterministic safeguard stand that the model cannot override. If the output reaches an actuator, the system is mission critical whatever its passport says. The safeguard lives outside the AI loop, in the controller or the protective relay, and that is exactly where the security by design of his piece and the AI protection of mine meet.

Security by design: what it means for a model

I fully agree that protection bolted on afterwards is expensive and ineffective. For a model the statement has to be translated into specifics, because designing an AI system does not look like designing a SCADA.

Designing a model means choosing the data it learns from and the rules by which that data enters the training set. It means an isolated training environment from which a poisoned set does not slip into production unnoticed. It means integrity control of the trained model, so that the version on site matches the one that was tested. It means a log of prompts and responses from which, six months later, you can reconstruct what the model saw and what it decided.

Here I have good news for the author on the fragmented vocabulary he rightly criticises. For the AI loop the regulator has begun closing it not with terms but with measures. The methodological document FSTEC, Russia's technical security regulator, issued in April 2026 alongside its order 117 contains a dedicated section on protecting information when AI is used: an isolated development environment, integrity control for training data and the model, logging, testing for prompt injection. Formally the document covers state systems, but it set the direction for critical infrastructure. I covered that shift in 187-FZ nine years on, and I will return to the AI section itself separately.

Accident investigation: no security specialist on the commission, no model log on site

There is news here that postdates his piece. Since 1 January 2026 the 2009 decree has been replaced by government decree 1489 of 29 September 2025: the rules now cover incidents as well as accidents, commissions must preserve oscillograms, event recorder files, parameter files and recordings of operator conversations, and electronic materials are kept for at least seven years. But IT and security specialists still did not become mandatory members of the commission, and a cyber attack as a possible cause of an accident is still not mentioned. His point survived the new document intact.

And I would strengthen it. Even if an IT or security specialist is added to the commission, there will be nothing for them to look at unless firmware, configurations and logs at the moment of the accident were captured. The author says as much. With AI in the loop, four more items join the list: the model version, the data set it was trained on, the inputs at the moment of the decision, and the decision itself with its rationale, if the model provides one.

Without these, an accident caused by tampered telemetry looks like "the model made a mistake", and the model's mistake looks like "the operator did not check". The investigation closes on a person, the cause stays in the loop, and six months later it repeats. For agents I described this logic in observability for a swarm of AI agents: the unit of observation shifts from a request to the pair of intention and action, and attempts must be recorded, not only successes. In a process loop that rule becomes a requirement for investigation, not just for operations.

Staffing: the competence centre and what everyone else does

I will not argue with competence centres of 10 to 15 people for large power companies; it is a working model, and the six years of the vendor's cooperation with the national technology centre at the Moscow Power Engineering Institute that the author draws on weigh more than my observations. I will only add what I see from my side of the market.

For an enterprise of three hundred people such a centre is out of reach, in money and in the labour market: there are not enough specialists at the junction of power engineering, IT and security to go round, and the large companies will take them first. Yet such an enterprise has a critical infrastructure object, often a model in the loop too, and the same requirements. The working arrangement I see is one internal risk owner who knows the equipment and the process, plus an external architect with a team for the project, who brings the security and the AI. I will write about that separately; here I only note that the staffing shortage he describes is solved in the mid-sized segment by a structure of responsibility, not by hiring.

Three illusions I would add to his list

The piece is titled "how to avoid illusions", and its list of illusions is accurate. For 2026 I would add three.

1. "A model is just software, security will test it like any application." Code analysis and library vulnerability scanning are needed, but a model's behaviour lives in data, not in code. Testing a model means testing the data set, the training process and the response to corrupted inputs.

2. "The agent follows a procedure, so it is predictable." The agent's procedure is written in natural language and executed by a model that also reads the input data. The procedure can be rewritten by an email if the agent reads email. An agent's predictability comes from restricted permissions and safeguards, not from the text of its instructions.

3. "The model is local, so the gap protects against AI threats too." Locality protects data from leaking out; I wrote about that in local AI. Against poisoning from inside and injection through input data, locality offers no protection at all. These are different threats with different controls.

Honest caveats

• I am not from the power sector. My experience is manufacturing, retail and B2B, and on protective relays, the sector regulator and staffing in power companies the author knows more. My addition concerns AI and data in the loop, where I draw on my own projects.

• AI in process control still advises more often than it controls. Cases where a model's output reaches an actuator with no human in between are rare today. But the drift in that direction follows the path described above, and decision paths need classifying before the limiter is widened for the third time.

• Regulation of AI in critical infrastructure is still forming. The section in the FSTEC methodological document is written for state systems. I expect the approach to carry over to significant critical infrastructure objects, but that is an expectation, not a fact, and too early to budget on.

• There is no dispute with the author here. Everything above extends his text rather than refuting it. If I have misread him anywhere, I will be glad to be corrected.

In short

• The air gap was an illusion before AI: the USB stick, the contractor, the vendor VPN and the dependence on the corporate network always crossed it.
• In 2026 the loop has a participant that makes decisions from data rather than code. Data crosses the gap legitimately, and that is what the model is attacked with.
• For AI, the mission critical versus business critical split must be applied to the decision path, not the system: where the model's output reaches and where the safeguard stands that it cannot override.
• Security by design for a model means data control, isolated training, model integrity and a log of prompts and responses. The regulator has already written these down as measures in the methodology to FSTEC order 117.
• An accident commission needs not only a security specialist but a captured model version, data set, inputs and decisions, or the cause stays in the loop.
• For a mid-sized enterprise the staffing shortage is solved by a structure of responsibility, not by a fifteen-person competence centre.

If a model or an agent already sits on your site and you are not sure where its decision path runs and what stands between it and the equipment, that is exactly the question I start with. Feel free to get in touch; the first conversation commits you to nothing.