概述
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.
继续学习
相关指南
为此主题精选的更多指南