概述
It matters because an agent that can execute code is far more capable (it can compute, analyze files and test its own work), but model-written code is untrusted by default and can be buggy, wasteful or manipulated by prompt injection.
深入探討
When an agent generates code, something has to run it. Running that code directly on a developer laptop or production server is risky: the code could delete files, read credentials from environment variables, install software, mine cryptocurrency, or open network connections. A sandbox puts a boundary between the code and everything else. There are several layers of isolation, with different trade-offs. Standard containers (for example Docker) use Linux namespaces and cgroups to give code its own view of processes, files and network, and to limit CPU and memory. They start quickly, but every container shares the host's kernel, so a kernel vulnerability can let code escape. gVisor, an open-source project from Google, adds a user-space kernel that intercepts system calls, shrinking what untrusted code can touch on the real kernel. MicroVMs such as Firecracker, originally built by AWS for Lambda and Fargate, give each workload its own lightweight virtual machine and kernel while still booting in a fraction of a second. Hosted sandbox services for agents, such as E2B, build on this microVM approach. At the lightest end, WebAssembly runtimes and tools like Pyodide can run Python in a browser or Wasm sandbox with no direct system access. Isolation technology is only half of the design. Good sandboxes also restrict the network (often deny-by-default with an allowlist), mount the filesystem read-only except for a scratch directory, keep secrets out of the environment entirely, and enforce time, memory, process-count and disk limits. They are usually ephemeral: created per task and destroyed afterward. A common misconception is that a sandbox makes an agent safe. It limits damage from the code itself, but it does not stop an agent from producing wrong answers, and any tool or credential you pass into the sandbox becomes reachable by whatever code runs there, including code written in response to injected instructions.
戰略影響
成本與預算
多年來，架構決策決定著效能和營運成本。
更明確的決策
技術教育幫助團隊選擇正確的堆疊，而不僅僅是最新的堆疊。
品質管控
更好的工程選擇可以減少生產中的可靠性事故。
The Future of Code Execution Sandboxes for Agents
Code execution is becoming a standard capability for AI assistants and agents, so sandboxing is likely to become more of a commodity service with sensible defaults rather than something each team builds from scratch. Expect continued work on faster startup, snapshot and resume, and finer-grained policies for network and file access that can be adjusted per task. The harder open problem is policy rather than isolation: deciding what an agent should be allowed to reach, and keeping users informed, when agents take longer autonomous actions. Isolation will remain one layer among several, alongside permissions, logging and human review.
現實世界的實施
A data-analysis assistant receives an uploaded CSV, writes pandas code to clean it and plot trends, and runs that code in a disposable sandbox that is deleted when the session ends.
A coding agent runs a repository's test suite inside a container with no outbound network access, so a malicious dependency script cannot send source code or secrets to an outside server.
An education platform lets students ask an AI tutor to run Python examples, with each run capped at a few seconds of CPU and a fixed memory limit so an accidental infinite loop cannot stall the service.
A research team gives an agent a microVM with a read-only copy of a dataset and a single writable output folder, so the agent can produce results without modifying or deleting the original data.
風險與防護欄
優化一項基準測試可以隱藏更廣泛的系統弱點。
基礎設施和維護成本常常被低估。
隨著系統變得更加複雜，安全性和可觀察性差距可能會擴大。
實施路線圖
在實施之前定義延遲、品質和成本目標。
在實際負載和資料條件下進行基準測試。
儀器監控錯誤、漂移和使用者影響。
在擴展之前準備回滾和事件回應路徑。
不斷探索
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the Code Execution Sandboxes for Agents quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
常見問題
What is Code Execution Sandboxes for Agents?
A code execution sandbox is an isolated environment where an AI agent can run the code it writes without being able to harm the host machine, reach data it should not see, or use unlimited resources. It matters because an agent that can execute code is far more capable (it can compute, analyze files and test its own work), but model-written code is untrusted by default and can be buggy, wasteful or manipulated by prompt injection.
Why is code written by an AI agent treated as untrusted by default?
The guide explains that model-written code may contain bugs, consume excess resources, or follow injected instructions, so it should run inside a boundary rather than directly on a host.
What is the main security weakness of standard containers compared with microVMs?
Containers use namespaces and cgroups but all share the host kernel, so a kernel vulnerability can allow an escape. MicroVMs give each workload its own kernel.
What does gVisor add to reduce risk from untrusted code?
gVisor, from Google, runs a user-space kernel that handles system calls, reducing how much of the real host kernel untrusted code can reach.
Firecracker microVMs were originally built by AWS to power which kind of services?
Firecracker was created for AWS serverless workloads such as Lambda and Fargate, where many isolated workloads must start quickly.
Why is restricting outbound network access often considered the most important sandbox control when prompt injection is possible?
If injected instructions cause the agent to write malicious code, a deny-by-default network stops that code from exfiltrating data.
繼續學習
相關指南
為此主題精選的更多指南