大模型越狱攻击与安全防御：从原理到三层防线实践

大模型越狱最近频繁出现在技术社区。大模型能够熟练回答复杂问题，并不等同于模型总是按照服务提供者的规则运行。所谓越狱（jailbreak），在 LLM 领域指的是通过精心构造的输入文本，让模型绕过训练阶段建立的安全对齐，输出本应被拒绝的内容。这篇文章从原理、攻击形态、评估指标、防御架构和排查步骤几个角度展开，面向正在做 LLM 应用开发、本地部署大模型、模型微调以及负责 AI 内容安全的团队。读完后，你会得到一套可落地的越狱风险检测和加固思路，而不是只停留在概念层面。

1. 先分清：大模型越狱和普通提示词攻击不是一回事

1.1 “越狱”这个词到底指什么

越狱这个词最早来自终端设备。iPhone 越狱、游戏机越狱，本质都是绕过设备厂商对操作系统或硬件的限制，让设备运行本不被允许的代码。大模型领域借用这个词，指代一种更隐蔽的行为：用户通过构造提示词、上下文或输入格式，绕过模型在训练阶段建立的限制策略，让模型输出违反安全规范的内容。

这里的关键词是“绕过限制”。大模型本身并不天然理解什么可以说什么不能说，而是通过安全对齐训练获得了一套服从规则的倾向。越狱攻击的目标，就是让这套倾向在特定输入下失效。

需要注意的是，越狱不完全等于模型说了不好听的话，也不完全等于模型回答错误。它的核心特征是：模型具备拒绝能力，但攻击者通过改写问题形式，让拒绝机制没有被触发。这个区分对后续评估和防御很重要。

1.2 大模型越狱、提示注入和恶意指令遵循的区别

在实际项目里，越狱经常和另外两个概念混在一起，有必要先分开。

提示注入（prompt injection）偏向于干扰模型执行当前任务，比如让模型忽略前面的指令，去执行输入中夹带的指令。恶意指令遵循则指模型确实错误地执行了危险指令，但未必存在明显的“绕过”过程。越狱更强调对抗安全对齐，它针对的是模型内置的拒绝策略。

下表是三种概念的比较：

三者的边界并不绝对。越狱攻击在实现时往往也依赖提示注入技巧，而恶意指令遵循可能是越狱成功的直接结果。但在设计防御体系时，把它们分开仍然有价值：提示注入主要靠隔离和边界识别，越狱更多靠对齐和对抗样本检测。

1.3 为什么越狱是大模型应用的生产级风险

越狱不只是安全研究者的玩具。一旦大模型被接入生产系统，它就有权限、有工具、有数据，攻击者不再只是“问一个问题”，而是可能让模型执行敏感动作。

具体来说，越狱带来四类生产风险：

• 内容合规风险：模型输出了违反平台规范的内容，导致审核、投诉、下架。
• 数据泄露风险：通过让模型忽略“不要透露系统提示词”的限制，套出内部提示词、工具配置或上下文中的敏感数据。
• 工具滥用风险：模型接了数据库查询、文件读取、邮件发送等工具后，越狱可能让攻击者间接调用这些工具。
• 产品信任风险：反复出现越狱案例会削弱用户对该模型的信任。

越狱问题在多模态模型和 RAG 架构里会更加复杂。多模态模型可以把指令藏在图片或语音中，RAG 场景则可能因为外部文档被投毒，让模型在正常回答问题时被动读取恶意内容。这也是近期大模型领域频繁讨论越狱的原因之一。

2. 越狱能成立，问题出在对齐和生成的对抗上

2.1 安全对齐让模型学会“拒绝”

先要理解大模型为什么有“拒绝”这个行为。大模型在预训练阶段学到的是大量互联网文本的概率分布，目标是把下一句话预测得更合理，此时模型并不关心内容是否合规。完成预训练后，模型需要经过对齐阶段，常见方法包括 RLHF、DPO 等。

