NanoClaw 联手 Docker 沙箱隔离 AI 智能体

喜欢 OpenClaw 式智能体的概念，但对其安全性感到担忧？NanoClaw 和 Docker Sandboxes 的组合或许正是你需要的。

OpenClaw 虽然备受关注，但其安全性广受诟病。NanoClaw 作为一个开源、注重安全的 AI 智能体运行时，设计为在隔离容器中运行，而非直接部署在主机上。

NanoClaw 定位为 OpenClaw 的极简、生产就绪替代品，代码库更小、更易审计，架构围绕每个智能体的隔离构建。现在，其开发者与 Docker 合作，利用 Docker 新兴的基于 MicroVM 的 Docker Sandboxes 进一步加固安全。

Docker 过去一年将 Docker Sandboxes（一个实验性 Docker Desktop 功能）定位为 AI 编码和任务智能体的安全执行基础。这从简单的容器隔离转向了具有私有 Docker 守护进程的专用 MicroVM。目前，沙箱支持 macOS（Apple Silicon）和 Windows，Linux 支持将在未来几周内推出。

每个沙箱现在运行在自己的轻量级 MicroVM 中，拥有自己的内核和 Docker 引擎。这使得你的智能体可以安装包、构建镜像和运行容器，而无需接触主机 Docker 守护进程或主机文件系统。公司将其宣传为自主智能体的“深度防御”。

因此，即使智能体实现容器逃逸或利用环境中的零日漏洞，损害也仅限于 MicroVM 边界，而非开发者的笔记本电脑或 CI 运行器。这比 OpenClaw 的“安全？什么安全方法？”要安全得多。

这种集成使你可以通过单条命令将基于 NanoClaw 的智能体部署到隔离的沙箱环境中。NanoClaw 针对一类快速增长的 AI 智能体，这些智能体不仅能回答问题，还能连接实时数据、执行代码并代表用户和团队采取行动。

这种扩展范围提高了隔离和爆炸半径控制的风险，因为单个受感染的智能体可能访问共享主机上其他智能体的凭据、会话历史或数据。NanoClaw 加上 Docker Sandboxes 正是为解决这一风险而设计。

据 NanoClaw 创建者 Gavriel Cohen 在博客文章中表示：

当你构建 AI 智能体时，应将其视为不受信任且可能恶意的。正确的方法是采用一种架构，假设智能体会行为不端，并在发生时限制损害。这一原则驱动了 NanoClaw 的每个设计决策。不要将秘密或凭据放在智能体环境中。仅给予智能体执行其工作所需的数据和工具访问权限，不多不少。将所有其他内容保持在硬边界的另一侧。借助 Docker Sandboxes，该边界现在有两层深度。每个智能体运行在自己的容器中（看不到其他智能体的数据），所有容器都运行在 MicroVM 内（无法触及你的主机）。如果模型幻觉或行为不端的智能体能引发安全问题，那么安全模型就是有缺陷的。安全必须在智能体表面之外强制执行，而不是依赖智能体行为正确。

Docker 总裁兼首席运营官 Mark Cavage 在新闻稿中表示：“每个组织都希望让 AI 智能体工作，但障碍是控制：这些智能体可以访问什么、连接哪里以及更改什么。Docker Sandboxes 提供了安全执行层，用于安全运行智能体，而 NanoClaw 展示了当这一基础就位时可能实现什么。”

Cohen 在新闻稿中补充道：“我们正处于一个转变的开端，每个组织的每个团队都将拥有自己的 AI 智能体团队，代表其完成实际工作。NanoClaw 的构建是为了让这成为今天的现实，而 Docker Sandboxes 是让组织真正信任这一现实的关键。”

公司越来越警惕运行能够执行任意代码、安装包或调用云 API 而无需强隔离的智能体。基于 MicroVM 的隔离使用如 Firecracker、Sandboxes 或 Kata Containers 等程序，正成为保护主机免受 AI 生成代码影响的事实标准。在这种方法中，容器仅保留用于受信任的内部自动化。

通过将 Docker 的 MicroVM 沙箱与 NanoClaw 的最小攻击面和可审计的开源代码库结合，两家公司宣传其集成已为企业安全审查做好准备。该堆栈设计为，如果智能体尝试容器逃逸或触发未知漏洞，它仍运行在一次性、MicroVM 支持的沙箱中，可重置而不影响其他工作负载或泄露主机秘密。批评者指出，仅沙箱化不足以确保“智能体安全”。

他们强调需要在其之上进行细粒度的身份验证和授权。Docker 和 NanoClaw 都不会反对这一点，但他们坚持强隔离是任何更高级别安全控制的必要基础。他们没错。

要开始使用 Docker Sandboxes 上的 NanoClaw，开发者可以访问 NanoClaw 的 GitHub 仓库和官方 Docker Sandboxes 文档。