Sota Sandboxing

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 closed.
5. Make it ephemeral and observable: one sandbox per trust unit, destroyed after; action/egress logs outside the boundary; runtime detection where the platform supports it.
6. Verify from inside: ship a probe (attempt secret reads, metadata access, denied syscalls, egress) and run it in CI. A sandbox is config until tested.

Deliverables: threat classification, boundary choice + rationale, concrete configs (seccomp JSON, securityContext, run flags, broker interface), the inside-the-sandbox verification probe, and the residual-risk list.

AUDIT mode

Use when reviewing existing code/infra for isolation gaps.

Procedure: inventory workloads touching untrusted code/input/tenants → classify each → compare actual boundary vs the floor (rules/01 §3) → walk the relevant rules-file audit checklists → verify empirically where possible (inspect running specs, exec probes, grep for shell=True/--privileged/docker.sock/ automountServiceAccountToken).

Severity conventions

• Critical — untrusted code or fully attacker-reachable parsing with no effective boundary, or a boundary trivially bypassed by present config (--privileged, docker.sock mounted, secrets/metadata reachable from inside, language-jail-only sandbox, agent with full lethal trifecta and no gating).
• High — boundary below the floor for the threat class; a key layer missing or fail-open (no seccomp on untrusted code, root user + writable rootfs, flat network with no policies, shared sandbox across tenants).
• Medium — boundary correct but a defense-in-depth layer absent or weak (default seccomp where custom is warranted, missing pids/memory limits, broad RBAC, no runtime detection, missing -- in argv).
• Low — hygiene/hardening polish (image not pinned by digest, missing RLIMIT_CORE=0, audit-only PSA labels, log gaps).

Finding format

[SEV] <one-line title>
Where: <file:line | resource | runtime evidence>
Threat class: <untrusted code | untrusted input | multi-tenant | agent>
Gap: <which rule (file §rule) is violated and how>
Impact: <what the attacker holds when this is exploited>
Fix: <concrete change — config snippet or pattern reference>

Report findings ordered by severity; end with the boundary-vs-floor table for every workload audited.

Rules index

Top-10 non-negotiables

1. Classify the threat, then meet the boundary floor: untrusted code from the internet gets gVisor at minimum, microVM preferred — never bare runc, never a language-level jail (01).
2. Allowlist, never blocklist, at every layer: syscalls, paths, capabilities, network destinations, tool verbs. Blocklists always leak (01,02).
3. Fail closed: if any sandbox layer cannot be applied, the workload does not run (01).
4. No secrets inside the sandbox: no env keys, dotfiles, cloud metadata, orchestrator credentials; privileged actions go through a broker that returns results, not credentials (04,05).
5. Drop ALL capabilities, no_new_privs, non-root numeric user, read-only rootfs — the baseline four for every container and sandboxed process (02,03).
6. Resource budgets on every sandbox: memory.max (+swap off), pids.max, CPU quota, and a wall-clock kill — quotas throttle, they don't terminate (02,05).
7. Never mount the Docker/CRI socket; never --privileged; never host pid/net/ipc namespaces for anything touching untrusted data (03).
8. Default-deny network egress with explicit FQDN allowlists; metadata endpoint and RFC1918 blocked from untrusted contexts (03,05).
9. Sandbox the parser: attacker-supplied images/PDFs/archives are decoded in a one-shot, fd-only, no-network worker — never in the main process; no shell=True-class subprocess spawning anywhere (04).
10. Ephemeral per trust domain: one sandbox per session/tenant/input, destroyed after; never reused across users; actions logged append-only outside the boundary (01,05).