对齐阶段会构造大量“安全偏好数据”。比如同一个问题，一个回答是配合危险请求，另一个回答是礼貌拒绝，训练目标就是让模型更倾向于输出后一种。经过这样的训练，模型学习到的是：在特定话题、特定表达方式下，拒绝行为会获得更高的奖励分数。

所以，模型的安全能力不是一条写在代码里的硬规则，而是一个概率偏好。它表现为：当输入足够接近训练中的危险样本时，模型更容易触发拒绝路径；当输入看起来“不那么危险”时，模型则更容易走正常回答路径。

2.2 越狱的本质是让模型重新走上“通用路径”

大模型内部同时存在多个能力路径。面对一个包含危险意图的请求，模型实际上在做两种判断：帮助用户完成请求，还是遵守安全边界。安全对齐希望帮助路径在冲突时被抑制。

越狱攻击要做的事情，就是找出一种输入表述，让模型在判断时认为“这不算危险请求”，从而绕过抑制信号，重新激活通用帮助路径。这也是为什么很多越狱攻击看起来是在“绕弯子”：

• 把问题包装成虚构故事。
• 把目标拆成几步，每一步看起来无害。
• 让模型扮演一个不受限制的角色。
• 用另一种语言或者编码重新表达问题。

这些手法的共同点是：没有修改模型参数，也没有篡改系统指令，只是改变了模型对输入的“危险感知”。所以越狱被称为一种对抗攻击，它所对抗的正是模型的概率化安全判断。

2.3 泛化边界：换一种表达，安全策略就失效

大模型安全对齐面临的根本问题，是有限样本无法覆盖无限表达。模型在训练阶段见过的危险样本，可能集中在某几种语言、某几种话题、某几种角色设定中。一旦攻击者换了攻击面，模型的拒绝机制就可能失效。

典型情况包括：

• 语言迁移：模型训练时主要用英文安全样本，攻击者用中文、日文、多语言混写，拒绝概率明显下降。
• 格式迁移：把请求写成 Base64、凯撒密码、Unicode 变体，模型解码后仍然理解，但安全分类器没有识别。
• 指令层级混淆：把攻击性指令隐藏在系统提示词中，或者伪造“开发者模式”设定，让模型误以为这是更高优先级的要求。

这些现象说明，安全对齐不是一次训练就能解决的问题，而是需要持续补充对抗样本，扩大安全能力的泛化边界。

2.4 开源模型和微调模型的风险更容易放大

比起闭源大模型 API，本地部署的开源模型面临更直接的越狱风险。原因主要有三点：

• 开源模型的原始对齐强度参差不齐，很多 7B、13B 级别的小模型本身拒绝能力就不稳定。
• 微调会破坏对齐。即使是安全的基座模型，在领域数据上继续训练后，原有的安全偏好也可能被稀释。这就是最近的“大模型微调”话题里经常被忽略的安全性提示。
• 本地部署意味着没有平台侧的额外过滤。用 OpenRouter、Ollama、vLLM 部署的模型，输入输出完全由自己负责，所有防御都要自己补。

因此在部署开源模型时，不能默认“这个模型很安全”，而要在每次部署前重新评估越狱风险。模型能力越强，输出越流畅，越狱成功后的破坏力往往也越大。

3. 从防御视角看越狱攻击的常见形态

这一节只从防御和检测的角度介绍形态特征，目的是帮助识别和定位问题，不建议在非安全测试环境中复现。

3.1 角色扮演与虚拟场景类

这是最常见的一类越狱形态。攻击者让模型先进入一个虚拟角色设定，再利用角色本身的设定绕开安全规范。由于模型在判断时会把角色的行为规则识别为高优先级指令，原本应该拒绝的内容就可能被当作“角色说台词”而输出。

防御侧需要重点关注的关键词特征，包括“扮演角色”“虚构世界”“无视之前规则”“开发者模式”“模拟终端”等。检测时不能只依赖关键词，还要结合上下文判断模型是否真的被切换到了高风险角色设定。

3.2 编码、翻译与格式变换类

编码类越狱利用的是模型对多种格式的理解能力。攻击者把危险请求转成 Base64、十六进制、凯撒密码、拼音、Unicode 变体，或者通过多次翻译让文本语义保留但表面形式完全变化。模型仍然能理解，规则过滤却可能漏掉。

