本文翻译自 Don’t trust AI agents，原载于 Hacker News。
当你在构建 AI Agent 应用时，它们应该被视为不可信的、潜在恶意的实体。无论你担心的是 prompt injection（提示注入）、模型试图逃出沙箱，还是某种尚未被发现的攻击向量——不管你的威胁模型是什么，你都不应该信任 Agent。
正确的做法不是更好的权限检查或更智能的允许列表。而是假设 Agent 会出问题，并在它们出问题时控制损害范围的架构设计。
这正是 NanoClaw 的核心设计原则。
不要信任进程本身
OpenClaw 默认直接在主机上运行。它有一个可选的 Docker 沙箱模式，但默认是关闭的，大多数用户从未开启过。没有沙箱，安全性完全依赖于应用层面的检查：允许列表、确认提示、一组”安全”命令。
这些检查来自一种隐含的信任假设——Agent 不会试图做坏事。一旦你接受”Agent 可能是恶意的”这个前提，就会明白应用层面的拦截是不够的。它们无法提供密封的安全性。一个有决心的或被入侵的 Agent 总能找到绕过的方法。
在 NanoClaw 中，容器隔离是核心架构的一部分。每个 Agent 运行在自己的容器中，可以使用 Docker 或 macOS 上的 Apple Container。容器是临时的，每次调用时创建，结束后销毁。Agent 以非特权用户身份运行，只能看到被显式挂载的目录。容器边界由操作系统强制执行。
不要信任其他 Agent
即使启用了 OpenClaw 的沙箱，所有 Agent 也共享同一个容器。你可能有一个私人助理 Agent 和一个工作 Agent，在不同的 WhatsApp 群组或 Telegram 频道中。但它们都在同一个环境中，这意味着本应访问不同数据的 Agent 之间可能发生信息泄露。
Agent 之间不应该互相信任，就像你不信任它们一样。在 NanoClaw 中，每个 Agent 都有自己的容器、文件系统和 Claude 会话历史。你的私人助理看不到你工作 Agent 的数据，因为它们运行在完全独立的沙箱中。
容器边界是硬安全层——无论配置如何，Agent 都无法逃逸。在此基础上，~/.config/nanoclaw/mount-allowlist.json 中的挂载允许列表作为纵深防御的额外层：它的存在是为了防止用户意外挂载不该暴露的内容，而不是防止 Agent 越狱。敏感路径（.ssh、.gnupg、.aws、.env、private_key、credentials）默认被阻止。允许列表位于项目目录之外，因此被入侵的 Agent 无法修改自己的权限。主机应用代码以只读方式挂载，所以 Agent 做的任何操作都不会在容器销毁后持续存在。
群组中的人也不应该被信任。非主群组默认不被信任。其他群组和其中的人不能给其他聊天发消息、不能为其他群组安排任务、不能查看其他群组的数据。群组中的任何人都可能发送 prompt injection，安全模型已经考虑了这一点。
不要信任你无法阅读的东西
OpenClaw 有近 50 万行代码、53 个配置文件、超过 70 个依赖。这打破了开源安全的基本前提。Chromium 有 3500 多万行代码，但你信任 Google 的审查流程。大多数开源项目走的是另一条路：它们保持足够小，让很多人能真正审查它们。没有人审查过 OpenClaw 的 40 万行代码。它是在几周内写成的，没有正式的审查流程。复杂性是漏洞藏身之处，微软的分析也证实了这一点：OpenClaw 的风险可能通过普通 API 调用出现，因为没有人能看到全貌。
NanoClaw 是一个进程和少量文件。我们大量依赖 Anthropic 的 Agent SDK（Claude Code 的封装）来处理会话管理、内存压缩等功能，而不是重新发明轮子。一个有能力的开发者可以在一个下午审查完整个代码库。这是一个刻意的约束，不是限制。我们的贡献指南只接受 bug 修复、安全修复和简化。
新功能通过 skills（技能） 提供：带有完整参考实现的指令，由编码 Agent 合并到你的代码库中。你在代码落地之前审查将要添加的代码。而且你只添加真正需要的集成。每个安装最终都是几千行根据所有者确切需求定制的代码。
这才是真正的区别。对于 40 万行的单体代码库，即使你只启用两个集成，其余的代码仍然存在。它仍然被加载，仍然是你攻击面的一部分，仍然可以被 prompt injection 和恶意 Agent 访问。你无法理清什么是活跃的，什么是休眠的。你无法审计它，因为你甚至无法定义”你的代码”的边界。
使用 skills，边界是清晰的：几千行代码，全是你选择添加的，你可以阅读每一行。核心实际上在变小：例如 WhatsApp 支持正在被提取并打包为 skill。
为不信任而设计
如果幻觉或行为异常的 Agent 能导致安全问题，那么安全模型就是有缺陷的。安全性必须在 Agent 控制面之外强制执行，而不是依赖 Agent 正确行为。容器、挂载限制和文件系统隔离的存在，是为了即使 Agent 做了意外的事情，爆炸半径也被控制住。
这些都不能消除风险。有权访问你数据的 AI Agent 本质上是一种高风险安排。但正确的响应是让这种信任尽可能狭窄和可验证。
不要信任 Agent。在它周围建墙。
你可以在一个下午读完 NanoClaw 的源代码和完整安全模型——它们足够短。
关键要点
- 零信任原则：把 AI Agent 当作潜在恶意实体来设计，而不是假设它们会按预期行为
- 容器隔离是必须的：每个 Agent 独立容器，OS 级别的强隔离比应用层检查可靠得多
- 代码复杂度即风险：40 万行代码无法审计，几千行可以。选择你能理解的技术栈
- Skills 架构：按需添加功能，保持核心精简，每个安装都是定制化的
- 纵深防御：容器边界 + 挂载白名单 + 敏感路径黑名单，多层防护
- 群组隔离：不同群组的 Agent 和用户互不信任，防止横向渗透
这篇文章对正在构建 AI Agent 应用的开发者很有启发。在 AI 能力越来越强的今天，安全边界的设计比以往任何时候都重要。NanoClaw 的”极简 + 强隔离”哲学值得借鉴。