Sandbox Policy and Runtime Enforcement

Ota derives one provider-neutral policy graph from the complete selected execution closure, then asks a compatible target to apply only controls it can enforce and attest.

• target OS and platform remain part of canonical policy identity
• phase-specific segments preserve different setup, execution, and verification boundaries instead of flattening them
• identified policy overlays may only narrow the contract-owned boundary
• unsupported authoritative controls refuse before selected-lane work begins
• the provider must publish applied-control and cleanup evidence; configuration intent alone is not enforcement

• oci_local applies the supported subset to compatible explicit-platform ephemeral Linux container lanes
• the repository root is mounted read-only with only declared writable carve-outs
• external IP networking can be denied inside the isolated container namespace
• Ota inspects every mount, applied platform truth, and terminal container removal
• cleanup authority exists before provider mutation and survives setup, task, interruption, and partial-start failure
• agent mode selects the enforcing target automatically when authoritative controls require it and only one compatible target exists

ota run verify --agent --sandbox-target oci_local

• managed isolated paths refuse until durable provider resources have transaction-bound lifecycle evidence
• services, requirements, typed prepare/action/Compose/launch/attach bodies, and conditional checks refuse in the first adapter when they would escape the evidenced segment
• image-declared volumes, undeclared mounts, and runtime-control sockets refuse
• targeted egress and destination-constrained outbound policy remain unsupported by stock OCI
• human execution must request an enforcing target explicitly; Ota does not silently relabel ordinary container execution as sandboxed

It does not prove host-wide isolation, application correctness, targeted egress policy, execution outside Ota, or the wider repository.

• the selected policy identity and target platform
• the controls the provider actually applied and Ota inspected
• the exact per-invocation boundary identity
• precondition-probe purpose and cleanup when a provider-backed probe was necessary
• terminal cleanup posture and engine-confirmed removal of Ota's exact boundary
• archive reconciliation against the contract and policy-authority snapshots