这类攻击的检测思路，是寻找明显的编码特征，以及编码文本前后出现的解码指令。如果一段用户输入同时包含“解码”“翻译”“理解后回答”等指令，就需要提高风险等级。

3.3 多轮对话与上下文拆分

单轮提问往往容易被模型拒绝，但把完整请求拆成多个步骤，每一步看起来都安全，模型就可能逐步完成危险链条。例如先确认一个概念，再要求给出实施方案，最后要求替换成具体细节。

在多轮场景中，模型的安全判断不只是针对当前这一条消息，而是结合整个对话历史。攻击者可以在前几轮建立一种“模型已同意配合”的语境，让后续请求的拒绝概率下降。防御这类攻击，必须对多轮上下文做整体风险评估，而不是只看单条消息。

3.4 多模态与工具调用新增的攻击面

多模态越狱是最近讨论较多的一块。图片、音频、视频都可以携带文本中不易识别的指令。模型把图片中的文字识别出来后，如果按识别结果执行，图片上的恶意文本就绕过了文本输入过滤。语音也存在类似问题。

工具调用场景更危险。模型在 AI Agent 架构中已经具备调用数据库、文件、网络请求的能力。攻击者一旦越狱，目标就变成让模型执行某个工具调用，而不是让模型“说出一段话”。因此需要把工具调用的参数校验和 API 权限控制提升到和输入过滤同等的优先级。

3.5 越狱形态识别速查表

4. 用指标和数据评估模型的抗越狱能力

4.1 公开基准与数据集

评估模型是否容易被越狱，不能只靠几个人手工提问。目前研究社区已经有公开数据集和基准，常见的有 HarmBench、AdvBench、JailbreakBench、SafetyBench 等。这些基准通常包含大量对抗样本，覆盖不同语言和攻击手法。

使用公开基准时要注意两点：

• 数据集更新速度快，新攻击手法出现后，旧数据集的覆盖能力会下降。
• 不同基准对“越狱成功”的判定标准可能不同，不能直接跨基准对比数值。

更好的做法是把公开基准作为基础集，再根据自己业务场景补充一批自定义对抗样本。

4.2 红队测试的最小流程

无论用开源模型还是 API 模型，建议至少按以下流程做一次抗越狱评估：

1. 划定测试范围：确定哪些模型版本、哪些能力模块需要覆盖。
2. 准备基线用例：从公开基准中选取一个子集，再加入 20 到 50 条业务相关风险用例。
3. 定义判定标准：明确什么样的回答算违规，什么样的拒绝算有效。
4. 执行测试：可以用脚本自动调用模型接口，也可以交给人工红队做补充。
5. 汇总指标：计算越狱成功率、拒答率、拦截率等。
6. 复盘：对每条成功样本做根因归类，确定是模型对齐问题还是外部过滤问题。

4.3 越狱成功率与拒答率怎么算

越狱成功率通常叫 JSR，全称 Jailbreak Success Rate。实际评估中，还会计算拒绝率和拦截率。一个最小统计函数可以写成：

def compute_attack_metrics(results: list[dict]) -> dict: total = len(results) if total == 0: return { "jsr": 0.0, "refusal_rate": 0.0, "block_rate": 0.0, "total": 0, } success = sum( 1 for r in results if r.get("violation") and not r.get("blocked") ) refused = sum(1 for r in results if r.get("refused")) blocked = sum(1 for r in results if r.get("blocked")) return { "jsr": success / total, "refusal_rate": refused / total, "block_rate": blocked / total, "total": total, }

调用场景大致如下：

test_results = [ {"violation": True, "blocked": False, "refused": False}, {"violation": False, "blocked": False, "refused": True}, {"violation": True, "blocked": True, "refused": False}, ] print(compute_attack_metrics(test_results))

输出为：

{'jsr': 0.3333333333333333, 'refusal_rate': 0.3333333333333333, 'block_rate': 0.3333333333333333, 'total': 3}

