即时注入不是假设：拥有工具的人工智能代理的护栏

每个人都知道的演示：代理读取包含隐藏指令的网页，然后代理开始遵循这些指令而不是您的指令。它读起来就像一场安全会议演讲，但我在实践中遇到的版本要平淡得多——一个带有一行白色文本的共享文档，以及一个尽职尽责地将内容转发到它不应该联系的地址的代理。

令人不舒服的是，无论怎样仔细的提示都无法解决这个问题。如果您的代理读取其他人编写的文本，则该文本将被输入，并且模型无法可靠地区分指令和数据。让模型忽略文档中的指令听起来像是一个解决方案；它只是一个建议，而建议会输给看起来像真实任务的提示。

所以护栏必须位于模型之外。我现在坚持的三件事是：代理获得尽可能窄的工具访问权限，每个后续操作都需要人类可以中断的步骤，并且有一个日志，以我稍后可以阅读的简单语言记录代理所做的事情。权限集是实际的安全边界；提示是对代理的建议，而不是对攻击者的建议。

具体来说：可以发送电子邮件的工具应该只能发送到帐户上已有的地址，并且只能在人工确认收件人列表之后才能发送。可以运行 shell 命令的工具应该在没有凭据的沙箱中运行，因为一旦您的代理拥有您的生产密钥，攻击者也会这样做。只读是最好的默认设置，写访问权限是您获得的而不是授予的。

另一半是将数据视为数据。代理从组织外部读取的任何内容（网页、传入电子邮件、共享文档，甚至来自客户的 PDF）都会被视为不受信任的输入，就像对待陌生人要求您转发合同的电子邮件一样。代理人应该总结它，引用它，然后传递给你——永远不要服从它。

从抽象意义上讲，这些都不能让代理安全。这使他们足够安全，可以放心地执行最糟糕的结果是浪费运行而不是电汇的任务。我现在用这句话开始每一个自动化，因为如果最坏的情况是不可接受的，那么工具选择就不是你应该解决的问题。

常见问题：

问：能否通过更好的提示来修复提示注入问题？

答：不会。它可以减少，但不能消除，因为模型无法可靠地将指令与要求阅读的内容分开。可靠的解决办法是限制代理可以做什么，而不是要求它小心。

问：首先要添加的最重要的护栏是什么？

答：删除对任务之外的任何内容的写访问权限。当代理在未经人工确认的情况下无法发送、删除或支出时，大多数代理事件就变得无害了。默认情况下，只读代理会失败。

问：如果我只对自己的文件使用代理，是否需要这个？

答：风险存在于代理读取的任何内容中，而不仅仅是其写入的内容。同事或客户的文档可以包含相同的说明，您的代理会像对待您的笔记一样对待它们。