Watching Is Not Stopping

If we are serious about letting AI help run nuclear plants and power grids, observability is not a safety plan. The control that matters happens before the action, not after it. Runtime authorization for AI-assisted decision systems in nuclear and renewable energy critical infrastructure Here is the uncomfortable version. We are moving AI into the control rooms of nuclear facilities and the dispatch systems of power grids, and the dominant plan for keeping it safe is to watch it. Log the inputs. Flag the anomalies. Route the alerts to a human. That is not a safety plan. That is a recording of the damage.

Monitoring tells you what an AI system did. It tells you nothing about what it was allowed to do. In an enterprise app, that gap is an inconvenience. A misrouted email, a bad recommendation, a dashboard nobody reads. In a reactor, or on a grid that is already running tight on reserve, that gap is the window in which something irreversible happens. Detection after execution does not prevent execution. By the time the alert fires, the action is already in the physical world.

So the real question is not the one the industry keeps asking. It is not only whether the model is accurate. A model can be accurate on average and still propose an action that is impermissible right now, in this plant, under these constraints, by this operator. The question that decides safety is narrower and harder: is this specific action permitted to execute, at this moment, under the constraints that actually govern the system? That is action eligibility, and almost nothing in the current AI assurance stack answers it.

If we are going to be serious, the conversation has to move from observability to authorization.

What authorization actually means

Runtime authorization is a control layer that sits between an AI recommendation and the machinery that acts on it. Before anything executes, it asks whether the proposed action is permitted under the operative constraints. If it cannot establish that, it fails closed. The action does not run.

It returns one of three verdicts, and only three. ALLOW: the action is permitted, with any conditions recorded against it. DENY: the action violates a constraint and is stopped at the boundary. ABSTAIN: eligibility cannot be established, so execution is blocked pending an authorized human override, and that override is itself logged, attributed, and constrained. Ambiguity does not quietly become permission. It becomes a stop.

And every verdict leaves an artifact. Not a log written after the fact, but a contemporaneous, tamper-evident record that says what was proposed, what constraints were checked, what the system state was, who held the authority, and what was decided, all captured at the moment of decision. A log records that something happened. An authorization artifact records that something was permitted before it happened, against named constraints, on named evidence, by named authority. That is the entire difference between reconstructing an accident and preventing one.

A control you can route around is not a control

Here is the part that gets quietly skipped in most architectures, and it is the part that matters most.

An authorization boundary only works if the machinery downstream refuses to act on anything that does not carry a valid verdict. Every request that reaches actuation, including the ones coming from a trusted operator console, a legacy interface, a vendor side channel, or a convenient shortcut someone added under deadline, has to be rejected if it has no artifact. The moment one path can skip the boundary, the boundary is decoration. The system keeps the exact risk it was built to remove.

Non-bypassability is not a feature you bolt onto the authorization layer. It is a property of how authorization and actuation are wired together. A control you can route around is not a control. It is a suggestion with good branding.

What this looks like in a plant

An AI maintenance system recommends deferring an inspection on a cooling-system component. The analysis may be sound. The authorization layer does not argue with the analysis. It checks the action against the regulatory interval, the current operating state, the component's degradation history, and the authority of the person asking. Constraint violated, the verdict is DENY. Evidence incomplete or the rule ambiguous in this operating mode, the verdict is ABSTAIN. The recommendation does not get to execute on the strength of being clever.

A dispatch optimizer proposes a generation profile that is the cheapest option on the board. The authorization layer checks it against reserve margin, instantaneous frequency, ramp limits, interconnection terms, and operator authority. Cheapest and impermissible, it is rejected at the boundary, no matter how good the cost number looks. Economic optimality is a property of the recommendation. Permissibility is decided separately, and permissibility wins.

And in a degraded state, when sensors are failing and the situation is outside anything the model trained on, the discipline tightens rather than loosens. The default moves toward ABSTAIN. The worst time to let an AI act on a guess is the moment the guess is least reliable.

None of the tools we already bought solve this

It is tempting to assume something on the existing security or AI stack already covers this. It does not. Identity and access management decides who can reach a system, not whether a given AI action is eligible to fire. Observability and monitoring describe behavior after it occurs. Policy engines express what should happen, and expression is not enforcement at the point of action. Runtime application protection guards software against exploitation, not the operational permissibility of an AI-generated instruction. Each does real work. None of them is the execution-time eligibility decision plus the evidence that it was made. That is what runtime authorization is, and it is the category FERZ has been building and naming across its research corpus.

Serious cuts both ways

Demanding authorization is not the same as pretending an authorization layer is infallible. It is not. A serious version has to survive its own failure modes: stale context that no longer matches the plant, a regulatory rule mistranslated into the wrong threshold, override privileges handed out too freely, latency that tempts operators into working around it, and integration shortcuts that quietly reopen a bypass. Naming those honestly is not a weakness in the argument. It is the price of being serious instead of selling something. An architecture that does not account for them is not ready for a control room.

But none of that is a reason to keep treating monitoring as governance. It is a reason to do authorization properly.

The bottom line

If AI is going to touch critical infrastructure, the burden has to shift. An AI recommendation should not become an operational action until something has determined, at execution time, that the action is permitted under the constraints in force, and has captured that determination as evidence that can be checked later by someone who was not in the room. Anything short of that is watching. And watching is not stopping.

Read the full paper: Authorization Architectures for AI-Driven Critical Infrastructure, accepted for presentation at NURER 2026 and published in the FERZ research corpus.

Citation: Meyman, E. (2026). Authorization Architectures for AI-Driven Critical Infrastructure: Runtime Authorization for AI-Assisted Decision Systems in Nuclear and Renewable Energy Environments. Version 1.0. FERZ Research Corpus. Zenodo. https://doi.org/10.5281/zenodo.20292737

By Edward Meyman, Founder, FERZ, Inc.