要注意：如果应用层已经拦截了一条违规提问，那么这条请求应该算作“拦截”，不应该混入 JSR 统计。JSR 描述的是突破全部防线之后的成功率，而不是模型内部对抗的成功率。

4.4 评估中的典型误判

评估抗越狱能力时，有几种常见误判需要避免。

第一，只测单条攻击文本，不考虑多轮对话。很多越狱手法要在多轮环境下才能生效，单轮评估会严重低估风险。

第二，用关键词过滤结果代替模型判断。如果应用层用了脏词过滤，测试集里大量样本可能被直接拦截，导致 JSR 看起来很低，但模型本身的抗攻击能力并没有提升。

第三，让模型自己给自己的回答打分。模型裁判（LLM-as-a-judge）在判断“这段话是否违反安全规范”时，也可能被越狱。最好设置一个独立、不与主模型共享上下文的评审流程。

第四，忽略业务语境的特殊性。对一个客服机器人来说，用户提到“退款”是正常业务；对一个内容创作工具来说，用户要求生成恐怖小说可能是合法需求。评估用例必须结合业务边界，否则容易误报。

5. 模型、应用、网关三层防线怎么搭

大模型越狱没有单点解药。生产环境建议采用三层防线：模型层、应用层、网关层。每一层解决不同的问题，不能互相替代。

5.1 模型侧：对齐、微调与安全训练

模型层是第一步，也是最底层的一步。要提升抗越狱能力，可以从几个方向入手：

• 使用对齐程度更高的基座模型。在选型时不仅要看榜单分数，还要看安全评测结果。
• 在微调数据中加入安全样本，使用 DPO 等偏好优化方法，在保持业务能力的同时调整安全偏好。
• 建立对抗样本迭代机制。每次越狱事件后，把脱敏样本加入训练数据，形成“发现-修复-回归”的循环。

对已经微调过的模型，不要直接沿用基座模型的安全指标。微调后必须重新跑一遍安全测试，尤其是原本表现良好的拒绝能力可能被新数据稀释。

5.2 应用侧：输入清洗与输出过滤

应用层负责在模型前处理后输出后处理。输入侧可以加入提示注入检测器，输出侧可以加入违规内容分类器。

一个最小化输出过滤逻辑可用伪代码表示：

def review_model_output(text: str, config: dict) -> dict: if contains_pii(text, config.get("pii_rules", [])): return {"decision": "mask", "reason": "pii"} if contains_unsafe_content(text, config.get("safety_rules", [])): return {"decision": "block", "reason": "unsafe"} return {"decision": "pass", "reason": "ok"}

实际落地时，判断逻辑可以依赖三类能力：

• 规则库：明确的敏感词、占位符、正则规则。
• 小型分类模型：适合做文本风险分类，如赌博、色情、暴力等。
• 大模型裁判：适合做语义级判断，但需要防止裁判模型本身被注入。

这里要强调：输出过滤不能只做“坏了再拦”，还要把高风险提问记录到日志中，用于后续分析。

5.3 网关侧：限流、审计与告警

网关层负责请求的入口管控和事后审计。如果要部署本地大模型，建议在模型服务前方加一层网关，统一处理鉴权、限流、日志、告警。

网关日志建议记录以下字段：

{ "request_id": "req_8f21", "user_id": "u_10086", "model": "demo-llama-3-8b", "prompt_preview": "cut-off text before current request", "detected_zones": ["role_play", "encoded_scheme"], "risk_score": 0.82, "decision": "block", "created_at": "2025-01-01T10:00:00.000Z" }

网关不需要承担太多语义判断，它更擅长做：

• 频率控制：同一用户短时间高频提交相似内容，触发告警。
• 敏感链路审计：记录哪些用户访问了能力较强的模型。
• 灰度策略：新模型先小流量，再逐步放开。

5.4 三层防线覆盖对照表

三层配合的正确姿势是：模型层做基础安全能力，应用层做业务安全兜底，网关层做运营安全监控。千万不要只依赖一层。

6. 部署后遇到越狱样本怎么排查

6.1 先记录现象再碰模型

