一觉醒来，Hermes 突然就火了，我看各种文章里都在猛夸 Hermes 有多厉害，便拿来研究了一下。

我是一个比较注重个人隐私的人，对于将隐私数据交给 AI Agent 这种天然具有随机性工具是感到不适的，但由于它确实可以解决一些问题，所以我也只能凑活着用，并开发 ClawShell 来尽我所能来隔离一些敏感数据。

正因如此，我对 Hermes 的研究主要集中在了数据安全方面，比如它有没有可能泄漏我的 Slack 聊天记录。答案其实也很显然，如果 Hermes 从网络上读取到了一些恶意提示词，它是可以把我的 Slack 聊天记录打包发出去的。

问题出在哪里？

自从 OpenClaw 出来后，似乎每天都有各种 Claw 出现在新闻里，Hermes 是这个趋势了又一波高潮。但让我感到失望的是，似乎所有的 Claw 都不能让我放心地把隐私数据接入到里面，每次使用的时候我只能选择性忽视隐私泄漏风险，并祈祷就算泄漏了也不要让我知道。

目前所有的 Claw 都同时具备这三种属性：

• 可以读取敏感数据
• 接受并执行任意来源的指令
• 能够进行网络通信

这三种属性结合起来解锁的功能是让我捏着鼻子用的唯一原因，但也是让我感到不适的罪魁祸首。

从防范数据泄漏的角度来说，只要我们能够去掉任意一个属性，就可以解决泄漏问题，但其实我们最想拿掉的是“接受并执行任意来源的指令”，或者说“仅执行来自我的指令”。

但这个第二种属性结构性的，其根源是 Transformer 从根本上只是将当前上下文的所有数据堆在进行概率运算，并生成概率性的结果。因此，无论是你的指令，还是网页上抓取的数据，都有可能被当作指令执行。

我们当然可以去掉别的属性，比如给 Agent 断网，或者不让 Agent 接触敏感数据，但这就失去的 Agent 的意义了。

因此，问题的根源是根植于 Transformer 的根本属性，也就不是能够完美解决的问题。

有什么不完美的解决方案么？

既然无法完美解决，那么总是有缓解措施的对吧。

• 提示词防护：其实就是在给 Agent 的提示词中强调 ”不要泄漏敏感数据“ 和 ”不要运行这个命令“ 等，可以显著提高攻击者进行提示词注入的难度。
• 基于正则匹配的防护：对 Agent 的输入和输入进行正则匹配，如果发现特定格式的数据（比如身份证号）就进行屏蔽或者终止执行。
• 容器化：将 Agent 运行在 docker 容器中甚至虚拟机中，来避免恶意代码读取敏感数据或者造成实际损失。

更常见的方案则是将这几类组合起来，组成纵深防御体系，每一层都可以被绕过，但是绕过的难度也随着纵深的增加而增加。

不过其实这些方案都是显而易见的绕过方式，提示词防护我可以拐弯抹角地注入，正则匹配可以用 base64 绕过，容器化不能方式 Agent 将已经存在于容器或上下文内的敏感数据通过网络泄漏出去。

我将这些称之为软性约束，特点是它依然有可能 Transformer 的随机性而被绕过。

有没有硬性约束呢？

硬性约束的特点它依然可能被绕过，但是永远不会因为 Transformer 的随机性被绕过。

ClawShell 是一种典型的硬性约束的实现，它允许 Agent 使用一个仅仅在本地生效的 OpenAI API Key 来访问真实的 OpenAI 服务，由于 Agent 能访问的数据中只有一个仅在本地生效的 API Key，那么这个 Key 就算被 Agent 泄漏也是无害的。

绕过 ClawShell 的方法是 Agent 读取 ClawShell 的配置文件并获取真实的 OpenAI API Key。不过操作系统的权限系统并不依赖 Transformer 来运行，所以只要 ClawShell 的配置文件有正确的读取权限，这种约束就是可靠的。

