How to Use Autonomous AI in Critical Infrastructure Without Giving It Control of the Plant

Giving a system access to operational information is not the same as giving it control of equipment.

Those two ideas get blurred together constantly, in vendor material and in the objections raised against it, and they should not be. A maintenance system can read an alarm, examine a historian trend, retrieve the correct manual revision and help a team diagnose a pump without being permitted to change a controller, start a motor or open a valve.

The security architecture has to make that distinction explicit and structural, not implicit and configurable. This guide sets out how to evaluate whether it does, whether the system in question is ours or somebody else’s.

Start with three questions, not one

The usual security conversation collapses into a single question: is it secure. That question cannot be answered, because it does not specify against what.

Three questions can be answered, and they should be asked separately because they have separate answers and separate controls.

1. What can the system see?
2. What can the system decide or recommend?
3. What is the system actually allowed to do?

Most evaluations spend their time on the first, occasionally reach the second, and rarely get to the third, which is the one that matters. Access is a confidentiality question. Authority is a safety question. In critical infrastructure the second is larger.

1. What can the system see

For maintenance work, the useful evidence is a defined and fairly short list: alarm and event context, historian trends, the asset record, manuals and drawings, work history, inventory, and supplier records.

Three properties determine whether reading them is safe.

Direction. Whether the connection to operational technology can carry a write at all. This is the difference between a read-only integration and an integration with writes turned off. The first is a property of the architecture; the second is a setting, and a setting can be changed by whoever holds administrative access, including somebody who is not supposed to have it.

EQUA AIMMS treats SCADA and historian context as read only. There is no write path to a PLC, DCS or SCADA system, and no capability to issue setpoints, restarts, interlocks or actuator commands. That is not an autonomy level or a configuration option. It is absent from the system.

Mediation. Whether the connection is brokered, monitored and controlled, or direct. This is the same principle the FBI and EPA emphasised after the July 2026 attacks on internet-facing water-sector controllers: remove inbound exposure and put a mediated, monitored path in front of anything that reaches an operational device.

Scope and retention. Which specific sources, which tags, which sites, for how long, and who can change that list. A boundary that nobody can enumerate is not a boundary.

2. What the system can decide or recommend

Reasoning is where AI systems add most of their value in maintenance, and where the honest description differs most from the marketing one.

A maintenance system can usefully propose likely causes, suggest the next inspection or check, retrieve applicable guidance, identify the part that matches the installed configuration, surface supplier options, and draft the work and purchase records that a person will act on.

Three properties determine whether that reasoning is trustworthy in an operational setting.

Traceability. Every claim names the record it came from and how old that record is. A value presented without its source and its age invites a decision it cannot support. At 2 a.m. the difference between a reading from twenty minutes ago and one from last Thursday is the whole answer.

Declared uncertainty. The system says what it is not sure about, in the same place it says what it concluded. Confidence that is not calibrated is worse than no confidence.

Visible absence. When a source is unreachable or stale, that is shown as unreachable or stale. Missing evidence is never filled in from somewhere plausible. This is the single most important property in the list, and the one most systems fail, because a gap silently filled with a reasonable-looking value is indistinguishable from information until somebody acts on it.

And a boundary that belongs here rather than in the authority section: qualified people diagnose. Likely causes are proposed for a person to accept or reject. Nothing is concluded on a technician’s behalf, and no diagnosis is asserted as fact.

3. What the system is allowed to do

This is the section to read first if you are evaluating a vendor.

Actions are not one category. Read, create, send, reserve, request, approve, purchase and write back to a system of record are eight different privileges with eight different consequences, and each needs separately defined authority. A vendor who describes all of them as “the AI handles it” has not thought about the problem, or is hoping you will not.

FIG. 1

Authority is enumerated per action class, not granted as a level

Authority by action class in EQUA AIMMS

