官方 AI 沙盒已到来——我为何仍然发布自己的沙盒

Source: Dev.to

Previously

在我之前的文章中，我写到了捕获 Claude Code 静默读取 iOS 项目中的 API 密钥——它甚至不在当前目录，而是在我从未指向的父目录中。没有提示。没有权限。它只是读取了。

这个发现把我带进了一个兔子洞——我最终构建了 AI Sandbox Environment + DockMCP：一个将 AI 隔离在 Docker 容器内的系统，通过卷挂载隐藏机密，并通过 MCP（模型上下文协议）对其他容器提供受控访问。

剩下的就是清理仓库并发布它。或者我这么认为。

就在那时，我在同一领域找到了官方解决方案：

• Docker AI Sandboxes — Docker 的官方 AI 沙盒
• Claude Code Sandboxing — Anthropic 的官方沙箱功能

我的诚实第一反应是 “再也没有发布的意义了。”

如果官方已经覆盖了，为什么还要发布个人项目？于是我没有立刻放弃，而是决定仔细阅读他们实际提供的内容——细致地。

Docker AI 沙盒

• 基于 MicroVM 的隔离
• 在轻量级 VM 中运行 AI 代理
• 完全隔离主机的 Docker 守护进程、容器和文件
• 将工作区目录同步到 VM 中以实现自主工作

这是一种成熟的方案。VM 级别的隔离非常稳固，您可以使用 docker sandbox ls 来管理沙盒。

缺点（截至撰写时）

1. 完整工作区同步 – 目录级别同步，无法排除特定文件。如果您的 .env 或 secrets/ 目录位于工作区内，AI 将能够看到它们。（此功能仍在演进，未来可能会改变。）
2. 无法访问主机侧容器 – 每个沙盒在完全隔离的 VM 中运行自己的 Docker 守护进程。您可以在其中启动测试容器，但它无法访问已经在主机上运行的容器。当您让 AI “检查 API 容器日志” 时，它根本看不到这些日志。

在实际的多容器开发场景——前端、API 和数据库各自运行在独立容器中——这一限制影响很大。

Source: …

Claude Code 沙盒

Claude Code 采用了不同的方法。它不使用容器或虚拟机，而是利用操作系统级别的安全原语（macOS 上的 Seatbelt，Linux 上的 bubblewrap）对进程进行限制。

• 文件系统读写控制 – 阻止在工作目录之外的写入
• 按域名限制的网络访问 – 基于代理
• 已批准的命令自动执行；其他所有操作都需要用户确认

文件访问通过 settings.json 中的拒绝规则进行控制。你可以阻止读取 ~/.ssh/、/etc/ 或特定文件路径。网络隔离尤其强大——代理执行域级访问控制，防止数据泄露到未授权的服务器。沙盒运行时甚至是开源的，这对生态系统非常有利。

缺点

1. 配置错误没有安全网 – 沙盒本身在操作系统层面是稳固的，但哪些文件被隐藏完全取决于拒绝规则是否正确。新增秘密文件却忘记更新拒绝规则时，系统不会给出任何警告。这不是设计缺陷，而是基于规则的方法固有的挑战。
2. 跨容器访问是可能的但不受控制 – 由于 Docker 命令与沙盒不兼容，它们通过 excludedCommands（沙盒保护之外）运行。这意味着 docker exec 和 docker logs 能工作，但它们完全绕过沙盒。无法控制访问哪些容器、允许哪些命令，或日志输出中的秘密是否会被 AI 看到。（Anthropic 可能在未来加入更细粒度的控制。）

三向比较

在隔离方面，三者都有答案。Docker AI Sandboxes 以 VM 级别的分离最为稳健。Claude Code Sandbox 在易用性上胜出。AI Sandbox 基于容器——三者中最弱的，因为容器共享主机内核，无法达到 VM 级别的隔离。

但在隔离之后会发生什么，现有的两个并未多作说明。隔离的 AI 虽然安全，却也无能为力。它看不到 API 日志，无法运行测试，也无法追踪错误。如果结果是“安全但不可用”，人们最终会关闭沙箱。

为什么 AI Sandbox + DockMCP 很重要

