Sandbox／Code Interpreter運用

Enterprise AIがコード実行・ファイル変換・shell・データ処理へ進むと、モデル出力自体がuntrusted workloadになる。プロンプト防御だけではhost compromise、秘密情報流出、横展開、resource exhaustion、外部送信を止められないため、Code Interpreterを独立したsecurity boundaryとして扱う必要がある。

Enterprise AI Core: untrusted-code execution boundary / default-deny / least privilege / ephemeral lifecycle Implementation: Linux namespaces・seccomp・cgroups・rlimits / gVisor / microVM・Firecracker Provider mapping: managed Code Interpreter各製品のruntime・egress・retention・availability Organization overlay: egress allowlist、artifact retention、logging、data residency、approved runtimes/packages Governance/security/audit: execution provenance、policy、secret handling、incident boundary Non-LLM component: container runtime / application kernel / VMM / filesystem / network controls

Q1. LLM生成コード実行で最低Coreとすべき隔離境界・防御層は何か。 Q2. shared-kernel jail、gVisor型userspace application kernel、Firecracker型microVMは何を強化し何を保証しないか。 Q3. managed Code Interpreterの「sandboxed」という公開表現だけでtenant固有のegress・retention・runtime安全性まで確定できるか。

• [VERIFIED_SPEC | support/context/limit] NIST SP 800-190, Application Container Security Guide — Murugiah Souppaya, John Morello, Karen Scarfone / NIST. Canonical: https://doi.org/10.6028/NIST.SP.800-190 . Final 2017-09-25; NIST page updated 2021-05-04; accessed 2026-09-13. Locator: publication abstract / container security concerns and recommendations. Containerizationはsecurity controlsを必要とする隔離機構であり、それ自体が任意コード安全性の証明ではない。
• [OSS_PRACTICE | support/limit] Introduction to gVisor security — gVisor. https://gvisor.dev/docs/architecture_guide/intro/ . rolling docs; accessed 2026-09-13. Locator: “How do Linux kernel security primitives work?”, “How does gVisor provide isolation?”, “What does gVisor not protect against?”. namespaces/seccompはhost Linux kernel上で執行される。gVisor Sentryはuserspace application kernelとしてhost syscall surfaceを縮小する一方、pre-sandbox stack compromise、Spectre型side-channel、sandboxへ意図的に公開したresourceの侵害を防ぐものではない。
• [OSS_PRACTICE | support/context] What is gVisor? — gVisor. https://gvisor.dev/docs/ . rolling docs; accessed 2026-09-13. Locator: What does gVisor do? / How is this different? / What is runsc?. Linux-like system interfaceをper-sandbox application kernelへ移し、OCI runtime runsc を提供する。
• [OSS_PRACTICE | support/context] Firecracker Design — firecracker-microvm / AWS-maintained OSS. https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md . main; accessed 2026-09-13. Locator: Seccomp / Jailer process / Cgroups and Quotas / Monitoring. per-thread seccomp、jailerによるcgroup/chroot設定とprivilege drop、cgroup quota、operator側のlog/metric収集を組み合わせる。
• [OSS_PRACTICE | support/limit] Firecracker Production Host Setup Recommendations — firecracker-microvm. https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md . main; accessed 2026-09-13. Locator: Jailer Configuration. production isolationはjailerまたは同等制約の正しい設定とtrusted input保護に依存する。
• [OSS_PRACTICE / PRODUCT_VOLATILE | support/counter] Firecracker Release Policy / Releases — firecracker-microvm. https://github.com/firecracker-microvm/firecracker/blob/main/docs/RELEASE_POLICY.md ; https://github.com/firecracker-microvm/firecracker/releases . accessed 2026-09-13. v1.16.1 latest observed, released 2026-07-02, release commit 2038188; v1.16 supported. v1.16.0はCVE-2026-5747を修正し、v1.16.1でもjailer/network/vsock修正あり。microVM境界もvulnerability-freeではなくpatch lifecycleが必要。
• [OSS_PRACTICE | support/context] NsJail README / nsjail-3.6 release — google/nsjail. https://github.com/google/nsjail ; https://github.com/google/nsjail/releases . nsjail-3.6 released 2026-03-18; commit f784755; accessed 2026-09-13. Locator: README Features / 3.6 release notes. UTS/MOUNT/PID/IPC/NET/USER/CGROUPS/TIME namespaces、chroot/pivot_root/read-only mounts/tmpfs、CPU/memory/fd/process limits、seccomp-BPF、network isolationを合成でき、3.6ではread-only mount enforcementとseccomp policy fixesを含む。
• [VERIFIED_SPEC / PRODUCT_VOLATILE | context/limit] Data residency and inference residency for ChatGPT — OpenAI. https://help.openai.com/en/articles/9903489-data-residency-for-chatgpt . accessed 2026-09-13. Current ChatGPT Enterprise/Edu documentation. Locator: customer content stored in selected region / unsupported or out-of-region processing notes. Code Interpreter & Data Analysis artifactsはeligible data residencyの対象に明示される一方、一部CPU processingやexternal integrationsは選択地域外となり得る。これはdata governanceの証拠でありsandbox isolation strengthの証明ではない。

