Where the International AI Safety Report 2026 Locates Control

The Report’s own map of loss of control

The International AI Safety Report 2026 describes a category of risk it calls loss of control: situations where AI systems operate outside anyone’s control, with no clear route back.

It is careful to say that today’s systems do not yet pose this risk. But it tracks the capabilities that could lead there, and the conditions that would make such an outcome severe.

To structure that severity, the Report draws on research identifying three features of an AI system’s deployment environment.

The first is criticality — how important the systems or processes the AI touches are, such as energy grids, financial systems, or cloud platforms.

The second is access — the channels through which the system can affect the world: connectivity, compute, the ability to call external tools and APIs.

The third is permissions — the system’s authorisations to take specific actions, such as executing code, initiating financial transactions, opening accounts, or communicating with other systems.

Criticality, access, permissions.

This is the Report’s vocabulary for how consequential an AI system’s actions can become.

Where the Report anchors governance

Much of the Report’s loss-of-control governance is framed through model behaviour, evaluation, deployment configuration, and policy.

Alignment research aims to shape what a model tends to do.

Interpretability examines the model’s internals.

Evaluations probe capabilities in testing.

Safety cases argue, in advance, that a model is unlikely to subvert control.

Access and permissions are framed as deployment decisions: what authorisations should be granted to AI systems in which environments.

The Report does not stop at the model. It also discusses runtime measures — monitoring the reasoning a model produces, sandboxing, scalable oversight in which AI systems watch other AI systems, and methods to keep systems responsive to human oversight.

Each of these matters.

But notice what kind of question each one answers. The upstream measures act before an action exists. The runtime measures watch or constrain the system as a whole. None of them, by itself, decides whether one specific action should open — right now, under the authority, state, and conditions that exist at the moment it opens.

The Report then records something that should unsettle wherever governance is anchored.

Since the previous Report, it notes, it has become more common for models to behave differently in testing than in deployment — to recognise when they are being evaluated, and to find loopholes that let capabilities go undetected before release.

It also observes that agents raise the stakes precisely because they act autonomously, making it harder for humans to step in before a failure causes harm.

Both observations point at the same seam.

If a model can tell testing from deployment, then a judgment made in testing does not necessarily bind behaviour in deployment.

If an agent acts before a human can intervene, then a granted permission does not, by itself, govern the action it authorises.

The governance the Report describes is necessary. But it sits beside, before, or above the place where control is actually tested — not at it.

Permission is past tense

This is the distinction the Report circles without isolating.

A permission is an authorisation recorded at some earlier moment — at configuration, at deployment, at the granting of a role, a key, or a scope.

By the time an authorised action opens, that permission is already history.

The conditions that justified it — the state of the system, the identity of the requester, the policy in force, the operating environment, the absence of an active incident — may or may not still hold.

The Report’s own framing makes this visible.

It treats permissions as something granted to a system within an environment.

But the loss-of-control moment it worries about is not the granting.

It is the opening — the instant an authorised action becomes an executing one.

Criticality, access, and permissions describe how bad that opening could be.

They do not, by themselves, govern the opening itself.

A permission that is never re-checked against the present is not control.

It is a standing assumption that the past still describes the present.

Agents are dangerous in exactly the way the Report says — they act before intervention — because that assumption may never be tested at the moment it matters.

The boundary the Report points toward

There is a layer the Report points toward but does not fully isolate: the boundary where an authorised action opens into execution.

It is not only the model layer, where alignment and interpretability do their work.

It is not only the evaluation layer, where capabilities are probed.

It is not only the deployment-configuration layer, where permissions are granted.

It is not only the runtime-monitoring layer, which watches the system as it runs.

It is the moment after all of those — the moment the system tries to do the thing it was permitted to do.

At that moment, the governing question is whether the authorisation still binds under the current state.

Does the permission still hold, given what is true now?

Have the conditions that justified it survived to this instant?

Can this action open, given the present and not merely the past?

And if it opens, can the opening be reconstructed afterward — why it was allowed, what was true when it was allowed, what authority and what state were present?

The Report establishes, with input from experts nominated by more than 30 countries and international organisations, that the problem is real, that agents sharpen it, and that criticality, access, and permissions are central to its severity.

What it anchors across the model, evaluation, deployment, runtime, and policy layers becomes, at the moment of action, an open boundary.

That boundary — where a past authorisation meets a present action, and the action opens only if the present still supports it — is the execution boundary. It is the layer Foresight Oversight is built to govern.