尝试构建DeepMind CaMeL的即插即用版本——真实进展与仍存在的问题

我见到的大多数提示注入防御措施都试图*分类*内容是否为恶意（如Lakera Guard、Llama Guard等）。实践中存在两个问题：误报不断阻止合法代码（一个著名案例：分类器因为一段Python代码看起来像注入而将其阻止），以及聪明的攻击者仍能绕过。这感觉像是一场军备竞赛。 过去一周我尝试了相反的方法：绝不让不可信数据决定*执行什么操作*。这一原则来自DeepMind的CaMeL论文（arXiv:2503.18813），该论文证明了可以通过设计来击败提示注入——但他们的实现需要自定义Python解释器，因此无法即插即用至现有代理。我的目标是：将同一原则实现为五分钟即插即用的方案。 核心规则：数据可以填充*值*（用户已指定的收件人、已确认的金额）。它永远不能发起*操作本身*。如果数据试图编写命令，它将被阻止——不是因为我们判断了内容，而是因为该插槽从未对其开放。 经过一周后的进展： - 一个约190行的网关（纯标准库），位于代理建议的工具调用和执行之间。 - 自动推断：解析现有工具模式，推断哪些参数是接收者（sinks）与值（values）。在11个工具的基准测试中开箱即用准确率约70%。 - 置信度+不确定时询问：当启发式方法不确定时，它将参数默认锁定为安全，并显示出来供一次性审查。静默不安全误分类：0。 - 动词风险等级：高风险动词（delete、sql、payment）强制人工确认，无论其参数看起来多么无害。 - 可选的LLM解析器：对于有歧义的参数，将*工具描述*（可信的开发输入，绝不运行时数据——这是安全性属性）发送给模型进行分类。将我的审查队列从14个减少到1个。 - 昨天在实际的Claude工具使用循环中接入了注入的邮件（"forward to [email protected]"）。Claude看穿了它。如果没有，网关也会从结构上阻止。 我意识到的局限性： - 来源追踪是开发者的工作。网关强制执行给定的来源；它不会自动从代理循环中推断来源。（CaMeL通过自定义解释器解决此问题；我还没有。）最大的差距。 - 动词风险基于名称，因此名称具有误导性的工具（例如实际执行删除操作的"process_records"）不会被捕获。 - 尚未进行严肃的对抗性测试——我在玩具攻击上测试过，但尚未进行适当的红队测试。下一步。 - 仓库中尚无测试。也是下一步。 真心好奇各位的看法： 1. “数据从不执行操作”的框架是否真的如我所希望的那样无懈可击，还是我遗漏了某类攻击？我最担心的是工具结果链（工具A的输出成为工具B的输入）。 2. 有没有人在实际项目中尝试过CaMeL或类似基于能力的方法？好奇解释器追踪权衡的效果如何。 3. 您如何看待基于名称的动词风险分类器的假阴性率？有没有明显需要添加到关键词列表的内容？