# Sandbox for Agentic Application With Cloud Native Stack > [!info] Ported from an existing deep-read (Refactor Appendix present). One claim from this source was already promoted to a Permanent note on 2026-08-08, before this Literature Note existed — see Cross Reference. CNCF/KubeCon talk; a live demo largely failed on stage, which the deep-read treats as its own data point rather than glossing over. > [!question] Lingering Questions > - PVM (the claimed nested-virtualization-free KVM driver) is asserted as "tested in Ant Group's production environment" with no benchmark data shown — worth tracking if Kata Containers 4.0 benchmarks get published separately. > - Has WordPress Playground's WASM-based sandboxing been audited against this talk's lifecycle framework (create/configure/execute/observe/reset/destroy)? Likely already satisfies most of it, but worth an explicit check given the vault's WordPress focus. > - Does the "1.4 second warm start" figure from the failed demo hold up in the production system, or only in the 7-day Codex-assisted demo project built specifically for this talk? > [!tip] Article Ideas > - "Definition before implementation" — the speakers forced themselves to answer "what is a sandbox, really?" before building, which prevented conflating an implementation detail (the pod) with the actual requirement (the lifecycle). A reusable discipline worth its own short piece, generalized past infrastructure. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/A Shared Kernel Is Not a Trust Boundary for Untrusted Agent Code]] — already promoted from this exact source (2026-08-08); covers the VM-vs-container isolation claim > - [[3. Resources/MOCs/AI Agent Safety MOC]] — isolation-boundary-matches-threat-model is a recurring safety thread > [!quote] Vocabulary > - **Kata Containers** — a runtime that gives each container its own guest kernel (VM-level isolation) while preserving the standard container workflow (same images, same Kubernetes, different runtime class) > - **security boundary vs. lifecycle boundary** — the talk's two distinct requirements: preventing data leakage between tenants (security), and being able to stop/clean up a buggy or runaway user program (lifecycle) ## Bibliographic capsule CNCF/KubeCon conference talk, YouTube. A Kata Containers co-founder (Ant Group) and an infrastructure engineer (JAPAN AI) explain why JAPAN AI migrated its multi-tenant AI agent platform from a SaaS sandbox to a self-hosted, VM-isolated sandbox. Category: video, filed under Podcasts. ## Author's thesis (as synthesized) Container-level (shared-kernel) isolation is insufficient for AI agents that run arbitrary, user-supplied, credentialed code across tenants — the correct mental model treats a sandbox as a full lifecycle (create/configure/execute/observe/reset/destroy) requiring its own kernel boundary, and the resulting VM-based approach is worth its acknowledged startup/memory overhead. ## Key arguments (≤3) 1. **A sandbox is a lifecycle, not a pod.** The pod (or VM) is one object within create/configure/execute/observe/reset/destroy, not the definition of the sandbox itself — conflating the two leads to under-designed systems. 2. **Containers share a kernel; untrusted code needs its own.** Namespace/cgroup isolation doesn't satisfy a threat model where the platform genuinely doesn't know what code a tenant's agent will run with real credentials attached. 3. **Overhead should be engineered down, not ignored.** The VM-isolation tradeoff (startup time, memory) is real and stated plainly rather than hidden — an unusually honest note for a vendor-adjacent talk. ## Claim atoms ### A sandbox is a lifecycle, not a pod > [!quote] ID: rw_01kze55ftgg0660ctefn4xrp5m > "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." Where/why: the foundational reframe that drove their architecture — asking "what is a sandbox, really?" before building prevented mistaking an implementation detail for the requirement. ### Definition before implementation Where/why: forcing the definitional question first is presented as the reason the eventual design (VM-based, lifecycle-aware) held together, rather than accreting features onto a pod-shaped assumption. A generalizable discipline for infrastructure design questions. ### A live demo failure is data too Where/why: the demo largely failed on stage; the deep-read treats that failure as more reliable evidence than the slide's claimed capability. The demonstrated "1.4 second warm start" figure should be discounted accordingly — it comes from a 7-day, Codex-assisted personal project built for the presentation, not the production system. ## Permanent candidates - **A Shared Kernel Is Not a Trust Boundary for Untrusted Agent Code** — already promoted from this source (2026-08-08); connected, not duplicated. - **A sandbox is a lifecycle, not a pod** — genuinely uncaptured elsewhere; promoted below. ## Processing checklist - [x] Ported claim atoms from the existing deep-read - [x] Checked existing Permanents before creating new ones — found one already promoted, connected it - [x] Connected into [[3. Resources/MOCs/AI Agent Safety MOC]] ## Links - [[3. Resources/MOCs/AI Agent Safety MOC]] — isolation design for untrusted agent execution - [[3. Resources/Literature Notes/Sandbox for Agentic Application With Cloud Native Stack]] — source transcript/notes