生产环境中发现疑似越狱，第一件事不是去模型里反复试 prompt，而是把现象完整记录下来。

需要记录的信息包括：

• 用户输入原文和完整对话上下文。
• 系统提示词版本和模型版本。
• 命中的过滤规则和未命中的规则。
• 模型的完整输出或输出截断。
• 会话时间、用户标识、请求 ID。

这些信息决定了后续能否定位根因。缺少上下文的越狱样本，排查难度会成倍增加。

6.2 从日志还原上下文

越狱往往多轮生效。单看最后一条消息，可能看不出任何问题。排查时要从日志中还原完整上下文，观察攻击节奏。

一个典型的日志分析思路如下：

{ "request_id": "req_8f21", "step": 3, "user_input": "continue the previous reply", "previous_turns": [ {"role": "user", "text": "role play setup..."}, {"role": "assistant", "text": "accepted role..."} ], "risk_indicators": ["role_play_setup_captured"] }

排查时注意看前几轮是否包含角色设定、虚构场景、开发者模式等高风险指令。很多越狱是在多轮铺垫后才发动的。

6.3 定位根因的四个检查点

如果确认发生了越狱，建议按以下四个点逐一检查：

1. 系统提示词是否被泄露或覆盖？检查模型是否输出了内部提示词内容。
2. 输入侧过滤器是否被绕过？检查编码类、翻译类输入是否绕过了规则。
3. 模型自身是否对齐不足？把同样的问题换回正常表达，看模型能否拒绝。
4. 微调是否破坏了安全能力？对比同版本基座模型与微调模型在同一测试集上的表现。

6.4 应急处理与后续回归

应急处理时，优先降低损失：下线高危工具、收紧模型权限、增加人工审核比例。不要急着改模型，除非已经能稳定复现。

处理完成后，要把样本加入回归集，之后每次模型升级、微调、提示词改动都要重新跑一遍。建议维护一个“越狱回归用例表”：

这张表就是团队在模型安全上的长期资产。越狱防护不是一次评审能结束的，而是每一次升级都要重复执行的常态化动作。

7. 给大模型团队的安全实践建议

7.1 把安全评估写进发布门禁

大模型项目的发布流程里，安全评估应该和功能测试、性能压测并列，而不能作为上线后补救项。

推荐的最小门禁包含：

• 静态检查：检查系统提示词是否包含敏感信息或过度授权表述。
• 动态测试：核心模型版本必须跑一次对抗样本回归集。
• 权限复核：所有工具调用的权限范围必须和最小权限原则对齐。
• 监控配置：确保高风险输入、异常模型输出已经接入告警。

7.2 不要为了安全把模型调成复读机

防御过度同样存在问题。如果输出过滤器经常把正常业务内容误判为违规，用户很快就会放弃产品。越狱防御的目标是降低风险，不是消除所有“有一点风险”的回答。

平衡手段包括：

• 分场景设置安全等级，客服、教育、创作工具可以使用不同敏感度。
• 对低风险内容采用“放行但打标”策略，保留人工复核入口。
• 定期分析过滤器误报样本，持续优化规则和分类模型。

7.3 学习路线：从提示词工程到大模型安全

如果你刚接触大模型，想深入越狱防护，可以参考以下顺序：

1. 先会部署模型：用 Ollama 或 vLLM 本地部署一个大模型，理解模型输入输出链路。
2. 再做提示词工程：掌握角色设定、指令优先级、上下文管理，这些是安全边界设计的基础。
3. 再理解对齐：读 RLHF、DPO 相关材料，明白模型拒绝行为是怎么来的。
4. 再做安全评测：尝试用公开基准跑一次越狱评估，计算 JSR。
5. 最后做防御工程：把模型、应用、网关三层防线落到自己的部署环境里。

大模型越狱是模型能力和安全策略的持续对抗。对开发者来说，真正有用的不是记住几条攻击案例，而是建立一套“能评估、能检测、能响应、能回归”的完整机制。模型会持续迭代，越狱手法也会持续变化，但只要评估和防御链路始终在运转，风险就能被控制在可接受范围内。