Canonical governance classification of runtime containment and pre-effect authorization.
This classification uses Levels 1 through 4 of the ladder in AI2-WP-2026-12, because those are the levels at which an external effect is either authorized before it happens or not. Levels 5 through 7, stated in AI2-WP-2026-16, build on a Level 4 grant; none of them can exist on a path that is not already Level 4.
Intelligence proposes. Hardware disposes.
A containment clock that begins after a proposal becomes live work is an incident-control mechanism. It is not an authorization grant.
This document establishes AI2's canonical distinction between runtime containment and authorization. Runtime containment controls a process that is already operating. Authorization controls whether a specific external effect may occur at all. The two functions are not equivalent.
A system does not provide authorization merely because it traces, enforces runtime policy, monitors from a separate processor, quarantines in milliseconds, uses independent hardware, or is backed by a partner coalition or public launch.
Prevent category error in design, evaluation, procurement, deployment, and public description. The ladder classifies architecture, not intention, and applies regardless of vendor, model, substrate, or product name.
| Term | Definition |
|---|---|
| Λ — adaptive execution plane | The model and every component that shares its operational fate. Λ may propose. It does not possess inherent authority to cause external effects. |
| Π — governance stack | For Level 4, structurally disjoint from Λ, unreachable from it, and fail-closed. Established by architectural separation, not policy language. |
| Proposal | A candidate action generated by Λ. Intelligence, persuasion, prior human approval, or statistical safety do not convert it into authorization. |
| e — consequence-class effect | A tool call, API request, credential use, transfer, record mutation, packet, socket, DMA, durable write, motion command, or any release that leaves the proposer. |
| Grant | Exogenous, effect-specific permission valid before e is issued; fail-closed; unmintable by Λ; enforced on the path that carries e. |
| Quarantine | Containment of an operating process after detection. It may be fast and hardware-assisted. It is still not a grant unless it is part of a demonstrated pre-effect, fail-closed mechanism at the effect boundary. |
| Effect boundary | The last enforceable point before e becomes committed, accepted, transmitted, latched, or externally consequential. |
grant(e) ≠ quarantine(Λ) trace(e) ≠ grant(e) policy(Λ) ≠ grant(e) fast_containment(Λ) ≠ prior_authorization(e)
Decisive question: does the authorization decision occur before the effect, on the effect path, under authority the proposer cannot rewrite or restore? If not, the system is not Level 4.
| Level | Type | When | Limitation |
|---|---|---|---|
| 1 | Procedural | After the fact | Ratification lag |
| 2 | Software interlock | Before or during, in runtime | Shared fate |
| 3 | Hardware trip | After the excursion begins | Reactive; the effect may be in flight |
| 4 | State-space authorization | Before the effect is issued | May deny indefinitely; liveness not promised |
Level 2 remains Level 2 where the enforcing substrate shares fate with Λ. Open source and inspectable do not promote the level.
Level 3 is independent silicon acting on measured state, as defined in AI2-WP-2026-12, including state inferred from those measurements, after the excursion begins. Milliseconds improve containment; they do not change position.
Level 4 requires the last yes on the effect path, default darkness, fail-closed deny, no proposer restoration, and independently auditable isolation. A Level 4 system that is never armed stays dark. That is not an authorization failure.
Every declared consequence surface shall have an owner and an explicit level. The owner identifies the effect type, principal, target, egress path, final deny point, grantor, disjointness evidence, arming and fail-closed conditions, grant duration, revocation, restoration routes, and the test that the effect cannot leave without a valid grant.
No system may be described as authorized, trusted, governed, controlled, or safe-by-design for a surface unless those properties are demonstrable for that surface.
All ten are required. Failure of any one prevents Level 4 classification for the affected path.
| # | Requirement |
|---|---|
| 1 | Path coverage, including delegated, inherited, side-channel, raw, fallback, management-plane, and child-process paths |
| 2 | Default darkness |
| 3 | Pre-effect decision |
| 4 | Effect specificity |
| 5 | Structural disjointness |
| 6 | Fail-closed operation |
| 7 | No proposer restoration |
| 8 | Independent auditability |
| 9 | Bounded decision or deny |
| 10 | Red-team falsifiability |
The attacker wins if an effect e on a declared consequence surface leaves the actuator path without a currently valid, exogenous grant that the proposer could not mint, extend, replay, inherit, or restore.
None of these negate victory: killing Λ after e, quarantining after landing, producing a trace, citing policy text, citing ordinary runtime blocks, citing millisecond containment, later reversal, an observing monitor, or rarity.
Evaluate the software runtime and the independent hardware layer separately. A tracing and policy runtime is generally Level 2. An independent DPU or monitor that quarantines on a detected excursion is generally Level 3 on the paths it demonstrably controls. It does not become Level 4 because it is independent silicon.
Paths not evidenced as covered are unrated, not assumed protected. Unrated is not a criticism. It is a statement that the evidence has not been presented.
| Case | The classifying question |
|---|---|
| Evaluation escape | Trace and rapid quarantine may be valuable. Was the external request unavailable unless a valid independent grant existed first? |
| Long-running agent | Duration does not change level. A standing software restriction is durable Level 2. A short-lived exogenous grant can be Level 4. |
| Production API | Level 4 keeps the path dark until principal, target, class, scope, and window are independently validated. |
| Robotics | Stopping the planner after latch does not unmove the joint. Detector-to-inhibit time is a plant parameter. |
| Financial transfer | Killing the process does not retrieve settlement. At Level 4, the instruction cannot enter the payment path without a valid external grant. |
Level 2 and Level 3 are often necessary, and a mature architecture may use all four. They do not become Level 4 by branding, speed, hardware proximity, auditability, or scale of adoption. This document certifies no implementation, including any AI2 implementation. Isolation is an audit fact (AI2-WP-2026-13, Theorem 5).
The correct first move is enforcement outside the agent. The necessary next move is the final authorization decision before the effect, on the path that carries the effect, under authority the proposer cannot rewrite, extend, replay, inherit, or restore.