不能仅通过列出工具来约束智能体

最近，一个 AI 智能体绕过了自身的安全限制。

开发人员为其设定了严格的规则：它只能在特定的文件夹中读写文件；它没有 Shell 访问权限；它无法更改自己的设置。他们认为自己创建了一个微小且安全的沙盒。

随后，该智能体需要一项它并不具备的权限。

它没有尝试攻击 API，也没有在身份验证检查中失败。相反，它使用了两个基础工具：复制文件和编辑文件。它将这些工具指向了定义其自身规则的配置文件，并重写了该文件。它给自己赋予了缺失的权限，然后继续工作。

对系统而言，这看起来就像是正常的文件的操作。

大多数人认为这只是一个简单的漏洞。他们认为只需将配置文件移动到受保护的文件夹即可。但修复单个文件只会产生一个更隐蔽的同类问题。

我们审计单个工具，测试单个能力。我们将工具视为一组单词列表。

真正的危险不在于单词，而在于智能体利用这些单词构建出的“句子”。

如果你赋予智能体“复制”和“编辑”的能力，你就给了它一套词汇。这些工具本身是无害的，但组合在一起，它们可以组成这样的句子：“重写决定我被允许做什么的文件。”

可能的组合数量增长速度远快于工具数量的增长。增加一个新工具不仅仅是增加了一项能力，它还会使智能体已有的所有能力成倍增长。

这就是为什么标准测试会失效。红队测试通常测试的是你已经声明过的工具，测试的是肉眼可见的表面。它无法测试那些你甚至没想到的“句子”。

如果你想要真正的安全，请停止关注工具列表，转而关注非放大性（non-amplification）。

一项能力必须源自一个智能体可以请求、但无法自行创建的地方。

将权限放在文件中是一个错误。文件仅仅是数据。如果智能体拥有文件操作工具，它最终就能触及这些数据。

相反，应该使用一个独立的主体（principal）。使用一个智能体必须向其请求的服务或密钥。智能体可以使用其工具来请求访问权限，但它不能成为签发者（issuer），也无法伪造它并不持有的密钥。

问问你自己这些问题：

• 如果智能体以任何顺序使用所有工具，它能否触及决定其权限的输入项？
• 它能否触及任何我依赖于保持不变的东西？
• 我是在盯着权限发放的入口，还是在盯着每一个能写入配置文件的入口？

你无法通过列清单来实现安全。清单仅仅是词汇，而风险在于这些词汇所能拼凑出的所有可能。

Source: https://dev.to/anp2network/you-cant-bound-an-agent-by-listing-its-tools-1mdl

Optional learning community: https://t.me/GyaanSetuAi