2026 年 2 月初，GitGuardian 发布了一份报告，足以让每个运行个人 AI 助手的开发者警醒。他们的密钥扫描基础设施检测到超过 200 个直接与 OpenClaw 部署相关的泄露凭证——API 密钥、数据库密码、OAuth 令牌和云服务商凭证，散落在公开仓库、日志文件和错误报告中。有些属于医疗公司，有些属于金融科技初创企业，而且全部是有效的。
几天后，Northeastern 大学发表了一篇文章，标题比任何 CVE 编号都更扎心："为什么 OpenClaw AI 助手是一场'隐私噩梦'"。研究人员没有聚焦于某个单一漏洞，而是聚焦于架构本身——OpenClaw 处理数据、存储凭证和暴露用户信息的方式，是设计使然，而非意外。
这些不是由粗心用户造成的孤立事件。它们是在没有任何隔离的环境中运行 AI agent 的必然结果——密钥、用户数据和 agent 代码共享同一个地址空间。
密钥是怎么跑到不该去的地方的
典型的 OpenClaw 设置是这样的：你在机器上安装它，在环境变量中配置 API 密钥，然后开始聊天。agent 进程以你的用户身份运行，拥有你的权限，读取你的环境变量。你安装的每个 skill 都在同一个进程中运行，拥有相同的访问权限。
这意味着当你让 AI 助手帮你调试部署脚本时，agent 能看到你的 AWS 凭证。当一个 skill 处理你的邮件时，它能读取你的数据库密码。当发生错误并记录堆栈跟踪时，那些环境变量可能出现在日志文件中。而当那个日志文件被提交到仓库、上传到 bug 报告或同步到云服务时——你的密钥就公开了。
GitGuardian 发现的 200 多个泄露密钥不是 200 个独立的失误。它们是同一个架构错误重复了 200 次：把密钥放在 process.env 中，让进程中的每段代码都能读取。
问题在 skill 和插件的加入下进一步恶化。OpenClaw 的 skill 系统在与核心 agent 相同的进程中运行第三方代码。恶意 skill 不需要漏洞利用就能窃取你的凭证——它只需读取 process.env。编写不当的 skill 也不需要故意泄露你的数据——它只需在错误报告中包含环境上下文。攻击面不是一个可以修补的漏洞，而是架构本身。 ## Northeastern 说对了什么
Northeastern 的研究人员指出了安全社区一直在回避的问题：AI 助手的隐私问题不在于加密或认证，而在于一个根本性的问题——agent 能访问什么，agent 的世界和你的世界之间存在什么边界。
当一个 AI agent 以你的用户身份、你的权限在你的机器上运行时，就不存在边界。agent 可以读取你的文件、你的凭证、你的浏览历史、你的 SSH 密钥。它能访问你能访问的一切。唯一阻止它做有害事情的是 prompt——而 prompt 注入攻击已经反复证明，prompt 不是安全边界。
这就是 Northeastern 所说的"隐私噩梦"的含义。不是说 OpenClaw 在故意窃取数据，而是这种架构使得数据泄露无法被杜绝。agent 的访问范围仅受操作系统用户权限的约束，换句话说，几乎没有实质性的约束。
NanoClaw 的容器隔离如何改变局面
NanoClaw 采用了根本不同的方式。每个 agent 都在自己的 Linux 容器中运行——macOS 上用 Apple Container，Linux 上用 Docker。容器不是一个便利功能或部署选项，它就是安全模型本身。
当你向 NanoClaw 发送消息时，宿主进程不会直接运行 Claude。它会启动一个容器，只挂载该 agent 需要访问的特定目录，然后将对话上下文传入。agent 在容器内运行，拥有自己的文件系统、自己的进程空间和自己的网络栈。完成后，容器被销毁。
密钥处理方式是关键所在。NanoClaw 从不将 ANTHROPIC_API_KEY 加载到 process.env 中。相反，它在运行时从 .env 读取密钥，并通过 stdin 以 JSON 载荷的形式传递给容器进程。在容器内部，agent-runner 接收密钥，用于 API 调用，且永远不会将其写入磁盘或导出到环境变量。
这意味着即使恶意 prompt 诱骗 agent 运行 `printenv` 或 `cat /proc/self/environ`，API 密钥也不在那里。它只存在于 agent-runner 的进程内存中，仅在单次对话轮次的持续时间内存在。被攻破的容器无法泄露它没有访问权限的东西。
挂载系统增加了另一层防护。NanoClaw 维护一个可以挂载到容器中的目录白名单，存储在项目根目录之外。每个群组都有自己隔离的文件系统——自己的 CLAUDE.md 记忆文件，自己的可写工作区。白名单包含符号链接逃逸检测，因此精心构造的符号链接无法欺骗挂载系统暴露允许集合之外的目录。
容器还以非 root 用户运行，项目源码以只读方式挂载。agent 可以读取代码库以理解上下文，但无法修改宿主机的文件。可写路径按群组划分，容器退出时被清理。 ## 按群组隔离模型
NanoClaw 的隔离不仅仅是将 agent 与宿主机分开。每个 WhatsApp 群组都有自己的容器、自己的记忆和自己的文件系统。群组 A 无法看到群组 B 的对话、文件或 CLAUDE.md 记忆——不是因为应用层的访问控制，而是因为它们运行在物理上独立的容器中，拥有独立的挂载点。
这对大多数 AI 助手完全忽略的场景至关重要：共享设备和多用户设置。如果你和家人一起使用 NanoClaw，你的工作群组的对话和文件与家庭群组的对话和文件在容器层面就是隔离的。不存在能导致群组间数据泄露的应用 bug，因为隔离是由容器运行时而非应用程序来保证的。
你的主 WhatsApp 频道——与助手的私聊——充当管理界面。它是唯一可以管理定时任务、修改配置和访问跨群组状态的频道。群组频道默认被限制在自己的沙箱中。
行业应该学到的教训
GitGuardian 的报告和 Northeastern 的分析指向同一个结论：AI agent 是基础设施，基础设施需要基础设施级别的安全。在与你的凭证相同的进程中、以你的用户账户相同的权限运行 AI agent，等同于以 root 身份运行一个没有防火墙的 Web 服务器。在出事之前一切正常，而一旦出事，爆炸半径就是一切。
容器隔离不是新概念。Web 托管行业二十年前就想明白了——你不会在同一个进程中运行多个客户的代码。数据库行业更早就想明白了——你不会让每个查询都能访问每张表。但 AI agent 生态系统仍处于"以 root 运行一切"的阶段，泄露的密钥和隐私噩梦就是可预见的结果。
NanoClaw 的方式不是解决这个问题的唯一途径，但它证明了这个问题是可以在不牺牲功能的前提下解决的。在容器中运行的 agent 仍然可以搜索网页、浏览页面、读写文件和执行 shell 命令。它们只是在一个沙箱中完成这些操作，任何故障的爆炸半径——无论是 bug、prompt 注入还是恶意 skill——都被限制在单个容器的范围内。
GitGuardian 发现的 200 个泄露密钥本不必发生。它们之所以发生，是因为架构使其不可避免。修复方案不是更好的用户教育或更谨慎的凭证管理。修复方案是一种密钥根本无法泄露的架构——因为它们从未被放在可能泄露的位置。