Action	AIMMS may prepare	Authority held by
Read permitted maintenance evidence	Assembles it, with the source and age of every line	Your data owners define the scope
Propose likely causes	Ranks them, with the evidence for each	Your technician or engineer accepts or rejects
Identify and reserve a part	Reconciles the part against the installed configuration, prepares the reservation	Your storeroom or planner
Request supplier quotes	Prepares the requests, tracks the responses	Your purchasing function
Commit spend, raise an order	Assembles the comparison a buyer can act on	Your buyer, under your limits
Approve work	Routes the complete case with the evidence attached	Your named approver. A denied gate stays denied
Write back to CMMS, EAM or ERP	Prepares the record	You, and only after that integration is built, tested and approved
Authorise return to service	Assembles the return evidence your procedure requires	Your personnel
Write to a PLC, DCS or SCADA system	Nothing. Out of scope.	Plant operations, through their own control systems
Issue a setpoint, restart, interlock or actuator command	Nothing. Out of scope.	Plant operations, through their own control systems

Figure 1. Authority is enumerated per action class, not granted as a level. A table of action classes. For each, what AIMMS may prepare and who holds the authority. Read permitted maintenance evidence: assembles it with source and age attached; authority held by the customer's data owners who define the scope. Propose likely causes: ranks them with the evidence for each; authority held by the qualified technician or engineer who accepts or rejects. Identify and reserve a part: reconciles part against installed configuration and prepares the reservation; authority held by the storeroom or planner. Request supplier quotes: prepares requests and tracks responses; authority held by the customer's purchasing function. Commit spend or raise a purchase order: assembles the comparison; authority held by the customer's buyer under the customer's limits. Approve work: routes the complete case with evidence attached; authority held by the customer's named approver, where a denied gate stays denied. Write back to CMMS, EAM or ERP: prepares the record; authority held by the customer, and only after that specific integration is built, tested and approved. Authorise return to service: assembles the return evidence; authority held by the customer's personnel. Two final rows are marked out of scope entirely: write to a PLC, DCS or SCADA system, and issue a setpoint, restart, interlock or actuator command. For both, AIMMS prepares nothing, because both are out of scope, and the authority sits with plant operations through their own control systems.

Two things about that table are worth stating plainly.

The customer defines autonomy. Which rows run without a person, and which stop and wait, is set by the customer’s own roles, thresholds and approval rules. It is not a product default we impose, and it is not a fixed setting where every action requires a signature. Both of those are wrong for different reasons: the first ignores that a municipal utility and a merchant generator have genuinely different governance, and the second describes a system nobody would use.

A denied gate stays denied. This sounds obvious and is the most common quiet failure in workflow automation. A system that retries, escalates around, or re-presents a denied decision until it gets a different answer has converted a control into an obstacle.

The boundary, drawn

FIG. 2

See is not the same as control

Figure 2. See is not the same as control. Three stacked zones. The top zone is plant control, drawn as a boundary, containing PLC, SCADA control, historian and process equipment. A one-way downward connector labelled read only, mediated and monitored leads to the second zone, reasoning, containing AIMMS with evidence, likely causes and repair guidance. A second downward connector labelled enumerated authority and customer approval leads to the third zone, permitted action, containing CMMS, inventory, suppliers, approvals and procurement. Below all three, a struck-through dashed line marks the path that does not exist: no return path from action back to plant control.

Identity, before protocols

A stolen password should not be enough to operate a privileged account in a system that can commit spend and route approvals against critical assets.

That is the requirement. The protocol conversation follows from it rather than leading it.

There are two defensible shapes for this, and a vendor should support both. Where the customer federates, the customer identity provider stays authoritative: the system honours their single sign-on and MFA policy, including phishing-resistant FIDO2 and WebAuthn hardware security keys, and enforcement and deprovisioning stay with the customer. Where an account is not federated, the system itself has to enroll, verify, recover, and audit those credentials. Ask which shape you are being offered, because a vendor that only inherits enforcement has no answer for accounts outside your tenant, and one that only issues its own credentials has quietly built a second identity system beside yours.

Beyond authentication, three things determine whether identity is actually a control:

Roles that mirror the customer’s own. Approval authority in the system should map to approval authority in the organisation. Where it does not, the system has quietly created a second, undocumented governance structure.

Enumerable standing access. Who currently holds privileged access, granted when, by whom, and reviewed when. If the answer requires a database query rather than a report, access review is not happening.

