# A Sandbox Is a Lifecycle Not a Pod ## Claim A sandbox is the full create-configure-execute-observe-reset-destroy cycle, not the runtime object (pod, VM, container) that happens to implement one stage of it. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when designing any system that runs untrusted or semi-trusted code on behalf of a user and needs to reason about the whole lifecycle, not just execution. - Mistaking the object for the concept tends to under-design the stages nobody thinks about first — reset and destroy get skipped because "the pod" already feels like the deliverable once execution works. - Doesn't prescribe which object should implement the lifecycle (container, VM, WASM runtime) — that choice is a separate decision made against the threat model, not against this framing. ## Evidence JAPAN AI's team explicitly forced the question "what is a sandbox, really?" before building, rather than starting from their existing SaaS sandbox's pod-shaped assumptions. Naming the six lifecycle stages separately from the implementation object is what let them later swap the underlying isolation mechanism (SaaS sandbox → Kata Containers VM isolation) while keeping the same lifecycle contract and running both backends in parallel during migration. > "We always consider the sandbox is a pod, but it's not true. The pod is just the object in this life cycle. We should consider sandbox with a life cycle." ## Links - [[3. Resources/Permanent Notes/A Shared Kernel Is Not a Trust Boundary for Untrusted Agent Code]] — extends; that note is the isolation-mechanism decision this note's lifecycle frame sits above — this note is definitional, that one is about which object satisfies the definition under a specific threat model - [[3. Resources/MOCs/AI Agent Safety MOC]] — applies-in; any platform running untrusted or agent-driven code benefits from separating "what a sandbox must do" from "what currently implements it" ## Tests / falsifiers - Audit a sandboxing system that was designed around a concrete object (e.g., "the sandbox is a container") for whether reset and destroy were afterthoughts compared to a system designed lifecycle-first — if there's no measurable design-quality difference, the framing's practical value is weaker than claimed. - If WordPress Playground's WASM-based sandboxing already satisfies this lifecycle framework without ever having named it explicitly, that's evidence the discipline is more about avoiding a specific failure mode (premature object-lock-in) than a universally necessary design step. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/Sandbox for Agentic Application With Cloud Native Stack]] — Xu Wang (Ant Group) & Yu Hu (JAPAN AI), CNCF/KubeCon talk