不要信任 AI 代理
2026年2月28日 · Gavriel Cohen
在使用 AI 代理进行开发时，应该将它们视为不可信且可能具有恶意的。无论你担心的是 prompt injection、模型试图逃离沙箱，还是某些尚未被发现的威胁——无论你的威胁模型是什么，你都不应该信任代理。正确的做法不是更好的权限检查或更智能的 allowlist，而是一种假设代理会行为不端、并在发生时控制损害范围的架构。
这就是我构建 NanoClaw 的原则。
不要信任进程
OpenClaw 默认直接在宿主机上运行。它有一个可选的 Docker 沙箱模式，但默认是关闭的，大多数用户从不启用。没有沙箱时，安全完全依赖于应用层检查：allowlist、确认提示、一组”安全”命令。这些检查建立在一种隐性信任之上——假设代理不会试图做坏事。一旦你接受了代理可能具有恶意这一思维方式，就很明显应用层的阻断措施是不够的。它们无法提供密封的安全保障。一个有决心的或被入侵的代理能找到绕过它们的方法。
在 NanoClaw 中，容器隔离是架构的核心组成部分。每个代理都在自己的容器中运行，使用 Docker 或 macOS 上的 Apple Container。容器是临时的——每次调用时全新创建，结束后即销毁。代理以非特权用户身份运行，只能看到被显式挂载进来的目录。容器边界由操作系统强制执行。
不要信任其他代理
即使启用了 OpenClaw 的沙箱，所有代理仍然共享同一个容器。你可能有一个代理作为个人助手，另一个用于工作，分别在不同的 WhatsApp 群组或 Telegram 频道中。它们都在同一个环境中，这意味着信息可能会在本应访问不同数据的代理之间泄露。
代理之间不应该比你信任它们更多地互相信任。在 NanoClaw 中，每个代理都有自己的容器、文件系统和 Claude 会话历史。你的个人助手无法看到工作代理的数据，因为它们运行在完全独立的沙箱中。
容器边界是硬安全层——无论配置如何，代理都无法突破它。在此基础上，~/.config/nanoclaw/mount-allowlist.json 中的挂载 allowlist 作为额外的纵深防御层：它的存在是为了防止用户意外挂载不应暴露的内容，而不是为了防止代理突破。敏感路径（.ssh、.gnupg、.aws、.env、private_key、credentials）默认被屏蔽。allowlist 位于项目目录之外，因此被入侵的代理无法修改自身权限。宿主应用代码以只读方式挂载，所以代理的任何操作在容器销毁后都不会留存。
群组中的人也不应被信任。非主群组默认被视为不可信。其他群组及其中的人员无法向其他聊天发送消息、为其他群组安排任务或查看其他群组的数据。群组中的任何人都可能发送 prompt injection，安全模型对此有充分考量。
不要信任你无法阅读的代码
OpenClaw 有近 50 万行代码、53 个配置文件和超过 70 个依赖项。这违反了开源安全的基本前提。Chromium 有超过 3500 万行代码，但你信任 Google 的审查流程。大多数开源项目的运作方式恰恰相反：它们保持足够小，以便众多审阅者能够真正审查它们。没有人审查过 OpenClaw 的 40 万行代码。它在几周内编写完成，没有经过正式的审查流程。复杂性正是漏洞藏身之处，Microsoft 的分析证实了这一点：OpenClaw 的风险可能通过正常的 API 调用显现，因为没有任何一个人能够看到全貌。
NanoClaw 是一个进程和少量文件。我们大量依赖 Anthropic 的 Claude Agent SDK——Claude Code 的封装层——来处理会话管理、内存压缩等诸多功能，而不是重新造轮子。一个有经验的开发者可以在一个下午审查完整个代码库。这是刻意的约束，而非局限。我们的贡献指南只接受错误修复、安全修复和简化改进。
新功能通过技能（skills）引入：包含完整可运行参考实现的指令，由编程代理合并到你的代码库中。你可以在代码被纳入之前精确审查将要添加的内容。而且你只添加实际需要的集成。每个安装最终只有几千行根据所有者具体需求定制的代码。
这才是真正的区别。面对一个 40 万行的单体代码库，即使你只启用两个集成，其余代码仍然存在。它仍然被加载，仍然是攻击面的一部分，仍然可被 prompt injection 和恶意代理触及。你无法区分哪些是活跃的、哪些是休眠的。你无法进行审计，因为你甚至无法界定”你的代码”的边界。使用技能方式，边界是清晰的：只有几千行代码，全部是你选择添加的，你可以阅读每一行。核心实际上随着时间在变小：例如，WhatsApp 支持正在被抽离并打包为技能。
为不信任而设计
如果一次幻觉或一个行为异常的代理就能导致安全问题，那么安全模型就是有缺陷的。安全必须在代理表面之外强制执行，而不是依赖代理的正确行为。容器、挂载限制和文件系统隔离的存在，就是为了确保即使代理做了意料之外的事情，爆炸半径也是可控的。
这一切都不能消除风险。一个能访问你数据的 AI 代理本质上就是一种高风险配置。但正确的应对方式是让信任尽可能窄、尽可能可验证。不要信任代理。在它周围筑起围墙。