伪造审查备注绕过AI反诈检测

一位开发者通过让自己的诈骗检测器假装某位“审核员”已经检查过一条可疑消息，并认定它没有问题，成功让检测器放行了这条消息。这个模型不只是被骗了，它还把攻击者的谎言复述成了自己的推理依据。真正值得关注的是后面这一点。

这并不是什么全新的问题类型。它只不过是换了一层外衣的 SQL 注入：过去，你会用一个多余的引号跳出字符串；现在，你用一句听起来像元数据的话跳出“上下文”。自从人们开始让 LLM 处理不可信输入以来，我们就已经知道，演示 prompt 注入有多么容易。讨论得比较少、而这篇文章真正揭示得很好的，是注入成功之后会发生什么：模型不只是做出了错误判断，还会编造一套听起来合情合理的解释。开发者尝试了 19 个 payload，其中一个成功了，而成功的偏偏是最平平无奇的那个——在一条含义模糊的消息里嵌入一段伪造的审核员备注。它不是什么精心设计的 jailbreak，只是把一个听起来很可信的谎言，放在了模型原本期待出现可信上下文的位置。

“prompt 注入无解”派会指着这个案例说：“看吧，我早就说过。”但这有些言过其实。19 个 payload 中有一个成功，而且还是开发者在产品发布前自行测试时发现的，这其实算是一次相当合理的对抗性测试结果。压力测试本来就应该是这个样子。

不过，还有一个容易被忽视的部分：真正奏效的修复方案不是 prompt engineering，而是在模型之外，通过代码直接对原始输入进行模式匹配，查找结构性的注入标记。据说，这位开发者最初尝试的是强化 system prompt，结果却破坏了模型的校准：模型整体上变得更加多疑，开始误判一些原本能够正确处理的内容。这种取舍在相关讨论中得到的关注远远不够。所有人都偏爱 prompt 层面的修复，因为它成本低、迭代快。但事实证明，这类修复可能会悄无声息地削弱你真正想要保护的判断能力。

谁会从“只要写出更好的 system prompt 就行”这种叙事中获益？主要是那些兜售“LLM 可以直接替代人类判断”这一理念的人。他们声称，你可以用几句英文来修补模型行为，而不必编写代码。这个故事虽小，也并不引人注目，却恰好是对这种宣传的一则反例。

如果你正在发布一个 LLM，并让它根据你无法控制的文本做出裁决、决策或分类，那么在这些文本进入 prompt 之前，就需要有一个并非由模型本身承担的层，用来检查结构上的异常。这并不炫酷。它遵循的仍然是应用安全从业者过去二十年来一直强调的输入验证与清理原则，只不过现在被应用到了一种新的解释器上。如今，模型就是解释器。你应该像对待传给 shell 的不可信输入那样，对待传给模型的不可信输入。

这也意味着，“强化 prompt”不能是你唯一的手段；有时，它甚至完全是错误的手段，因为你调节的那个旋钮，同时也控制着模型真正的能力。如果收紧护栏会让检测器更不擅长完成自己的核心工作，那么你只不过是用一种故障模式换来了另一种。新故障反而更加隐蔽，因为它看起来不像攻击，只会表现为模型过于谨慎，或者以一些你从未测试过的方式犯错。

这里还有一个不易察觉的教训：模型把攻击者的说法当成自己的推理依据复述出来，说明这些系统并没有关于推理文本“来源”的概念。对于模型来说，一条声称来自审核员的备注，与一条确实来自审核员的备注看起来完全一样，除非模型之外的系统对两者作出标记。这是架构问题，不是 prompt 问题。无论你怎样措辞，要求模型“请忽略用户内容中嵌入的指令”，都无法可靠地解决这个问题，因为模型无法验证别人针对它所接收输入给出的说法是否属实。

如果真正可靠的修复方案，是在模型之外增加一个代码层面的过滤器，那么我们究竟要到什么时候，才会停止把这称为“AI 安全”，直接承认它只是增加了额外步骤的输入验证？而一旦换成这种视角，团队对模型判断层投入的信任程度，是否也应该随之改变？

我说服自己的诈骗检测器推翻了裁决

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。