AI Sandbox + DockMCP 解决了一个更具体的问题：

“只隐藏机密——可靠地——让 AI 访问其他所有内容。”

• 使用 Docker 卷挂载将 /dev/null 挂载到文件上，文件在物理上根本不存在。
• 使用 tmpfs 挂载一个目录，目录是空的。

与 deny 规则不同，这里没有歧义——不会出现“我写了规则，但路径解析不匹配导致仍可读取”的情况。你挂载的东西就会消失。

当然，如果你忘记在 docker‑compose.yml 中添加某个文件，它仍然会可见。deny 规则也是如此。这就是我构建 自动验证 的原因：它在每次启动时运行，交叉检查 Docker‑compose 卷挂载与 AI 工具的 deny 配置（Claude Code、Gemini Code Assist、Gemini CLI）。如果某个路径在 deny 列表中却缺失于 docker‑compose.yml，就会收到警告。

唯一它捕捉不到的情况是：未在任何地方列出的机密。最初的清单——“需要隐藏的内容”——仍然是人为责任。但一旦清单建立，工具就能捕获其余的风险。

volumes:
  - /dev/null:/workspace/api/.env:ro      # .env 实际不存在
tmpfs:
  - /workspace/api/secrets:ro              # secrets/ 为空

这就是我对沙箱化现状的看法，也正因如此，我仍然认为 AI Sandbox + DockMCP 有值得分享的细分市场。

AI 沙盒 + DockMCP

问题

“让 AI 访问其他容器——并设置防护栏。”

DockMCP 作为 MCP 服务器运行在宿主操作系统上，充当 Docker API 的网关。AI 可以：

• 访问日志
• 运行 白名单 命令
• 检查容器

所有交互都通过 DockMCP。

AI (in container) ──MCP──▶ DockMCP (host) ──Docker API──▶ Other containers
   No Docker socket        Policy enforced            Full access

受控执行

每个容器都有一个允许命令的白名单。列表之外的任何命令都会被拒绝。

exec_whitelist:
  securenote-api:
    - "npm test"
    - "npm run lint"
  securenote-web:
    - "npm run build"

示例： 如果 AI 试图运行 rm -rf /，DockMCP 会阻止它，因为该命令不在白名单中。

文件系统访问也可以受限（例如，/etc/shadow 被阻止）。

安全策略提供三种层级：

秘密掩码

AI 响应中的密码和 API 密钥会使用正则表达式自动掩码。AI 能看到日志，但任何机密信息都会被替换为 ***。

网络控制

默认情况下网络限制 较弱——没有针对 AI 的出站流量过滤。可以通过 Docker 网络设置进行缓解，但域级别的细粒度控制更适合以下方案：

• Claude Code Sandbox（基于代理的方法）
• Docker AI Sandboxes（VM 级别隔离）

为了提升网络安全，Anthropic 官方的防火墙脚本可以集成到 DevContainer 中。详细的设置请参阅 Network Restriction Guide。

为什么重要

现有方案侧重于安全地隔离 AI，这一点至关重要。然而真实的开发往往需要 AI：

• 调试多容器应用
• 运行测试
• 读取日志

在隔离性与可用性之间取得平衡是关键挑战。AI 沙盒 + DockMCP 正好填补了这一空白。它不是官方方案的竞争者，而是补充。如果 Docker AI Sandboxes 引入 DockMCP 风格的控制，或 Claude Code Sandbox 增加卷挂载级别的隐藏，整体防御将更为深度。

面向所有人的模板

该仓库已发布为 GitHub 模板仓库。

1. 点击 “Use this template.”
2. 将 demo-apps/ 替换为你自己的项目。

由于它基于纯 Docker + MCP，能够兼容：

• Claude Code
• Gemini CLI
• 任意 MCP 兼容工具

快速 FAQ

行动号召

如果你在多容器环境中使用 AI，并且需要在文件系统层面处理机密，请尝试本方案并告诉我们缺少了哪些功能。

AI 沙盒环境 + DockMCP 已在 GitHub 上提供：

点击 “Use this template” 将其用于你的项目。

欢迎在 GitHub Discussions 中讨论、提问或分享反馈。