Docker Sandbox：给 AI Agent 造了个金库级的隔离环境，但你真的需要吗？

最近注意到 Docker 有个叫 Sandbox 的功能，专门给 AI Agent 用的隔离环境。去年底（2025 年 11 月）就已经推出了，目前仍处于实验阶段。

一句话：让 Agent 在 microVM 里跑，能干活但碰不到你的系统。最核心的设计是 API Key 不给 Agent - 通过宿主机上的网络代理在请求出去时自动注入凭证。

它解决什么问题

AI Agent 越来越自主 - 能执行命令、装包、跑测试、发网络请求。这些能力在提升效率的同时也带来了风险：如果 Agent 被 prompt injection 骗了呢？如果它执行了 curl 把环境变量里的 API Key 发到外面呢？

Docker Sandbox 的回答是：让 Agent 跑在一个它逃不出去的盒子里。

架构：三层隔离

Sandbox 用的不是普通容器。Docker 的解释很直接 - 容器共享宿主内核，不能安全隔离一个需要自己 Docker daemon 的东西。所以他们选了 microVM：

• 虚拟化层 - macOS 用 virtualization.framework，Windows 用 Hyper-V（实验性）。每个 Sandbox 是一个独立虚拟机，有自己的内核
• 独立 Docker daemon - Agent 在 VM 里有完整的 Docker 环境，但只能看到自己创建的容器，看不到宿主机的
• 网络隔离 - Sandbox 之间不能通信，也访问不了宿主机的 localhost 服务

工作区文件在宿主机和 Sandbox 之间双向同步，路径保持一致。这样 Agent 报的错误路径和你本地看到的是同一个。

核心设计：API Key 代理注入

这是 Sandbox 最有意思的部分。

传统做法是把 OPENAI_API_KEY、ANTHROPIC_API_KEY 这些环境变量传进容器。问题是，一旦传进去，Agent 进程就能读到，恶意代码也能读到。

Sandbox 的做法是：Key 永远不进 VM。宿主机上跑一个 HTTP/HTTPS 代理（host.docker.internal:3128），Agent 的所有出站请求都走这个代理。代理识别到请求目标是 OpenAI、Anthropic、Google、GitHub 等已知服务时，自动注入对应的认证头。

这意味着 Agent 发 API 请求时不带任何凭证 - 它甚至不知道 Key 是什么。即使被 prompt injection 骗了执行 env 或 curl 泄密，拿到的也是空的。

为了做到这点，代理对 HTTPS 连接做了中间人解密（MITM） - 终止 TLS，注入凭证，再用自己的 CA 证书重新加密。

网络策略

除了凭证注入，代理还支持域名级的访问控制。两种模式：

• Allow 模式 - 默认放行，黑名单拦截
• Deny 模式 - 默认拦截，白名单放行

按最小权限原则，Deny 模式更安全 - 只开放 Agent 工作需要的域名。

但有几个已知限制需要注意：

• 只过滤 HTTP/HTTPS，其他协议直接阻断
• 不检查流量内容，只看目标域名
• 存在 domain fronting 绕过的可能 - 通过允许的域名路由流量到其他目标
• 私有网段（10.0.0.0/8 等）和 localhost 默认封锁

支持的 Agent：白名单机制

需要注意的是，Docker Sandbox 不是"任何 Agent 都能直接扔进去跑"。它采用白名单机制 - Docker 为每个支持的 Agent 做了专门的模板，模板里预装了运行环境和代理配置。

目前已支持或开发中的 Agent：

• Claude Code - 生产可用
• Codex、Copilot、Gemini、OpenCode、cagent、Kiro - 开发中
• Shell - 最小化手动配置，跑任何工具

启动很简单：

docker sandbox run claude ~/my-project

不在列表里的 Agent 想用，可以走 Shell 模式 - 给你一个裸的隔离 VM，自己装 Agent、自己配代理。microVM 隔离本身对任何进程都有效，但凭证代理注入的便利性只对已适配的 Agent 有效。这是 Docker Sandbox 最大的价值点，也是最大的限制。

你真的需要它吗

这要看你的使用场景。

不太需要的情况 - 如果你是单人本地开发，Agent 的 prompt 都是自己写的，跑的都是自己的代码。这种情况下你完全信任 Agent 的输入源，Sandbox 等于给自家厨房装银行金库的门。额外的 VM 开销、同步延迟、调试复杂度不一定值得。

真正有价值的场景：

• 跑第三方插件/Skill - 你不知道别人写的 Skill 里有没有恶意代码。Sandbox 把爆炸半径限制在 VM 里
• 部署到公网 VPS - Agent 暴露在互联网上，prompt injection 的风险不是理论上的
• 团队共享 - 多人共用一套 Agent 环境，但不想互相暴露 API Key
• 合规要求 - 某些场景下隔离执行环境是硬性要求

本质上，Docker Sandbox 解决的是 信任边界 问题。当你不完全信任 Agent 的输入、代码或运行环境时，它提供了一层可靠的隔离。当你完全信任这些东西时，它就是额外的复杂度。

和其他方案的对比

市面上不只 Docker 一家在做 Agent 沙箱。gVisor、Firecracker、各种 WebAssembly 沙箱都有类似定位。Docker Sandbox 的优势在于两点：一是它直接集成在 Docker Desktop 里，不需要额外装东西；二是凭证代理注入这个设计，把"Agent 拿不到 Key"做成了默认行为而不是可选配置。

对于已经在用 Docker 的开发者来说，试一下的成本很低。对于在评估 Agent 安全方案的团队来说，Docker Sandbox 的架构设计值得参考 - 即使最终不用它，"把凭证留在信任域内、通过代理注入"这个思路在任何方案里都适用。