8.0
热点
AI SCORE
技术实践2026-08-29 23:41
AI沙箱不止一层：Claude Code Sandbox与自建隔离方案对比
dev.to · AI#AI安全#沙箱#开源
Editor brief · 编辑速览
作者开源AI沙箱项目，详解各层隔离机制差异——OS级microVM、容器隔离、文件系统读写拦截——以及AI厂商自带沙箱的防护边界。
我维护了一个开源的 AI 沙箱项目，每次跟做产品和解决方案的人提起它，有时候会得到这样的反应：
"AI 厂商不是已经自带沙箱了吗？难道你不信任它？"
我愣了一秒。不是我不信任，而是 AI 厂商自己的沙箱（如 Claude Code Sandbox）所保护的层次，和我的项目所保护的层次，根本就是不同的事情。
一旦你开始研究如何安全地运行 AI 编程智能体，就会不断遇到一些名字极易混淆的工具：Claude Code Sandbox、Docker AI Sandboxes、Docker MCP Toolkit、firejail、gVisor、Firecracker……它们看起来都在指向同一个方向——"隔离 AI 智能体"——但它们实际保护的是什么、怎么工作的，差异远超你的想象。这篇文章就是我尝试真正把这个问题回答清楚的一次尝试。
简短回答：它们保护的是不同的层次
先来看对比表。
关键不是"哪个最强"，而是每个工具针对的是不同的威胁模型。逐一来看。
Claude Code Sandbox 使用操作系统层原语（macOS 上的 Seatbelt，Linux 上的 Bubblewrap）来限制文件系统写入和网络访问。在权限设置中添加读取拒绝规则，还可以阻止 AI 读取特定文件。
它的优势很明显：在 macOS 上实现了零配置的操作系统级执行限制（Linux/WSL2 需要安装 bubblewrap 和 socat）。同时减少了权限确认的摩擦。
不过有两个空白没有被覆盖。
第一，拒绝规则是一种应用层机制。它依赖正确配置，同时也依赖 AI 工具实际遵守这条规则。更糟的是，这些拒绝规则不会遍历父目录。在 monorepo 或多项目工作区里，一个项目的配置无法保护兄弟项目中的密钥。
AI Sandbox 在文件层面完全绕过了这个问题。每个项目的密钥文件通过卷挂载单独对 AI 的文件系统隐藏，不受目录层级影响。根本不存在需要遍历的规则——核心理念是，规则本就不应该存在。
第二，与 Docker 命令存在摩擦。Docker 命令需要直接访问 Docker socket，这在结构上与沙箱机制不兼容。事实上，Claude Code Sandbox 自己的故障排除文档建议把 docker * 加入 excludedCommands（即将其排除在沙箱之外）。结果：Docker 操作以完全不受限制的主机权限运行，完全在沙箱保护之外。
在 Linux 上，firejail 经常出现在对比中。它使用 Linux 命名空间在进程层面进行沙箱化——与 Claude Code Sandbox 使用的 bubblewrap 属于同一类别。与本项目将 AI 智能体的整个执行环境独立出来的做法不同，firejail 旨在嵌套在一个更大的沙箱内部。
不过在"隐藏密钥"这个窄化问题上，情况就不同了。firejail 的 --blacklist 选项在操作系统内核层面拒绝访问目标路径。根据 firejail 官方文档，黑名单中的文件/目录"在文件系统中仍然可见，但完全无法访问"。我无法从公开文档中确认底层实现是否基于绑定挂载，但从它不依赖 AI 工具遵守规则这一点来看，它在精神上更接近 AI Sandbox 的卷挂载方式，而不是应用层拒绝规则（不过面向 AI 的呈现形式可能不同——AI Sandbox 显示空文件/目录，这可能与 firejail 的呈现方式不完全一致）。
不过 firejail 局限于单个进程，没有被设计成将整个多项目工作区视为一个单元来对待，也不覆盖对其他容器的受控访问。它仅限 Linux，所以无法在 macOS 上使用——而 macOS 正是 AI Sandbox 的主要目标平台。在特定的 Linux 开发机器上，仅靠 --blacklist 本身可能已经能实现密钥隐藏，但它覆盖不了其余部分。
Docker AI Sandboxes 在一个隔离的微虚拟机中运行 AI 智能体，智能体拥有自己的 Docker daemon。它完全无法触碰主机系统。
优势：基于微虚拟机的强隔离、沙箱内 AI 智能体的完全自主权、每个沙箱拥有自己的 Docker daemon。
有两个空白。它将整个工作区目录同步到微虚拟机中，没有排除特定文件的机制——所以 .env 文件在里面一览无余。这与其说是缺陷，不如说是设计目标的差异：Docker AI Sandboxes 的存在是为了"保护主机免受 AI 智能体执行的影响"，而不是"对 AI 隐藏密钥"。另一个空白：由于是完全隔离的，沙箱无法与其他容器通信，这就排除了跨容器调试。
Docker MCP Toolkit 提供 200+ 个容器化的 MCP 服务器，内置隔离和密钥管理。其优势在于丰富的预构建 MCP 服务器目录以及 MCP 服务器配置的内置密钥管理。
但这个工具专注于隔离 MCP 服务器——对 AI 隐藏项目级密钥不在其范围内。它不处理源码树中的 .env 文件或私钥。
综合以上对比，AI Sandbox + HostMCP 可以被概括为填补了两个特定的空白。
不是通过规则（可能被错误配置或绕过）来阻止访问密钥，而是用 Docker 卷挂载从物理上把密钥从 AI 的文件系统中移除。
volumes:
- /dev/null:/workspace/my-app/.env:ro # 对 AI 显示为空文件
tmpfs:
- /workspace/my-app/secrets # 对 AI 显示为空目录
密钥在 AI 的世界里根本不存在。不是被规则阻止，不是被配置过滤——就是不在那里。而应用容器照常挂载真实文件。
作为防止错误配置的安全措施，沙箱在启动时运行一项验证检查，确认 AI 工具的拒绝规则与 docker-compose.yml 中的卷挂载保持同步。如果密钥文件只配置了一侧，在 AI 能访问它之前就会发出警告。另有一项独立检查每次 AI 会话启动时扫描 docker-compose.yml 中未隐藏的疑似密钥文件。这能及早发现开发过程中创建的文件的配置空白，AI 本身会询问用户如何处理被标记的文件——是否真的需要隐藏，还是可以保留原样。
HostMCP 作为 AI Sandbox 与 Docker 容器之间的网关，执行安全策略。AI 可以读取日志、运行白名单命令、检查容器——但无法访问被阻止的路径或运行任意命令。启动/停止容器默认禁用，只有在配置中明确启用后才能工作。敏感数据（密码、API 密钥、令牌）在输出中自动被遮蔽，HostMCP 本身默认只绑定到回环地址（127.0.0.1），开箱即用状态下无法从网络上的其他机器访问。
到目前为止一直用"对比"的角度来讲，但实际上这些工具分属两个不同性质的层次，这样理解才能弄清楚各自的定位。
Docker AI Sandboxes 和 AI Sandbox 都在回答"在你 AI 智能体整个执行环境周围画一条什么线？"这个问题。前者用微虚拟机；后者用容器加上基于卷挂载的密钥移除。由于角色有重叠，它们不是要叠加使用——而是根据威胁模型二选一。
Claude Code Sandbox 针对的是不同的东西——只在操作系统层面限制 Bash 命令执行——所以可以嵌套在你选择的任何外层环境内部。不过，当嵌套在 AI Sandbox 这样的非特权容器内部时，bubblewrap 可能无法挂载一个全新的 /proc（据官方文档），需要启用 enableWeakerNestedSandbox——在这种情况下，嵌套沙箱的进程空间隔离最终取决于外层容器边界（权限拒绝规则本身不受影响，继续正常工作）。所以"嵌套在 AI Sandbox 内部就能获得最大保护"这种说法并不准确——有额外收益，但有限。
如果你好奇这些边界与管理型云 AI 服务使用的内核级隔离技术（gVisor、Firecracker）有什么关系，以及本地是否值得采用，我会在第二部分讲到——那超出了 AI Sandbox 本身的范畴，所以我把它拆出来，以保持这篇文章的主题集中。
HostMCP 的跨容器访问控制和 Managed Settings 的拒绝规则与隔离边界属于不同层次。它们在单个工具调用的层面控制访问，所以可以独立地叠加在你上面选择的任何隔离边界之上。
"如何隔离 AI 智能体？"没有唯一正确答案。Claude Code Sandbox 限制命令执行，Docker AI Sandboxes 在微虚拟机中隔离一切，gVisor/Firecracker 在云端生产环境中用作更强的隔离技术。每个保护的是不同的层次，针对的是不同的威胁模型。
AI Sandbox + HostMCP 选择专注的方向是：在文件系统层面物理擦除密钥，以及在审批流程后面安全地桥接跨容器访问。它专门为填补这两个空白而构建，设计初衷是加成性的——不与其他隔离边界或上面的权限层竞争。
安全的 AI 驱动开发需要两者兼顾：保护密钥，同时不妨碍真正在工作的人和 AI。AI Sandbox 试图同时把握住这两端。
如果你曾经看着自己的开发环境想过"等等，AI 是不是也在读我的私钥？"——去看看这个仓库。