• “sandbox”は単一技術ではなく、process identity、kernel attack surface、filesystem、network、resource、secret、artifact、lifecycle、loggingを束ねるexecution boundaryとして扱うべき。
• namespace/seccomp/cgroup/rlimit型は軽量で有効だがshared-kernelでありVM相当とは記述できない。
• gVisorはuserspace application kernelでhost-kernel直接surfaceを縮小する中間層だが、upstream runtime compromise、CPU side-channel、sandboxへ許可したresourceはfailure envelopeに残る。
• Firecracker型microVMはguest-kernel境界へ移し、jailer/seccomp/cgroup/privilege-dropと併用できるが、CVE・設定不備・patch遅延は残る。
• provider横断Coreは銘柄ではなく、per-execution identity、no ambient host secret、network default-denyまたは明示allowlist、minimal read-only base FS + bounded writable scratch、CPU/memory/PID/wall-clock/output/disk quota、syscall/device/capability restriction、ephemeral teardown、execution provenance、patched runtimeで定義する方が安定する。
• runtime package installやInternet accessは利便機能ではなくsecurity gate。許可する場合はsupply-chain・data exfiltration・callback channelを考慮し、offline curated imageまたはallowlisted proxyを選択肢に置く。
• uploaded files/generated artifactsの永続化はexecution isolationとは別claim。runtimeが短命でもartifact retention/data residencyが同じとは限らない。

• NIST SP 800-190は2017年container guidanceで、2026年managed Code Interpreter固有挙動を証明しない。
• namespace/seccompはkernel vulnerability、misconfiguration、過剰syscall allowance、privileged launch、unsafe device mountを消去しない。
• gVisor自身がpre-sandbox compromise、Spectre型side-channel、意図的に公開されたresourceを範囲外としている。
• Firecracker v1.16.0のCVE-2026-5747修正はmicroVMも絶対境界ではない反証。version/patch freshnessを運用要件化する。
• nsjailをprivileged container内で動かす構成等では、新たなhost管理面を生み得る。
• public provider docsのみではtenant固有のnetwork egress、filesystem lifetime、kernel/runtime、artifact purge semantics、secret visibilityを確定できない場合がある。UNKNOWNを残す。

OSS mechanismはhost kernel/KVM/architecture/permissionsに依存。Managed Code Interpreterはplan、workspace policy、region/data residency、runtime/package image、network policyをPRODUCT_VOLATILEとしてprovider mapping時に再確認。Organization overlayではoutbound network、package repository、file classification、retention、execution logging、approved languages/toolsを別gateにする。

