越狱(Jailbreak)到底是什么?
越狱(Jailbreak)指用户不依赖任何第三方内容,直接通过精心设计的对话——虚构场景、角色扮演、分步诱导等方式——尝试说服大模型自己突破安全对齐训练划定的行为边界,输出其本应拒绝的内容。它和利用不可信输入的 Prompt 注入是两类不同的问题,分清这个区别,是给应用做安全设计的前提。
越狱和 Prompt 注入的本质区别是什么?
这两个词经常被放在一起讨论,原因是后果看起来相似:模型都做了不该做的事。但攻击链条完全不同。越狱里,唯一的输入方就是当前会话里的用户本人,他清楚自己在尝试什么,整个过程不需要任何外部素材参与。Prompt 注入则相反,恶意指令通常藏在用户之外的第三方内容里——一个网页、一封邮件、一份文档,或者某次工具调用返回的结果——模型在正常处理任务时把这段内容当成了指令来执行,发起请求的用户往往对此毫不知情,甚至他本人也是受害者。
越狱的发起者和输入来源跟 Prompt 注入有什么不同?
越狱的发起者就是坐在对话另一端的人,输入完全来自他自己敲下的文字,不存在“内容”和“指令”被混淆的问题——用户说的每一句话本来就是指令。Prompt 注入恰恰依赖这种混淆:应用把外部内容当作数据传给模型,模型却分不清哪些是需要处理的素材、哪些是需要执行的命令,注入者利用的正是这条模糊地带。
越狱突破的是谁设定的行为边界?
越狱瞄准的是模型厂商在训练阶段划定的边界,也就是安全对齐设定的“什么内容可以生成、什么必须拒绝”。Prompt 注入瞄准的则是应用开发者在系统提示词里设定的任务边界,比如“只回答订单相关问题”“不要执行外部指令”。二者攻击的是两套不同的规则,防御的责任方也不一样。
模型厂商在安全对齐(Alignment)上做了哪些工作?
模型能识别并拒绝越狱尝试,靠的不是一条写死的规则,而是训练阶段投入的系统性工作,业内通称为安全对齐(alignment)。
安全对齐训练具体让模型学会了什么?
常见做法大致分两层:先用人工标注的示例做监督微调,让模型见识大量“应该拒绝”和“应该正常回应”的样例;再叠加基于人类反馈的强化学习等机制,用一个反映人类偏好的奖励信号持续调整模型的输出倾向。部分厂商还会引入让模型依据一套书面原则自我审视、自我修正的方法,降低对大规模人工标注的依赖。这些方法共同的目标,是让模型面对边界模糊的请求时倾向做出符合安全策略的判断,而不是单纯服从表面指令。
红队测试和拒答校准在对齐里扮演什么角色?
训练完成后,厂商通常会组织内部或外部的红队,专门尝试各种诱导思路找出模型的薄弱环节,再把发现的问题反馈回训练数据做针对性修补,这是一个持续迭代的过程,不是一次性动作。同时厂商要在“拒绝过度”和“该拒绝没拒绝”之间做校准——挡得太多会让模型在正常任务上变得难用,挡得太少边界就形同虚设,这个平衡点会随模型版本推移不断调整。
安全对齐能不能彻底杜绝越狱?
不能。安全对齐本质上是一种统计意义上的行为倾向,不是可以形式化证明的硬性规则,训练数据也不可能穷尽所有话术组合和场景包装方式。新的诱导思路在模型发布后仍会不断被发现,厂商再通过后续更新修补,这是持续的攻防过程,不是发布即终结的状态。不同厂商、不同模型版本在拒答尺度上存在差异,这属于产品策略的选择,不构成谁更优的评判。
为什么开发者不能完全依赖模型自身的安全对齐?
安全对齐解决的是模型本身“该不该说”的问题,但一个真实的应用远不止“模型说了什么”这一层,还包括这段输出会触发什么后续动作、面向什么用户群体、处于什么业务场景,这些都是模型厂商在训练时无法预知的变量。
对齐训练的边界为什么会随应用场景漂移?
厂商的安全对齐针对的是通用、宽泛的行为标准,而每个应用实际需要的边界是产品特定的:面向未成年人的教育产品、承载自动化操作的编程助手、直接调用支付接口的客服机器人,各自需要收紧的尺度完全不同。厂商不可能替每一个下游应用预先训练出它专属的边界,这部分判断只能由开发者自己在应用层补上。
API 网关这类中间层场景为什么让风险被放大?
通过网关按量调用模型的应用,拿到的是一次性的补全结果,不携带模型厂商自有产品里可能具备的额外上下文或平台侧防护。也就是说,应用开发者拿到的能力边界基本就是模型本身的边界,中间不会有厂商替你多做一层过滤。如果应用又把模型输出直接接到发邮件、改数据库、下单支付这类真实动作上,一次没被拦下的越狱就不再只是一段尴尬的聊天记录,而会变成真实的业务事故。
应用层应该怎么建立自己的防御边界?
既然模型层的对齐不构成可以完全托底的保证,应用层就需要建立独立的第二道防线,核心思路有两条:兜底审查模型说出来的内容,以及限制模型能碰到的高风险操作。
输出审核兜底具体应该审什么?
在把模型输出返回给用户或者交给下游动作执行之前,加一层独立的审核判断——可以是专门的内容审核接口,可以是规则匹配,也可以是一次不携带原对话诱导性上下文的独立模型调用,专门判断“这段输出是否违反本应用的策略”。关键在于这层审核不能和产生输出的那次调用共享同一段被诱导过的上下文,否则审核本身也可能被同一套话术绕过。
怎么限制模型能触达的高风险操作范围?
比输出审核更根本的一层,是从权限设计上收紧模型能直接触发的动作范围。给模型驱动的流程分配凭证和工具时按实际需要配置,不预留不必要的能力;任何不可逆或高风险的动作——转账、删除数据、对外发送信息、修改权限——都应该经过应用层的确定性校验,而不是完全交给模型自行判断是否合适。下面是几项常见的应用层防御措施:
- 输出审核兜底:独立于生成过程之外的二次内容判断,拦截漏网的违规输出
- 高风险操作权限收紧:模型可调用的工具和凭证按实际需要配置,不预留冗余能力
- 关键动作人工确认:涉及资金、权限变更等场景引入人工审核节点,不做全自动放行
- 异常调用模式监控:对短时间内密集尝试、话术反复变体等行为设置告警和限流
“安全与合规”系列五篇文章共同构成了什么样的防护体系?
把本支柱已发布的五篇内容放在一起看,大致是一套从输入到输出、从凭证到数据的分层防护:Prompt 注入关注模型如何被第三方不可信内容误导,API Key 管理关注调用凭证本身的发放与限权,内容审核关注请求与响应内容的合规判断,数据隐私关注哪些数据流经模型、该如何留存与限制范围,本篇越狱则补上了模型自身安全边界这一层认知——它足够重要,但从来不是唯一的一道防线。
这五篇文章分别把关的是哪一层?
可以粗略对应到五个不同的关注点:输入内容是否可信、调用凭证是否收紧、内容本身是否合规、数据流向是否可控,以及模型自身的行为边界是否可能被诱导突破。任何一层单独存在都不足以构成完整防护,合在一起才是一套可以落地的工程实践。
总结
越狱考验的是模型自身的安全对齐,Prompt 注入考验的是应用如何隔离不可信内容,两者需要不同的防御设计。开发者应把模型对齐当作第一道而非唯一一道防线,在输出审核与操作权限上建立自己的兜底机制。
