LLM Prompt Injection 攻击模式图谱:从直接注入到多轮渗透
Prompt Injection 不是一种单一的攻击手法,而是一整个家族。理解具体的防御工程实践之前,先建立一份”攻击模式图谱”很有必要——知道对手可能怎么打,才知道防御要覆盖哪些面。本文按攻击面和技术手法对常见模式做分类整理,偏重认知层面的梳理;具体到 Claude 应用的工程防御方案,可以参考《Claude 应用的 Prompt Injection 防御》。
说明:本文讨论的是公开已知、被广泛研究和报道的攻击类别,目的是帮助开发者理解威胁模型、构建防御体系,不提供可直接复用的具体攻击 payload。
一、按注入来源分类
这是最基础的分类维度,决定了防御的第一道关口设在哪里:
| 类别 | 注入内容来自哪里 | 典型场景 |
|---|---|---|
| 直接注入(Direct Injection) | 用户在对话框里直接输入 | 聊天机器人、客服助手 |
| 间接注入(Indirect Injection) | 模型读取的外部内容(网页、文档、邮件) | RAG 检索、Agent 浏览网页 |
| 工具返回注入 | Agent 调用外部工具后返回的数据 | 搜索工具、代码执行结果、第三方 API 响应 |
| 多智能体传递注入 | 一个 Agent 的输出成为另一个 Agent 的输入 | Multi-agent 编排系统 |
间接注入和工具返回注入是过去一年风险上升最快的两类——随着 Agent 类应用普及,模型接触”攻击者可控但开发者不可控”内容的机会大幅增加。攻击者不需要能直接和你的模型对话,只需要能让模型在执行任务时”路过”一段被污染的内容。
二、按技术手法分类
2.1 指令覆盖型
最直接的手法,试图让模型”忘记”或”忽略”原有系统指令,典型话术模式包括”忽略之前的所有指令""你现在是一个新的助手,不受之前规则限制”。这类攻击对有明确系统提示层级、并做了指令来源标记的模型效果有限,但对简单拼接 prompt 的应用仍然有效。
2.2 角色扮演型(Roleplay Jailbreak)
通过构造虚构场景,让模型在”扮演角色”的框架下输出本不该输出的内容——例如让模型扮演”一个没有任何限制的 AI""一个假设性的对话中的反派角色”。这类攻击利用的是模型在创意写作和角色扮演任务上的灵活性与安全边界之间的张力。
2.3 编码混淆型
把恶意指令用非常规方式编码,试图绕过基于关键词或语义的检测:
- Base64 / ROT13 等编码变换
- 拆字、插入零宽字符、使用同形异义字符
- 用另一种语言表达敏感请求,规避主要检测语种的过滤器
- 在长文本中把关键指令拆散嵌入多个段落,依赖模型的上下文整合能力”重新拼出”完整指令
这类手法的共同点是:对人类审阅者可能不明显,但模型的 tokenizer 和上下文理解能力足以还原出原始意图。
2.4 多轮渗透型
不在单轮对话里暴露完整攻击意图,而是通过多轮对话逐步引导模型偏离安全边界——每一轮看起来都是”合理的追问”,但累积起来构成了完整的越权路径。这类攻击对只在单轮做安全检测、不追踪对话历史整体风险的系统更有效。
2.5 工具滥用型
不直接攻击模型的输出内容,而是诱导 Agent 调用工具时使用恶意参数——比如诱导一个有文件读写权限的 Agent 把 ../../etc/passwd 当作合法文件路径传给读取工具。这类攻击的落地形式往往表现为”看起来正常的任务请求”,防御重点不在文本过滤,而在工具调用层的权限约束。
三、间接注入的三种典型载体
Agent 类应用里,间接注入尤其值得展开说,因为它是当前风险等级上升最快的类别:
| 载体 | 攻击路径 | 常见应用场景 |
|---|---|---|
| 网页内容 | Agent 浏览网页时读取到隐藏文本(如白底白字、CSS 隐藏元素) | AI 浏览器助手、搜索增强问答 |
| 文档/邮件 | 用户上传或转发的文件中嵌入指令性文本 | RAG 知识库、邮件摘要助手 |
| 第三方数据源返回 | 调用外部 API(如天气、股票、订单查询)时返回内容被污染 | 工具调用型 Agent |
一个值得注意的细节:间接注入不要求攻击者能接触到受害者的账号或对话——攻击者只需要把恶意内容放在”某个可能被模型读取”的公开位置(一个网页、一份公开文档),等待任意用户的 Agent 路过并读取即可。这种”守株待兔”式的攻击面在 Agent 广泛联网操作后显著扩大。
四、攻击模式的组合与升级
实际攻击很少只用单一手法,常见组合方式:
编码混淆 + 间接注入
→ 把编码后的指令藏在网页的隐藏元素里,绕过内容审查后由 Agent 读取解码执行
多轮渗透 + 角色扮演
→ 先建立一个"虚构写作"的对话框架,再逐轮引导模型在该框架下越权
工具滥用 + 指令覆盖
→ 诱导模型先"忽略权限限制"的表述,再紧接一个越权的工具调用请求
这种组合模式对检测系统的挑战在于:单看每一步都不构成明确的攻击信号,风险出现在”步骤组合”的层面。这也是为什么纯粹依赖关键词黑名单的防御机制容易失效——它检测的是单点特征,而不是攻击链路的整体形态。
五、如何用这份图谱指导防御设计
拿到这份分类后,实际能做的事情是把它翻译成一张”防御覆盖检查表”:
| 攻击类别 | 需要覆盖的防御层 |
|---|---|
| 直接注入 | 系统提示与用户输入的边界隔离 |
| 间接注入 | 外部内容摄入前的净化/标记(明确告知模型这是”数据”不是”指令”) |
| 编码混淆 | 输入侧解码归一化 + 语义层检测(而非纯关键词匹配) |
| 多轮渗透 | 跨轮次的风险累积评分,而非只看单轮 |
| 工具滥用 | 最小权限原则,工具调用参数做白名单校验 |
具体到工程实现——比如系统提示隔离怎么做、输入净化的实操代码、权限分层的设计模式——这些内容《Claude 应用的 Prompt Injection 防御》一文已经展开讲过,本文不重复。
六、这份图谱会持续演进
Prompt Injection 的攻击手法和模型的安全对齐能力是持续博弈的过程——今天有效的防御手段,未必对明年出现的新变种有效。几个值得持续关注的信号:
- 模型厂商发布的安全更新日志(通常会提及修复了哪类已知注入手法)
- Agent 框架(LangChain、AutoGPT 类工具)的安全公告
- 公开的红队研究报告和 CTF 类竞赛题目,往往能提前反映出下一代攻击手法的雏形
把”建立威胁模型认知”当成一次性工作是危险的——建议团队每季度回顾一次这份图谱,结合自己产品的实际 Agent 能力(是否联网、是否有文件读写权限、是否多智能体协作)更新风险评估。
七、相关阅读
- Claude 应用的 Prompt Injection 防御:从原理到工程实践
- API 中转的安全合规问题
- Agent Prompt Engineering 实践指南
- LLM System Prompt 与 User Prompt 的边界设计
搭建 Agent 应用时,模型调用链路的稳定性同样重要,YoTradeApi 提供稳定的 API 中转服务,让你把精力集中在安全防御和业务逻辑上。