sota-sandboxinglisted

# SOTA Sandboxing & Isolation ## Purpose Engineer and audit isolation boundaries so that compromise of a workload — untrusted code, a parser fed attacker bytes, a tenant, or an AI agent — is contained by design. The skill encodes 2026 state of the art: allowlist-first least privilege, boundary strength matched to threat class, kernel primitives composed correctly, hardened container/microVM deployment, application-level privilege separation, and agent-specific containment (lethal trifecta, egress control, ephemeral execution). Two modes. Pick one explicitly at the start of the task. --- ## BUILD mode Use when designing or implementing isolation for new or changed workloads. 1. **Classify the threat** before any mechanism talk: untrusted CODE, untrusted INPUT, or MULTI-TENANT (`rules/01` §3). State the classification in your output. 2. **Pick the boundary floor** from the decision table in `rules/01`; never go below it silently. If constraints force a weaker boundary, write the risk acceptance into the design. 3. **Enumerate needs first** — files, syscalls, network destinations, CPU/memory/ wall-clock, credentials. The sandbox config is the needs-list, inverted: everything else denied. 4. **Compose layers from the rules files**: kernel primitives (`rules/02`), container/orchestrator hardening (`rules/03`), in-app separation (`rules/04`), agent-specific controls (`rules/05`). Layers must be independent (different failure modes), each failing close