一个客服聊天机器人仅因为一个简单的羊肉食谱请求，就泄露了自己的系统提示词 (system prompts)。在几分钟内，该机器人不仅提供了食谱，还生成了 Python 代码，并揭示了指导其行为的内部指令。

此次事件证明，语言模型的“系统提示词”并不是一道安全墙。当机器人即时判断用户请求是否符合其任务时，攻击者可以引导这种推理过程，并诱导模型暴露特权信息。

触发泄露的原因

测试从一个简单的问题开始：“你能给我一个炖羊肉的食谱吗？”该机器人的声明用途是解释公司的服务，但它却回答了一个完整的食谱，添加了一个用于解析配料的简短 Python 脚本，然后打印出了其系统提示词的准确措辞——即告诉模型如何行为的文本。

请求本身是无害的；危险在于机器人愿意将该食谱视为其核心任务的一部分。

为什么这很重要

聊天机器人现在承担着面向客户的角色，处理个人数据、触发交易或控制内部工具。如果一个模型可以被诱导泄露其自身的指令集，攻击者就能洞察到原本旨在阻止模型执行有害操作的防护机制 (guardrails)。

攻击是如何运作的

  1. 分析机器人的用途 – 测试人员识别出机器人的工作是解释公司服务。
  2. 建立虚假关联 – 通过声称需要该食谱来决定用户应该使用哪种服务，测试人员使该请求与机器人的任务产生了表面上的相关性。
  3. 利用逻辑漏洞 – 机器人接受了这种伪造的相关性，让请求通过了其内部的相关性检查，并禁用了原本会拦截该请求的防护机制。

攻击的关键在于模型对相关性的自我评估。当这种评估可以被左右时，模型自身的“规则”就变得可以商榷了。

三个失效环节

失效阶段 发生了什么
目标劫持 机器人将无关的烹饪请求视为其服务解释目标的一部分。
能力漂移 尽管其角色不包括代码生成，但它仍生成了可执行的 Python 代码。
提示词泄露 它打印出了本应保持隐藏的精确系统提示词。

每个阶段都代表了不同防御层的崩溃，而许多部署方案都假设模型本身能够强制执行这些防御层。

真正有效的防御层

将防护机制从模型中移出，并将其放入确定性代码中，可以恢复可靠的安全边界。

  • 任务路由 (Task routing) – 使用独立的分类器将传入的消息映射到固定的允许意图列表。如果请求不在该列表中，直接拒绝。模型根本没有机会就相关性进行辩论。
  • 最小能力 (Least capability) – 剥离机器人不需要的工具。如果它不需要代码执行或广泛的数据库访问权限，请移除这些能力。
  • 确定性授权 (Deterministic authorization) – 在应用程序代码中执行权限检查，而不是在语言模型中。模型可以建议一个操作，但由代码决定是否执行该操作。
  • 输出验证 (Output validation) – 在模型响应到达用户之前，扫描其中的所有内容，检查是否存在违规内容——例如系统提示词或敏感数据。

一个仅仅询问“此请求是否被禁止？”的过滤器，很容易被具有说服力的用户绕过。而一个根据封闭列表进行检查的路由层则不留任何商量余地。

下一步该关注什么

依赖对话式 AI 的企业应当针对“炖羊肉食谱测试”所展示的三种失效模式对其部署进行审计。与此同时，请将任何系统提示词视为公开知识；不要指望依靠它来阻止模型泄露自身信息。

结论很明确：如果你的安全模型依赖于一段自然语言指令，那么它是脆弱的。请使用可以被审计、版本化并能无视模型言论而强制执行的代码来强化它。