不要相信 AI 代理
Source: Hacker News
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
使用 AI 代理进行构建：假设它们不可信
在使用 AI 代理进行构建时，应该把它们视为 不可信且可能具有恶意。无论你担心的是：
- Prompt 注入
- 模型试图逃离其沙箱
- 还是尚未有人想到的其他风险
…不管你的威胁模型如何，都不应信任该代理。
正确的做法
解决方案并不是：
- 更好的权限检查
- 更智能的白名单
相反，需要 设计假设代理会误行为的架构，并在它们出现问题时将损害限制在可控范围内。
这就是我构建 NanoClaw 时遵循的原则。
不要盲目信任流程
OpenClaw 默认直接在宿主机器上运行。它提供可选的 Docker 沙箱模式，但该模式 默认是关闭的，且大多数用户从不启用它。因此，安全性完全依赖于应用层检查，例如：
- 白名单
- 确认提示
- 预定义的“安全”命令集合
这些检查假设 隐式信任 代理不会进行恶意行为。如果你持有代理可能是敌对的思维方式，就会发现应用层的阻断不足——它们 无法提供全封闭的安全性。一个有决心或已被攻陷的代理仍能找到绕过的方法。
NanoClaw 的方法：容器隔离
| 功能 | 描述 |
|---|---|
| 每个代理的容器 | 每个代理在其自己的 Docker（或 macOS 上的 Apple Container）实例中运行。 |
| 短暂的生命周期 | 容器在每次调用时全新创建，随后被销毁。 |
| 非特权执行 | 代理在容器内以非 root 用户身份运行。 |
| 仅显式挂载 | 容器只能看到显式挂载的目录。 |
| 操作系统强制的边界 | 容器边界由操作系统强制执行，提供强隔离。 |
通过利用这些容器保证，NanoClaw 确保即使是恶意或已被攻陷的代理也无法逃离其沙箱或影响宿主系统。
不要信任其他代理
即使在启用了 OpenClaw 的沙箱时，所有代理共享同一个容器。你可能有个人助理代理、工作代理、家庭组代理等，它们分别在不同的 WhatsApp 群组或 Telegram 频道中运行。由于它们在同一环境中运行，原本应访问不同数据的代理之间可能会泄露信息。
为什么每个代理的隔离很重要
在 NanoClaw 中，每个代理拥有：
- 它的 独立容器
- 一个 专用文件系统 (
/data/) - 一个 独立的 Claude 会话历史
因此，你的个人助理无法看到工作代理的数据，反之亦然。
比较：共享容器 vs. 每代理容器
| 功能 | 共享容器 | 每代理容器 |
|---|---|---|
| 文件系统 | 单一共享文件系统 | 独立的 /data/ 目录 |
| 凭证 | 所有凭证均可访问 | 每个代理仅能看到自己的数据 |
| 会话历史 | 全部可见 | 每个代理拥有自己的会话 |
| 挂载数据 | 所有数据共享 | 挂载范围限定于每个代理 |
| 隔离 | 无——代理可以看到所有内容 | 代理之间相互隔离 |
| 示例布局 | ||
| 个人助理 | /data/personal (只读) | /data/personal (只读) |
| 工作代理 | /data/work (读写) | /data/work (读写) |
| 家庭组代理 | /data/family (只读) | /data/family (只读) |
容器边界是硬性的安全层——无论配置如何，代理都无法逃离它。
防御深度：挂载白名单
位于
~/.config/nanoclaw/mount-allowlist.json的挂载白名单提供了额外的安全保障：
- 目的： 防止 用户 意外挂载敏感路径，而不是阻止代理程序逃逸。
- 默认规则：
.ssh、.gnupg、.aws、.env、private_key、credentials等敏感目录/文件会被阻止。 - 位置： 白名单位于项目目录 之外，因此即使代理被攻破也无法修改自己的权限。
- 宿主代码： 宿主应用代码以 只读 方式挂载，确保代理所做的任何更改在容器销毁后都不会持久化。
Trust Model for Group Chats
- 非主群组默认不受信任。
- 其他群组的成员不能：
- 向他们不属于的聊天发送消息
- 为其他群组安排任务
- 查看属于其他群组的数据
由于任何群组中的成员都可能尝试 prompt‑injection 攻击，安全模型假设最坏情况并相应地对群组进行隔离。
不要相信你看不懂的东西
OpenClaw 包含 近五十万行代码、53 个配置文件以及超过 70 项依赖。如此规模破坏了开源安全的基本前提。
- Chromium 有 3500 万行代码，但我们仍然信任 Google 的审查流程。
- 大多数开源项目规模足够小，能够让众多眼睛实际审查。
没有人审查过 OpenClaw 的 40 万行代码。它在几周内完成，且没有正式的审查流程。复杂性是漏洞的藏身之处，而 Microsoft 的分析 证实：OpenClaw 的风险可能通过普通 API 调用出现，因为没有任何单个人能够看到全貌。
NanoClaw：小巧、可审计且可扩展
- 规模 – 一个进程和少量文件（约 3 千行）。
- 依赖 – 大量依赖 Anthropic 的 Agent SDK（Claude Code 的包装）来进行会话管理、内存压缩等，而不是重新造轮子。
- 可审计性 – 有能力的开发者可以在一个下午审计完整代码库。这是 一种刻意的约束，而非限制（理念）。
我们的 贡献指南 只接受：
- Bug 修复
- 安全修复
- 简化
基于技能的可扩展性
新功能以 技能 的形式出现：带有完整、可运行参考实现的指令，代码代理会将其合并到你的代码库中。
- 你可以 在代码落地前 审查 将要添加的代码。
- 只会添加你实际需要的集成。
- 每次安装最终都只有几千行代码，完全符合所有者的具体需求。
在一个单体的 40 万行代码库中，即使你只启用两个集成，剩余代码仍然被加载，成为攻击面的一部分，且可能被提示注入或恶意代理利用。你无法将活跃的部分与休眠的部分区分开，也无法审计，因为“你的代码”边界未定义。
使用技能时，边界非常明确：几千行你自行选择添加的代码，全部可读。核心实际上 随时间变得更小——例如，WhatsApp 支持正在被抽取并打包成一个技能。
不信任的设计
如果幻觉或行为异常的代理会导致安全问题，那么安全模型就已经失效。安全必须在代理表面之外强制执行；它不能依赖代理的正确行为。
- 容器、挂载限制和文件系统隔离的存在，是为了即使代理出现意外行为，冲击范围仍能被限制。
关键要点
- 风险仍在——拥有访问您数据权限的 AI 代理本质上风险极高。
- 缩小信任面——尽可能将代理的权限限制得更小且可验证。
- 不要信任代理——在其周围构筑防护墙。