Containment is not authorization

The position

A sandbox, a network perimeter, a credential scope, or a resource policy bounds where a system can reach: within its scope and while it holds, effects outside the perimeter do not occur and prohibited operations are rejected. That contributes to Output Integrity by blocking effect paths. It leaves open whether each released consequential action within the scope is authorized under the applicable policy and delegated authority, whether every execution path to a governed effect enforces a pre-execution determination, whether the origin of each verdict-grounding input is established, and whether any verdict can be independently reconstructed.

Containment falls short of authorization in two ways. The perimeter may be executed around: a path is found or made, and an effect occurs outside the confined region. A control that can be executed around is not an authorization boundary. Or the perimeter holds and authority is still exceeded: the action stays inside the sandbox and goes beyond what was delegated to the agent for the task. Even where the perimeter records that an operation passed its reachability restrictions, that record does not, by itself, establish a pre-execution authorization verdict under the applicable policy and authority.

At a perimeter, authorization requires what it requires elsewhere. Execution depends on a valid action-bound ALLOW verdict under the applicable policy and authority. DENY and ABSTAIN block execution. An authorized human resolution of an ABSTAIN supplies authority-bound input that the boundary must materially consume before emitting its own resulting action-bound verdict. Execution may resume only on a boundary-emitted ALLOW represented in an authorization artifact. A failed evaluation or absent verdict leaves execution blocked. The verdict is recorded in a tamper-evident authorization artifact that an independent party can reconstruct under a declared replay mode. Containment supports non-bypassability by restricting execution paths and keeping effects within the declared scope, and its resource and operation policies can be part of the enforcement architecture. It does not by itself establish that the action released through those controls is authorized.

Counter-positions

“The agent cannot leave the sandbox, so nothing it does can cause harm.” Reach and authority are different limits. The sandbox bounds the first; the second is set by what was delegated to the agent for this task, and an action can respect every reachability constraint and still exceed it. Deleting a file the agent can reach, sending a message the credential permits, or modifying a record inside the perimeter is permitted or prohibited by policy and authority, not by the wall. A record that an operation passed the perimeter's reachability restrictions does not, by itself, establish a pre-execution authorization verdict.

“The container's resource policy is the authorization policy.” A resource policy may evaluate identity, operations, resource attributes, and contextual conditions. It may also participate in an action-specific authorization decision. The question is whether the deployed arrangement makes every covered release depend on a valid pre-execution authorization verdict under the applicable policy and authority, represented in an authorization artifact sufficient for independent reconstruction. A policy that merely limits reachable operations does not establish those conditions. A resource policy may help satisfy them when incorporated into a runtime authorization boundary.