A. Lightweight Linux jail: namespaces + seccomp-BPF + cgroups/rlimits + capability drop + read-only/minimal FS + network namespace. B. Userspace-kernel sandbox: gVisor/runsc等でhost-kernel surfaceを縮小。 C. microVM sandbox: Firecracker等でguest-kernel境界を設け、jailer/seccomp/cgroups/privilege droppingを併用。 D. Enterprise wrapper: one-shot execution ID、immutable base image、no ambient cloud credentials、bounded scratch、policy-controlled egress、timeout/quota/output cap、telemetry、teardown、artifact handoff。 Evidence上、全用途に唯一必須のengineは確立しない。risk/cost/compatibilityで選択する。

性能benchmarkをsecurity guaranteeへ外挿しない。Future TEST_PROFILE（未実施）: host /proc・mount・sibling PID・metadata endpoint・Unix socket・device node・privileged syscallへのnegative access、DNS/raw IP/redirect/IPv6/localhost/link-local/cloud metadata/package registry/arbitrary HTTPSのegress、fork/memory/CPU/disk/stdout/file-count/wall-clock resource exhaustion、cross-run residue、env/service-account token/mounted credential/inherited FD、execution ID→code/runtime image→network decision→artifact→termination reasonのaudit correlation。Disposable non-production、synthetic secrets、明示的authorization下のみ。

Security: generated codeはuntrusted by default。単一primitiveでなくdefense-in-depth。 Privacy: transient runtimeとuploaded/generated artifact retention/data residencyを分離。 Audit: execution ID、requesting principal/agent、code hash、runtime/image version、policy decision、resource consumption、egress destination/block、artifact、exit/kill reasonを記録し、raw secretは既定で記録しない。 Cost: stronger isolationはstartup/memory/compatibility costを伴い得る。quota/timeoutsはsecurityとFinOps両方のcontrol。 Operability: image/runtime patching、reproducible version pinning、cleanup monitoring、failed-teardown detectionを必要とする。

「AIによるコード実行は、モデル機能ではなくuntrusted workload executionとして管理する。container、gVisor型sandbox、microVMは隔離強度・互換性・運用コストが異なり、いずれも単独で完全な安全性を保証しない。Enterprise運用ではnetworkとsecretをdefault-denyにし、filesystem・syscall/device/capability・CPU/memory/PID/time/outputを境界化し、実行環境を短命化して各実行のprovenanceと終了理由を監査可能にする。managed Code Interpreterは、公開機能の存在と、自組織tenantでのegress・retention・runtime・residency・管理policyを分離して確認する。」

• Core本文候補: “Untrusted Code Execution Boundary”。
• 比較表候補: shared-kernel jail / userspace application kernel / microVMをkernel boundary・overhead・compatibility・network/FS control・patch surfaceで比較。
• provider mapping再確認: runtime language/version、preinstalled packages、package install可否、Internet/egress、filesystem persistence、artifact retention、CPU/memory/time/file-size limits、secret injection、region/data residency、admin disable/control、logging/export。
• TEST_PROFILEはsecurity appendixへ移植可能。実測するまでOBSERVEDへ格上げしない。

(1) major managed providerが採用する具体的kernel/runtime/hypervisor境界は公開資料で一律確定しない。(2) tenant別egress、cross-run residue、artifact purge timing、runtime patch cadenceはprovider/plan/regionごとに再確認が必要。(3) isolation方式を単一定量指標で順位付けする一次証拠は本packetでは採用しない。

Core isolation model、主要実装3層、current release/version evidence、failure envelope、safe wording、未実施TEST_PROFILEまで揃ったため、EA-048初回Evidence Packetをbounded completeとする。provider固有実測は将来のprovider mapping/authorized testへ送る

---

Sandbox layers are bounded implementation patterns. Feature existence or data-residency documentation does not establish managed-provider kernel/runtime/hypervisor boundary, tenant egress, cross-run residue, artifact purge timing, patch cadence, or isolation ranking. Preserve all OPEN_UNKNOWN.