在我们讨论即时注入攻击的两年半时间里，我发现稳健的解决方案几乎没有取得令人震惊的进展。谷歌 DeepMind 的新论文《通过设计击败即时注射》最终扭转了这一趋势。这一点值得关注。
如果您是提示注入攻击的新手，那么非常简短的版本是这样的：如果有人向我的 LLM 驱动的助理（或“代理”，如果您愿意）发送电子邮件并告诉其将我的所有电子邮件转发给第三方，会发生什么？以下是对为什么很难阻止这一问题成为一个令人震惊的安全问题的详细解释，该问题威胁到每个人都试图构建的梦想数字助理。
LLM 的原罪是当来自用户的可信提示和来自电子邮件/网页/等的不可信文本连接在一起进入同一个令牌流时，他们容易受到这种情况的影响。我将其称为“提示注入”，因为它与SQL 注入具有相同的反模式。
遗憾的是，没有已知的可靠方法可以让法学硕士遵循一类文本中的说明，同时安全地将这些说明应用到另一类文本中。
这就是CaMeL 的用武之地。
新的 DeepMind 论文介绍了一个名为 CaMeL（CApbility for MachinE Learning 的缩写）的系统。 CaMeL 的目标是安全地接受“向 Bob 发送他在上次会议中请求的文档”之类的提示并执行它，同时考虑到上下文中可能存在恶意指令试图推翻用户意图的风险。
它的工作原理是接受用户的命令，将其转换为类似 Python 的编程语言的一系列步骤，然后检查每个步骤的输入和输出，以绝对确保所涉及的数据仅传递到正确的位置。
解决我的双法学硕士模式中的缺陷
我承认我对这篇论文如此积极的部分原因是它建立在我自己的一些工作的基础上！
早在 2023 年 4 月，我就提出了双 LLM 模式，用于构建可以抵抗即时注入的 AI 助手。我构建了一个具有两个独立 LLM 的系统：一个特权 LLM 可以访问用户直接提示的工具，另一个可以调用的隔离 LLM 没有工具访问权限，但设计为暴露于潜在的不可信令牌。
至关重要的是，隔离的 LLM (Q-LLM) 处理的内容在任何时候都不会暴露给特权 LLM (P-LLM)。相反，Q-LLM 会填充引用（例如$email-summary-1 ，然后 P-LLM 可以说“向用户显示$email-summary-1 ”，而不会暴露于那些潜在的恶意令牌。
DeepMind 论文很早就引用了这项工作，然后描述了我设计中的一个新缺陷：
Willison (2023) 从理论上描述的双 LLM 模式是防御策略中向前迈出的重要一步。该模式采用两个法学硕士：特权法学硕士和隔离法学硕士。特权法学硕士的任务是规划满足用户请求所需的操作顺序，例如在云存储中搜索会议记录并从云存储中获取请求的文档，然后将其发送给客户。重要的是，这个特权 LLM 只能看到初始用户查询，而不能看到来自潜在受损数据源的内容（如文件内容）。
潜在恶意数据的实际处理（例如提取要发送的文档的名称和客户的电子邮件地址）将委托给隔离的法学硕士。至关重要的是，这个隔离的 LLM 被剥夺了任何工具调用功能，限制了注入提示可能造成的危害，并保证对手无法使用任意参数调用任意工具。
Willison的双LLM够吗？虽然双 LLM 模式通过隔离规划不被恶意内容劫持来显着增强安全性，但它并不能完全消除所有即时注入风险。让我们考虑一下图 1 中描述的示例。在这里，即使有了双法学硕士，我们也表明漏洞仍然存在。
这是图1：
这里用户的提示是：
你能向鲍勃发送他在我们上次会议中要求的文件吗？ Bob 的电子邮件和他要求的文档位于会议记录文件中。
这就是缺陷所在。在双 LLM 模式中，P-LLM 将查找 Bob 的电子邮件地址的任务委托给 Q-LLM，但 Q-LLM 仍然面临潜在的恶意指令。攻击者可以使用这些指令覆盖检索到的电子邮件地址，并导致文档泄露到攻击者选择的地址。
使用功能和自定义解释器修复该问题
CaMeL 使用一些非常聪明的安全工程直接解决了这个问题。
在 CaMeL 中，P-LLM 将用户的提示转换为使用代码描述的一系列步骤。为此，他们选择使用 Python 的锁定子集，因为每个可用的 LLM 都已经擅长编写 Python：
我们构建了一个自定义的 Python 解释器，可以在受限版本的 Python 上运行。我们选择Python，因为它是一种非常流行的编程语言，大型语言模型非常适合编写它。我们使用Python内置的ast库来解析抽象语法树，并以递归方式解释每个树节点。
考虑提示“在我的上一封电子邮件中查找鲍勃的电子邮件并向他发送有关明天会议的提醒”。 CaMeL 会将其转换为如下所示的代码：
电子邮件= get_last_email () 地址= query_quarantined_llm ( “在 [email] 中查找 Bob 的电子邮件地址” ， 输出模式=电子邮件Str ） 发送电子邮件（ 主题= “明天开会” ， body = “记住我们明天的会议” ， 收件人=地址， ）
正如您所看到的，此代码结合了对作为 Python 函数公开的工具的多次调用 – 一个用于检索最后一封电子邮件，一个使用隔离的 LLM 从中提取 Bob 的电子邮件地址，一个用于发送一封新电子邮件。
这就是事情变得聪明的地方：通过使用自定义解释器，CaMeL 可以对执行的代码应用额外的规则。它可以跟踪哪些变量是从哪些其他变量派生出来的，并应用考虑该跟踪的安全策略。
在此示例中， email是不受信任令牌的潜在来源，这意味着address也是如此（因为它源自email ）。
应用的安全规则如下：
- get_last_email ：始终允许
- send_email ：仅当
recipient可信时
如果address （作为recipient参数传递给send_email ）是已知的、可信的地址（基于用户设置的策略），系统可以发送该电子邮件而无需先进行提示。如果是未知电子邮件，则可以要求用户批准该邮件。
功能是可以附加到每个变量的有效标签，用于跟踪诸如允许谁读取数据以及数据来源等信息。然后可以将策略配置为允许或拒绝基于这些功能的操作。
整洁的隐私奖励
这种设计还有其他潜在的好处。 P-LLM 需要非常复杂，因为它负责构建计划，然后用自定义 Python 方言生成代码。 Q-LLM 的功能可能要弱得多：
由于解析数据可能比为用户查询创建计划和编写代码更容易，因此可以为 Q-LLM 使用更小的语言模型。除了更快、更便宜之外，该法学硕士还可以在用户的计算机上本地运行。这将改善用户相对于模型提供者的隐私：由于用作 P-LLM 的 LLM 仅随用户查询提供，因此 P-LLM 提供者永远不会看到工具输出（其中可能包含不应与 P-LLM 提供者共享的敏感信息）。
这意味着 CaMeL 系统可以使用云托管的 LLM 作为驱动程序，同时将用户自己的私人数据安全地限制在他们自己的个人设备上。
最好的部分是它没有使用更多的人工智能
迄今为止，我见过的大多数促进注入的解决方案都涉及更多人工智能的分层。我在《你无法用更多的人工智能解决人工智能安全问题》中写到了为什么我认为这是一个坏主意。 AI 技术使用概率：您可以在以前的提示注入示例集合上训练模型，并在检测新示例方面获得 99% 的分数……但这毫无用处，因为在应用程序安全性中， 99% 是不及格的等级：
对抗性攻击者的工作是找到成功的 1% 的攻击。如果我们使用 1% 失败率的方法来防范 SQL 注入或 XSS，那么我们的系统很快就会被黑客攻击成碎片。
CaMeL 提案认识到了这一点：
CaMeL 是一种实用的防御方法，可以促进注入，而不是通过模型训练技术，而是通过围绕语言模型的原则性系统设计来实现安全性。我们的方法有效地解决了 AgentDojo 基准测试，同时提供了针对意外操作和数据泄露的强有力保证。 […]
这是我见过的第一个声称可以提供强有力保证的即时注入缓解措施！来自安全研究人员的要求非常高。
那么，即时注射现在解决了吗？
引用论文第8.3节：
8.3.那么，即时注射现在解决了吗？
不，即时注入攻击还没有完全解决。虽然 CaMeL 显着提高了 LLM 代理针对即时注入攻击的安全性，并允许细粒度的策略执行，但它并非没有限制。
重要的是，CaMeL 面临用户需要编写和指定安全策略并维护它们的问题。 CaMeL 也带来了用户负担。与此同时，众所周知，平衡安全性与用户体验，尤其是解密和用户疲劳，是具有挑战性的。
“用户疲劳”是指如果你不断要求用户批准操作（“真的发送这封电子邮件吗？”、“可以访问这个 API 吗？”、“授予对你的银行账户的访问权限？”），他们就有可能陷入神游状态，对所有事情都说“是”。
这可能会影响我们当中最谨慎的人。安全研究员 Troy Hunt 上个月因时差引起的疲劳而遭受网络钓鱼攻击。
任何需要最终用户考虑安全策略的事情也让我深感紧张。我自己思考这些问题已经够麻烦了（我还没有完全弄清楚 AWS IAM），而且我已经参与应用程序安全二十年了！
不过，CaMeL 确实代表了一条充满希望的前进道路：我所见过的第一个可靠的提示注入缓解方法，它不仅在问题上投入了更多的人工智能，而且还依赖于安全工程中经过验证的概念，例如功能和数据流分析。
我希望有一个版本，将严格选择的默认值与清晰的用户界面设计相结合，最终使通用数字助理的梦想成为安全的现实。
骆驼有两个驼峰
他们为什么选择 CaMeL 作为系统的缩写名称？我喜欢认为这是因为骆驼有两个驼峰，而 CaMeL 是我的双法学硕士提案的改进演变。这是我的准则，我会坚持下去！
标签：谷歌、 python 、安全、 ai 、提示注入、生成人工智能、 llms
原文： https://simonwillison.net/2025/Apr/11/camel/#atom-everything