第二章：Prompt Injection、Jailbreak 与系统提示泄漏

2.1 三者的关系与边界

这三类攻击经常被混用，但目标不同，建模和防御方式也不同：

三者常常组合出现：一次越狱可能同时是为了让模型「忘记」系统提示里的限制，其结果又可能顺带泄漏系统提示内容。架构级的根因——模型无法从结构上区分指令与数据——已在 Agent 安全 15.2 讲清楚，也是 OWASP LLM01（Prompt Injection）的核心描述；这里直接看三类攻击各自的技术分类，以及系统提示泄漏该怎么单独处理。

flowchart TB
    ROOT["模型无法区分指令与数据
见 Agent 安全 15.2"] --> PI[Prompt Injection]
    ROOT --> JB[Jailbreak]
    PI --> SPL[系统提示泄漏]
    JB --> SPL

2.2 Prompt Injection 的分类回顾与本章补充

直接注入（攻击者是当前用户本人）与间接注入（攻击载荷藏在第三方内容中）的定义、致命三要素和架构级防御，详见 Agent 安全 15.4-15.10 与 RAG 安全 20.3.2。这里补两个前面没展开、但在生产里经常漏掉的点：载荷编码方式和多轮/多 Agent 场景下的注入放大。

2.2.1 载荷编码与混淆

同一条注入指令可以用多种编码方式规避基于关键词的检测：

这些手法的共同点是：试图逃过输入侧的静态检测，因此纯粹依赖关键词或正则的输入过滤必然会被绕过，需要配合 Agent 安全 15.8-15.10 中的架构级隔离作为主防线，编码检测只是纵深防御的一层。

2.2.2 多轮与多 Agent 场景下的放大

单轮防御到位后，攻击者会转向利用对话历史和多 Agent 协作：

• 多轮蚕食（Crescendo）：从无害话题逐步引导，每一轮都只轻微越界，利用模型对连续上下文的服从倾向，最终达成单轮会被直接拒绝的目标；
• 上下文污染：先在早期轮次让模型「确认」一个虚假前提或虚假身份，后续轮次基于这个被污染的上下文做出不当响应；
• 跨 Agent 传染：在多 Agent 系统中，注入载荷通过一个 Agent 的输出传给下一个 Agent，每一跳都可能被当作「上游 Agent 的可信输出」而降低警惕——这是 Agent 安全 15.6.4 提到的多 Agent 混淆代理问题的另一种表现形式。

防御上，多轮场景需要对完整对话历史（而非单轮消息）做异常检测，例如监控话题漂移速度、权限请求频率的突增；多 Agent 场景需要在每一跳之间重新做来源标注和权限校验，而不是假设「上一个 Agent 已经处理过」。

2.3 Jailbreak 技术分类

Jailbreak 与 Prompt Injection 的区别在于：越狱通常不需要第三方载荷，攻击者本人就是发起者，目标是让模型突破自身的安全对齐（而不是执行「另一个任务」）。

flowchart TB
    J[Jailbreak 技术] --> J1[角色扮演类
DAN / 虚构人格]
    J --> J2[情境包装类
学术研究/小说创作/调试模式]
    J --> J3[多轮蚕食类
Crescendo]
    J --> J4[对抗后缀类
自动化搜索出的低可读性后缀]
    J --> J5[Many-shot 类
大量示例填满上下文诱导模仿]

防御要点：

• 安全对齐训练（RLHF/宪法式 AI）本身是第一道防线，但不能假设它是完备的——学术界持续发现新的越狱手法，说明对齐是概率性缓解而非确定性边界；
• 输出侧护栏模型（见 Agent 安全 15.13.3）可以在生成后二次判定，作为对齐失效时的补位；
• 长上下文场景需要限制单次可注入的「示例」数量和结构模式识别，防范 Many-shot 攻击；
• 越狱检测应作为持续对抗过程运营（见第九章红队部分），而不是一次性上线前测试。

2.4 系统提示泄漏

2.4.1 为什么系统提示泄漏是独立风险

OWASP 将其单列为 LLM07（System Prompt Leakage），原因是很多团队默认「系统提示词是保密的」，把业务规则、内部工具名称、限制条件甚至临时性的安全补丁都写进系统提示，一旦泄漏：

• 攻击者获得了绕过防御所需的「地图」——知道哪些关键词被禁止、哪些工具存在、审批阈值是多少；
• 如果系统提示里意外包含了凭据、内部 URL 或未脱敏的业务逻辑，会直接构成敏感信息泄漏（对应 OWASP LLM02）；
• 竞争对手可以复制业务的核心 Prompt 工程成果。

2.4.2 常见抽取手法

2.4.3 正确的设计原则：把系统提示当作不可靠的保密边界

唯一可靠的防御是不要依赖系统提示的保密性来实现安全控制。 具体做法：

• 真正的授权、敏感阈值、密钥判断逻辑放在系统提示之外的确定性代码里执行，系统提示只做行为引导，即使泄漏也不改变安全后果；
• 不在系统提示中写入凭据、内部主机名、未脱敏的客户数据或竞争性商业机密；
• 输出侧增加对「逐字复述系统提示」模式的检测，作为纵深防御而非唯一防线；
• 如果业务确实需要保密 Prompt 工程细节（例如商业竞争考虑），应认识到这是尽力而为的混淆，而不是安全边界，不能把安全控制建立在它之上。

这与 Tool Protocol 安全 15.6.1 「不要把 Agent Card/Tool description 当成授权证明」是同一类思路的推广：任何进入模型上下文、由模型输出或复述的内容，都不能作为安全决策的唯一依据。

2.5 检测与运营层面的建议

• 对输入和输出同时做异常检测：输入侧关注编码混淆特征（高熵字符串、语言切换、超长 Few-shot 示例），输出侧关注是否出现了系统提示片段、越权内容或与业务无关的敏感话题；
• 维护越狱和注入的样本库，定期跑回归（详见第九章），因为对齐模型的行为会随版本更新变化，旧的防御可能对新版本模型失效或过度触发；
• 记录（但脱敏后记录）触发防御的原始输入，用于分析攻击趋势，同时避免日志本身成为敏感信息泄漏点。

2.6 常见错误

2.6.1 认为系统提示是保密的安全边界

系统提示的保密性无法保证，真正的授权判断必须在模型上下文之外的确定性代码中完成。

2.6.2 只做关键词过滤应对编码混淆

Base64、同形字、语言混合等编码方式可以绕过任何静态关键词表，必须配合架构级隔离。

2.6.3 只测单轮越狱

多轮蚕食和上下文污染在单轮测试中完全测不出来，红队测试必须包含多轮对话场景。

2.6.4 把越狱防御当作一次性上线检查项

模型版本更新、新越狱手法公开都会让既有防御失效，需要持续运营（见第九章）。

2.7 本章总结

1. Prompt Injection、Jailbreak、系统提示泄漏目标不同但常常组合出现，共同根因是模型无法从结构上区分指令与数据（详见 Agent 安全）；
2. Prompt Injection 的载荷可以用 Base64、同形字、语言混合、分段拼接等方式编码，纯关键词过滤必被绕过；多轮蚕食和跨 Agent 传染是常被忽视的放大路径；
3. Jailbreak 手法可分为角色扮演、情境包装、多轮蚕食、对抗后缀和 Many-shot 五类，安全对齐是概率性缓解而非确定性边界；
4. 系统提示泄漏被 OWASP 单列为 LLM07，唯一可靠的防御是不把安全控制建立在系统提示保密性之上；
5. 检测与红队需要覆盖多轮对话和持续更新的攻击样本库，而不是一次性静态测试。

参考资料

• OWASP LLM01:2025 Prompt Injection
• OWASP LLM07:2025 System Prompt Leakage
• Many-shot Jailbreaking (Anthropic)
• Universal and Transferable Adversarial Attacks on Aligned Language Models
• Ignore This Title and HackAPrompt: Exposing Systemic Vulnerabilities of LLMs
• MITRE ATLAS: Prompt Injection