Appearance
02. Prompt Injection、越狱与提示词泄露
版本：
v1.1最后更新：
2026-07-08适用对象：已经在做 LLM、RAG、Agent 或浏览器/文档类工作流，希望把
prompt injection、jailbreak、prompt leak这些最常见但也最容易误解的风险拆清楚的团队
AI 安全里最常被提到、也最容易被低估的一组风险就是：
- prompt injection
- jailbreak
- prompt leak
- 间接注入
很多团队知道这些词，但真正落地时还是会回到一句话：
- “把 system prompt 写得更强一点”
这通常不够。
1. 先分清四个相近但不同的问题
1.1 Prompt Injection
OWASP 当前 LLM01:2025 Prompt Injection 把它定义成：
- 攻击者通过输入改变模型行为，使其偏离原本的系统目标或安全边界
它强调的是：
输入改变行为
1.2 Jailbreak
Anthropic 当前 Mitigate jailbreaks and prompt injections 把 jailbreak 和 prompt injection 放在同一组风险里，但更强调：
- 诱导模型忽略既有规则
- 绕过原本的使用限制
它更像：
对齐与规则绕过
1.3 Prompt Leak
Anthropic 当前 Reduce prompt leak 提醒：
- 不能保证提示词绝对不泄露
- 更现实的目标是降低泄露概率和泄露后的伤害
它强调的是：
隐藏规则或系统提示被暴露
1.4 间接注入
这类风险不是用户正面说：
- “忽略之前规则”
而是把恶意指令埋在：
- 上传文档
- 网页
- 邮件
- 工具返回文本
- OCR 识别结果
模型读到这些内容时，会把“证据文本”和“指令文本”混在一起理解。
2. 为什么这些风险在 Agent 和 RAG 里更危险
普通聊天系统里，最坏结果常常还是：
- 回答偏了
但一旦接入：
- 检索
- 浏览器
- shell
- 文件系统
- MCP 工具
- 写操作连接器
问题就会升级成：
- 错误动作
- 越权读取
- 信息外发
- 配置改写
- 连锁故障
OpenAI 当前 Safety in building agents 明确强调：
- 高风险工具要保留审批
- 输入要做 guardrails
- 工具调用不要默认放开
2.1 从“答偏了”到“执行错了”，中间其实有一条升级链
更实用的风险理解通常不是只看最终事故，而是看它是怎么升级的：
- 不可信文本进入上下文
- 模型把它理解成更高优先级指令
- 路由、检索或工具选择开始偏移
- 高风险工具或高权限路径被触发
- 审批、校验或人工 review 没接住
也就是说，prompt injection 真正危险的地方不只是：
- “模型被说服了”
而是：
- “模型被说服之后，系统有没有把这种偏移放大成真实副作用”
2.2 RAG、Browser、Computer Use、MCP 会把攻击面从“文本框”扩成“整条环境”
OpenAI 当前 Safety in building agents、Anthropic 当前 Computer use、Mitigate jailbreaks and prompt injections 放在一起看，一个很重要的现实是：
- 攻击者不需要直接和你的 system prompt 对抗
他可以把攻击面埋进：
- 检索库
- 网页正文
- OCR 文字
- 邮件线程
- MCP / connector 返回值
- 屏幕截图
这意味着很多系统真正需要治理的不是：
- 一个聊天框
而是一整条“环境输入链”。
3. 直接注入和间接注入的差异
3.1 直接注入
最典型的形式是用户显式输入：
- 忽略前文
- 泄露系统提示词
- 代替管理员执行操作
3.2 间接注入
更麻烦，因为攻击文本不是来自当前用户问题，而是来自上下文材料：
- “文档最后一页埋了恶意说明”
- “网页正文里混了伪指令”
- “截图 OCR 出来的隐藏文字带指令”
这类风险在：
- 浏览器代理
- 文档问答
- 邮件处理
- 工单自动化
里特别常见。
4. 为什么“把提示词写得更强”不是根本解法
Prompt 工程当然重要，但它解决不了两个结构性问题：
4.1 模型看见的仍然是同一种语言内容
模型内部没有天然“系统区”和“证据区”的硬隔离。
4.2 真实副作用发生在运行时，而不是文本里
即使 prompt 把风险降低了，只要：
- 工具权限过大
- 审批没加
- 参数没校验
风险仍然会落地成真实动作。
所以更可靠的策略必须分层：
- 输入分层
- 上下文标记
- 工具最小权限
- 输出校验
- 审批和回滚
4.1 更稳的系统，通常会显式区分“内容通道”和“控制通道”
OpenAI 当前 Safety in building agents 明确提醒不要把不可信变量直接塞进 developer messages；Anthropic 当前 Mitigate jailbreaks and prompt injections 也强调把系统提示、文档和用户消息分开构造。
这背后的关键不是格式洁癖，而是：
- 不同通道应该有不同信任等级
一个更稳的心智通常是：
控制通道- system / developer rules
- tool policy
- approval requirements
内容通道- 用户问题
- 检索片段
- 网页正文
- OCR / ASR
- 第三方返回文本
如果两者混成一段自由文本，后面几乎一定会出现：
- 模型把证据当指令
- 把指令当事实
4.2 Structured outputs 的价值，不只是“格式好看”
OpenAI 当前 Safety in building agents 把 structured outputs 当作缩窄数据流的一种核心手段。
这对 prompt injection 很关键，因为很多攻击依赖：
- 自由文本可以一路向下游传播
更稳的做法通常是：
- 上游只产生结构化字段
- 下游只消费白名单字段
- 高风险动作只接受枚举值、限定字符串或明确 schema
也就是说，structured outputs 真正减少的是：
- 攻击文本在系统里“自由流动”的空间
5. 什么内容默认应该视为低信任
一个更稳的默认值是：
- 用户自然语言输入
- 上传文档
- 检索片段
- 网页内容
- 外部 API 返回的自由文本
- OCR / ASR 结果
都默认属于：
低信任内容
这些内容可以用于：
- 提供事实
- 提供上下文
但不应天然拥有：
- 改写系统规则
- 提升权限
- 直接触发高风险动作
5.1 更稳的默认值是：所有外部自由文本都先按“可疑内容”处理
很多团队只把“用户输入”视为不可信，但真实系统里更危险的往往是：
- 来自别的系统、看起来更像“内部资料”的文本
例如：
- CRM 备注
- 邮件转发链
- 内部 Wiki 片段
- 网页 DOM 文本
- 文档页脚
- OCR 隐藏字
这些内容因为“看起来像系统材料”，更容易被误信。
所以更稳的默认值通常不是：
- “内部材料就可信”
而是：
- “所有自由文本先按低信任处理，再按来源逐层提升可信度”
5.2 元数据和来源标签本身也是防线的一部分
对 RAG / Browser / 文档系统来说，更实用的设计通常还会给内容附上：
- 来源系统
- 来源租户
- 审核状态
- 最后更新时间
- 内容类型
- 是否允许触发动作
这样模型或编排层至少还有机会区分：
- 这是可引用事实
- 还是只是未经验证的上下文片段
6. 最值得先做的四种防线
6.1 上下文分段与显式标记
不要把系统规则、工具说明、检索结果、用户输入揉成一大段。
更稳的做法是：
- 系统规则单独段落
- 工具规则单独段落
- 外部证据单独段落
- 用标签说明“以下是低信任材料”
6.2 高风险动作审批
OpenAI 当前 agents 审批与 guardrails 文档明确说明：
- guardrails 负责自动检查
- human review 负责敏感动作批准
这意味着：
- 就算模型被诱导，也不要让它直接拥有高风险最终执行权
6.3 结构化参数提取与校验
不要把自由文本直接拼成：
- shell 命令
- SQL
- HTTP 写请求
- 业务系统写操作
更可靠的方式是：
- 先结构化抽取
- 再做白名单和范围校验
6.4 工具最小权限
不同角色、不同任务桶，暴露的工具应不同。
不要让“会读文档的 Agent”和“能改生产配置的 Agent”共用同一工具集。
6.5 检索与浏览链路最好有“内容隔离层”
很多系统会直接把检索文本或网页正文原样拼进 prompt。
更稳的做法通常是中间先过一层：
- 来源判别
- 去噪 / 去模板
- 指令性语句筛查
- 高风险片段标记
它不一定能完全识别恶意内容，但能显著减少下面这种情况：
- 文档里的“请忽略之前规则”
- 和真正业务知识一起进入高优先级上下文
6.6 Guardrails 更适合做“先拦”，审批更适合做“最后裁决”
OpenAI 当前 Guardrails and human review 已经把这两类控制拆得很清楚：
- guardrails 做自动检查
- human review 做批准决策
放到注入风险里，一个更稳的顺序通常是：
- 先识别可疑输入或可疑中间结果
- 先阻断明显危险的动作链
- 剩余高风险情况再进入审批或人工确认
如果把所有问题都交给人工 review，团队很快会遇到：
- 噪音过多
- 真正危险 case 淹没在普通样本里
7. Prompt Leak 真正该防什么
Anthropic 当前文档的核心启发很实用：
- 与其执着于“绝对不泄露”，不如优先降低泄露后的伤害
所以真正要防的是：
- 把密钥写进 prompt
- 把访问控制只写在 prompt
- 把审批策略只藏在 prompt
更好的方式是：
- 密钥永不进 prompt
- 权限在运行时控制
- 审批在流程层控制
- 日志避免回显 system prompt
7.1 Prompt leak 防不住时，最关键的是“泄露后还能不能继续作恶”
Anthropic 当前 Reduce prompt leak 的核心启发非常实用：
- 目标不是幻想绝对不泄露
- 而是降低泄露概率，并降低泄露后的伤害
这意味着团队真正该优先检查的是：
- prompt 泄露后，是否还能直接拿到密钥
- prompt 泄露后，是否还能直接提升权限
- prompt 泄露后，是否能绕过审批链
- prompt 泄露后，是否暴露了太多内部风控逻辑
也就是说，prompt leak 真正的减伤重点通常是：
prompt 泄了，也不该让攻击者一下子拿到系统控制权
7.2 更稳的做法通常是把“秘密”和“策略”从 prompt 里外移
例如：
- 秘钥放密钥系统，不进 prompt
- 权限判断放工具层，不写成提示词约束
- 审批要求放工作流层，不只放在 system prompt 里
- 风险分级放策略引擎，不让 prompt 承担唯一责任
这样就算 prompt 被回显了，暴露的通常也更像：
- 工作指令风格
而不是：
- 直接可利用的控制面
8. 对 RAG 来说最危险的不是“查错”，而是“把恶意材料查进来”
RAG 系统里，prompt injection 的一个高风险版本是：
- 恶意材料被当成可信证据召回
这时要优先看：
- 数据源信任级
- 文档审核链
- metadata 标记
- 检索范围隔离
- 引用展示和证据分层
否则系统可能会把：
- “伪指令”
当成：
- “知识内容”
8.1 更值得优先隔离的是“可执行信号”和“解释性证据”
很多 RAG 系统默认把文档片段同时用于：
- 回答生成
- 动作判断
这是很危险的，因为注入文本最想做的事情之一，就是把：
- 解释性证据
伪装成：
- 可执行指令
更稳的做法通常是：
- 文档片段用于解释和引用
- 高风险动作仍需走独立策略或审批判断
换句话说：
- 证据可以影响答案
- 但不该直接决定高风险执行
9. 浏览器、电脑操作和截图类 Agent 的特别风险
Anthropic 当前 computer use 文档提到：
- 对截图里的 prompt injection 需要额外防御
- 某些情况下需要强制用户确认
这对可视化代理很关键，因为它意味着：
- 屏幕上的文本本身就可能是攻击面
所以对这类系统，更稳的控制通常包括：
- 对敏感动作要求确认
- 不让截图文字直接变成高权限动作
- 关键操作前做二次展示和复核
9.1 屏幕文本、网页 DOM 和 OCR 结果都应被视为可注入媒介
Anthropic 当前 Computer use 文档特别强调：
- 先看 mitigation 指南再给登录凭据
- 某些截图场景会触发额外分类器并要求确认
这说明视觉或浏览器代理的风险不是：
- 只是“看到了页面”
而是：
- 页面本身就可能在教模型做错事
所以对这类代理系统，更稳的默认值通常是：
- 所有屏幕文本都先按低信任处理
- 高风险点击或输入前必须再次确认
- 登录态和高权限动作尽量分离
10. 红队样例应该怎么设计
至少建议覆盖：
10.1 直接越狱
- 忽略前文
- 假装内部人员
- 请求输出隐藏提示
10.2 间接注入
- 恶意网页
- 恶意文档
- 恶意邮件
- 恶意 OCR 文本
10.3 提示词泄露
- 直接索取 system prompt
- 间接诱导回显规则
10.4 上下文污染
- 检索材料要求模型改变角色
- 外部文本冒充系统指令
10.5 截图 / OCR / 浏览器注入桶
- 页面按钮旁埋隐藏指令
- OCR 识别结果含伪管理员要求
- 恶意网页把“继续操作”包装成业务提示
10.6 Prompt leak 减伤桶
- 请求回显 developer prompt
- 间接诱导总结内部规则
- 让模型输出工具说明或审批规则
这类样例非常适合长期保留，因为它们能直接验证：
- 你的防线到底是“真分层了”
- 还是只是“提示词写得像分层了”
11. 什么情况下应该优先停用而不是继续调 Prompt
如果已经出现下面这些现象，更适合先熔断或降权：
- 高风险工具被诱导触发
- 检索材料可直接改写动作意图
- prompt leak 已暴露敏感规则
- 同一类注入持续复现
这时继续“修文案”通常不是最稳的第一反应。
11.1 一旦涉及真实副作用，默认先降权、隔离或转人工
更稳的处置顺序通常是：
- 先停高风险工具或写动作
- 先把相关桶切成只读、草稿或人工确认
- 再分析 prompt、上下文和策略哪里失守
这比一边让事故继续发生、一边改 prompt 要稳得多。
12. 常见反模式
- 把所有防御都堆进一段系统提示词。
- 把外部材料直接贴在系统规则旁边，不做分段。
- 工具参数直接由自然语言拼接，不做 schema 校验。
- 以为只要 moderation 开着，就能防 prompt injection。
- prompt 被泄露后，仍然依赖 prompt 继续承担权限控制。
- 把网页、OCR、邮件正文当成天然可信业务文本。
- 检索证据既参与回答又直接参与高风险动作决策。
- prompt 泄露后还能直接暴露控制逻辑、审批路径或内部敏感规则。
13. 推荐搭配阅读
14. 重点官方资料
以下资源已按 2026-07-08 复核可访问：