AI 智能体不可信：安全架构应假设其恶意行为
在 AI 智能体（Agent）开发与应用日益普及的今天，一个核心的安全原则正在被忽视：永远不要信任 AI 智能体。这并非危言耸听，而是基于当前技术架构潜在风险的深刻反思。
为什么不能信任 AI 智能体？
无论是担心提示词注入（Prompt Injection）、模型试图突破沙箱限制，还是未来可能出现、目前尚未被想到的攻击方式，开发者都不应假设智能体会“乖乖听话”。传统的安全措施，如更精细的权限检查、更智能的允许列表（Allowlists），本质上都建立在“智能体不会主动作恶”的隐含信任之上。
一旦我们转变思维，将 AI 智能体视为潜在的恶意实体，就会发现应用层面的防护是远远不够的。一个意志坚定或被攻陷的智能体，总能找到绕过这些检查的方法。
从 OpenClaw 的案例看问题所在
以 OpenClaw 为例，其默认配置就暴露了典型的安全隐患。默认情况下，它直接运行在主机上，其可选的 Docker 沙箱模式是关闭的，且大多数用户从未启用。这意味着安全完全依赖于应用层面的检查——允许列表、确认提示、一组“安全”命令。这种架构的脆弱性显而易见。
正确的安全架构：NanoClaw 的启示
与上述思路相反，NanoClaw 的设计哲学是：假设智能体会行为不端，并构建能限制其破坏的架构。其核心是将容器隔离作为架构的基石。
- 每个智能体运行在独立容器中：在 Docker（或 macOS 的 Apple Container）中，每个智能体都拥有自己专属的、临时的容器。容器在每次调用时创建，任务完成后销毁。
- 最小权限原则：智能体以非特权用户身份运行，只能访问被显式挂载（mount）的目录。容器边界由操作系统内核强制实施，提供了更强的隔离性。
智能体之间也不应互信
即使启用了沙箱，另一个常见问题是多个智能体共享同一个容器环境。例如，你可能有一个私人助理智能体和一个工作智能体，分别用于不同的聊天群组。但在共享容器中，它们的数据（如文件系统、会话历史、凭证）可能相互泄露。
NanoClaw 的解决方案是彻底的隔离：
- 每个智能体拥有独立的容器、文件系统和 Claude 会话历史。
- 你的私人助理无法窥探工作智能体的数据，因为它们运行在完全分离的沙箱中。
共享容器模式 vs. 单智能体容器模式对比
| 特性 | 共享容器（风险模式） | 单智能体容器（安全模式） |
|---|---|---|
| 文件系统 | 共享，所有数据可见 | 独立（如 /data/personal, /data/work） |
| 凭证访问 | 所有智能体均可访问 | 仅本容器内智能体可访问 |
| 会话历史 | 所有历史记录可见 | 仅本智能体可见 |
| 挂载数据 | 全部共享 | 按需、隔离挂载 |
| 安全状态 | 所有智能体能看到一切 | 智能体间数据隔离 |
对 AI 开发者的启示
随着 AI 智能体承担更多自动化任务（如代码执行、文件操作、API 调用），其安全风险指数级上升。开发者必须将**“零信任”原则**应用于智能体本身。这不仅仅是添加一层安全检查，而是需要从系统架构层面重新思考：
- 默认隔离：沙箱或容器隔离不应是“可选功能”，而应是默认且强制的运行环境。
- 资源与数据隔离：确保智能体之间无法通过共享环境进行横向移动或数据窃取。
- 假设失效：在设计时，就应假设所有防护措施都可能被绕过，并据此设计兜底和损害控制机制。
小结
AI 智能体的能力越强大，其潜在的攻击面也越广。信任，不应是默认设置。未来的 AI 应用安全，将越来越依赖于像 NanoClaw 所倡导的、基于不信任假设的架构设计，而非事后的修补和权限管控。这不仅是技术选择，更是应对未知风险的必要思维转变。