Attributable actions. Every action records the actor, the timestamp, the evidence it used, the decision, the approval state and the resulting status. This is what makes an incident reconstructable and an evidence review answerable, and it is the practical difference between a system you can defend and one you can only vouch for.

Encryption, and the post-quantum question

Encryption in transit and at rest is table stakes and not interesting. The question that has become live in the last year is what happens to data intercepted today and decrypted later, once a cryptographically relevant quantum computer exists. For operational records with a long useful life, that is a real consideration rather than a theoretical one.

The standards position is now settled enough to act on. NIST finalised FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism standard known as ML-KEM, in August 2024, alongside FIPS 204 and FIPS 205 for digital signatures. NIST followed with SP 800-227, recommendations for key-encapsulation mechanisms, finalised in September 2025.

The policy position moved in 2026. Executive Order 14412, issued on 22 June 2026, requires federal agencies to migrate their most sensitive systems to post-quantum cryptography for key establishment by 31 December 2030 and for digital signatures by 31 December 2031, and directs the Federal Acquisition Regulatory Council to propose a rule requiring covered federal contractors to comply with NIST standards including the post-quantum algorithms.

For a utility, the practical implication is that post-quantum readiness is moving from a research topic to a procurement question, and the vendors in your supply chain will be asked about it.

AIMMS uses the NIST-standardised ML-KEM algorithm for quantum-resistant key establishment on protected communication paths at the API gateway, and its cryptographic architecture is designed to be algorithm-agile, so the algorithms in use can change as standards and customer requirements evolve.

What that does not mean is worth stating as clearly as what it does. It does not remove cryptographic or implementation risk, and no absolute assurance should be accepted from anybody. Key establishment is one part of a cryptographic system, algorithm agility is a design property rather than a guarantee, and the migration is an ongoing programme across the whole industry rather than a completed state.

Eleven questions to ask any vendor, including us

1. Can your system write to a PLC, DCS or SCADA system under any configuration? If the answer is “not by default”, ask what changes the default.
2. Is your operational-technology connection read only architecturally, or is it a bidirectional connection with writes disabled?
3. Show me the enumerated list of action classes and who holds authority for each.
4. What happens when a source is unreachable or the data is stale? Show me the screen.
5. What happens to a denied approval? Does anything retry, escalate or re-present it?
6. Which specific sources and tags are in scope, and who can change that list?
7. Does every action record the actor, timestamp, evidence used, decision, approval state and result? Show me one.
8. Does the customer identity provider remain authoritative, and can its SSO and MFA policy include phishing-resistant FIDO2 and WebAuthn hardware security keys for all users where configured?
9. What is written back to my systems of record, and what has to happen before that is switched on?
10. Where does my data reside, for how long, and what happens to it if we stop?
11. What is your position on post-quantum key establishment, and can you name the algorithm and the standard?

If a vendor cannot answer question 3 with a table, the rest of the answers are not load-bearing.

Where this leaves the operator

The July 2026 attacks on water-sector controllers made a point that had been made before and not widely heard: equipment that performs physical work should not be reachable by anything that does not need to reach it, and the list of things that need to reach it is shorter than most plants assume.

Maintenance intelligence does not belong on that list. Understanding a fault, preparing a repair, verifying a part, coordinating a supplier and routing an approval are all achievable from evidence, with no ability to change plant behaviour whatsoever. A system that asks for control in order to deliver maintenance value is asking for something it does not need.

The correct shape is the one in Figure 2, and the correct way to verify it is Figure 1. Ask for the table.

Sources

• National Institute of Standards and Technology, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, issued alongside FIPS 204 and FIPS 205, effective 14 August 2024.
• National Institute of Standards and Technology, Migration to Post-Quantum Cryptography, National Cybersecurity Center of Excellence, ongoing; SP 800-227, Recommendations for Key-Encapsulation Mechanisms, finalised September 2025.
• Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, 22 June 2026, as summarised by DigiCert and Skadden. Deadlines cited: post-quantum key establishment for the most sensitive federal systems by 31 December 2030, digital signatures by 31 December 2031.
• Federal Bureau of Investigation and Environmental Protection Agency, Public Service Announcement I-073026-PSA, 30 July 2026, on removing inbound exposure to operational-technology devices and mediating access through a secure gateway.