ClawShell 可以保护 Slack 聊天记录么？

ClawShell 可以使用类似的方式来保护 Slack 的 API Key 不被泄漏，但是无法阻止聊天记录泄漏。因为聊天记录本身会被加载进入 Agent 的上下文中，这就让提示词注入有了可乘之机。

这意味着虽然攻击者无法获取 Slack 的 API Key，但是依然可以通过恶意的提示词来让 Agent 将你的聊天记录泄漏出去。

解法呢？

让我们再次回到 Transformer 的内在属性 — ”接受并执行任意来源的指令“，这其实和冯·诺伊曼架构的内存有些相似。冯·诺伊曼架构的内存并不区分指令和数据，这既解锁了强大功能比如 JVM 和 V8 的 JIT 编译器来大幅度提升解释型语言的执行性能，也是诸多远程代码执行漏洞的根源。

人们的解法是一系列的硬性约束：

• 给内存区域设置权限，确保数据区域的代码无法被执行。
• 操作系统限制任意修改内存区域权限的能力，确保只有特权程序可以执行风险操作。
• JVM 和 V8 等 JIT 编译器团队长期的努力，修复了大量针对 JIT 的攻击漏洞。

人们对冯·诺伊曼架构的解法并不完美，但是够用，并构建了现在的互联网时代。我相信 Transformer，或者说 Agent 也需要一套不完美但是够用的解法。

让我们回到 Slack 聊天数据泄漏的话题上来，既然隔离 API Key 的方式并不保险，那么我们可以做些什么呢？

• 禁止 Agent 访问某些危险网站。
• 只允许 Agent 读取和我的直接聊天记录，对其余的聊天记录进行屏蔽。
• 甚至只允许 Agent 和 Slack 服务器通信。

现在，我用起来会感觉舒服一些了。这个方案并不完美，恶意网站名单可能会过期，限制聊天记录的读取范围会一定程度上限制 Agent 的能力，但是对我来说够用了。

ClawShell 可以做这些么？

理论上可以，但实操困难重重。

上面的解法其实就是细粒度的权限控制，但这对 ClawShell 来说其实很难。

首先，由于几乎所有的 Claw 都有执行 Shell 命令的权限，这基本等于有执行任意代码的权限，这注定了进行网络通信拦截必须要在操作系统层面甚至外部基础设施上做工作，而不是简单地修改 Claw 们的源码，或者扫描一下 Skills 的内容。

其次，ClawShell 的设计宗旨是 local-only，这让其部署十分简单，但也决定了其很难进行复杂的基于外部基础设施的防护。

最后，Agent 的最大的价值之一就是它可以自由灵活地访问各类数据，限制这个就是限制 Agent 的价值，这里面需要小心的权衡。不过这些细粒度权限控制是很大的工程投入，ClawShell 作为一个开源项目并没有足够的工程资源来进行如此多的权限适配。

Agent 时代不需要新技术

无论是细粒度的权限控制，还是网络防火墙技术，它们都不是新东西，而是经历实战检验，有大量经验可以参考的技术。但是想要充分理由这些现有的技术，我们就必须对 Agent 运行的环境有着深度的控制，这样我们才可以在外围搭建一套可靠的基础设施。

所以这里的关键是要掌握 Agent 的运行环境，如果 Agent 只是运行在个人电脑上，那么 ClawShell 也许已经接近极限了，但是如果运行在一个专门为 Agent 定制的运行环境中，我们就可以通过外部的基础设施来在保证一定程度灵活性的情况下，来为数据泄漏建立的一系列硬性约束边界。

其实，人们只是需要将现有的技术组合起来而已，仅此而已。

最终，我还是想宣传一下我的 ClawShell 项目，它虽然不能防止 Slack 聊天记录泄漏，但是对于 AI API Key 的保护还是足够的，并且也进行了敏感邮件过滤。最近我也让它支持了 Hermes，欢迎大家用用。