前方高能，一大波LLM投毒攻击袭来
很多人一提到 LLM 安全，首先想到的是 prompt injection：用户一句“忽略以上所有指令”，模型就开始跑偏。这个认知不能说错，但远远不够。对于今天的 AI system，尤其是带 RAG、memory、tool calling、MCP、workflow orchestration 的 agent system 来说，“投毒攻击”早就不是单点问题，而是整条 pipeline 的系统性攻击面。
如果把一个现代 LLM 应用拆开看，它至少包含这些层：输入层、检索层、记忆层、工具层、模型层、训练与微调层、反馈闭环层，以及越来越常见的多模态入口。攻击者未必非要直接攻破模型参数，只要能在任意一层植入“高置信度但有偏导向”的内容，就可能让系统在后续链路中持续放大错误，最终表现为泄露、误操作、越权调用、错误决策，甚至“带着安全外观的自主偏航”。
所以，“投毒”更准确的理解是：向 AI 系统未来会信任、读取、检索、继承或学习的介质中，注入恶意内容或恶意结构。下面按类别拆开看。
1. Prompt injection 与 indirect prompt injection
这是最靠近“上下文入口”的一类攻击。前者通常直接出现在用户输入中；后者则藏在模型会读取的外部内容里，比如网页、PDF、工单、邮件、知识库页面、代码注释等。
它的核心不是“修改模型参数”，而是污染模型当下的推理上下文。典型载体包括：
- 用户消息中的越权指令
- 网页正文、隐藏文本、HTML 注释
- 文档中的“请忽略开发者提示词”类文本
- 工具返回结果中夹带的自然语言指令
危害主要体现在：泄露 system prompt、绕过策略、诱导调用工具、改变回答目标、让 agent 将“不可信文本”误当成“高优先级指令”。
它和后面几类的区别在于：prompt injection 作用于本轮或短期上下文决策；如果没有写回 memory、知识库或训练集，理论上影响范围相对短。
2. RAG / retrieval poisoning
RAG poisoning 不是直接攻击模型，而是攻击“模型信任的检索语料”。当系统从知识库、搜索索引、企业文档或外部网页中召回内容时，攻击者可以通过提前埋入恶意文档，让检索结果天然偏向错误结论或危险指令。
典型载体包括：
- 被污染的 FAQ、Wiki、内部文档
- SEO/搜索操纵后的外部网页
- 语义相似度很高但内容带偏的“对抗文档”
- 伪造的操作手册、伪知识条目
这类攻击的关键点在于：它利用的是“被检索到”这件事本身带来的信任感。用户会以为模型“查过资料”，系统也会把检索内容包装成 grounding evidence。与 prompt injection 相比，RAG poisoning 更像是“给模型喂错资料”，强调的是知识来源的污染，而不是单轮指令覆盖。
3. Memory / context poisoning
很多 agent 会把用户偏好、任务历史、环境状态、长期摘要写入 memory。问题是，一旦 memory 写入策略不严，攻击者就能把恶意内容“升级”为持久上下文。
典型场景包括：
- 诱导 agent 记住错误偏好或错误身份信息
- 在长期记忆中植入高风险操作建议
- 利用摘要压缩，把恶意结论固化成后续会反复引用的背景事实
- 在共享会话上下文中混入误导性的 state
这类攻击的危险之处在于持久性。prompt injection 可能只影响一轮，但 memory poisoning 会让错误跨轮存在，甚至在未来任务中被再次激活。它和 RAG poisoning 的区别也很明显：RAG 污染的是“外部被检索知识”，memory 污染的是“系统对自己用户与任务历史的内部认知”。
4. Tool / MCP metadata poisoning
这是 agent 时代非常值得重视的一类。模型不只读自然语言，它还会读取工具说明、参数 schema、MCP server 的 metadata、resource 描述、capability 文档。只要这些元信息被污染，模型就可能在“看似合法”的接口层被误导。
典型载体包括：
- 工具 description 中夹带误导性指令
- 参数说明把高危参数包装成安全选项
- MCP resource 内容中掺入 prompt-like 文本
- tool result 返回中把“数据”伪装成“下一步该做什么”
它和普通 prompt injection 的区别在于：这里的恶意内容披着“系统接口说明”的外衣。由于 agent 天然要依赖 tool spec 来决定调用路径，metadata poisoning 往往更隐蔽，也更容易触发真实外部动作，比如发消息、改文档、执行命令、转账、创建工单等。
5. Training data poisoning
这是更底层、更长期的一类攻击。攻击者试图污染 pretraining corpus 或持续训练语料，让模型在统计分布层面学到偏差、后门或错误关联。
典型载体包括：
- 大规模爬虫可抓取的公开文本
- 数据供应链中的清洗前原始语料
- 被批量伪造、重复发布的特定模式文本
这类攻击不一定表现为“每次都触发”，更可能表现为某些 trigger、某类实体、某种模式下的稳定偏向。它和 prompt / RAG 的根本区别在于：前几类是在推理阶段污染输入，training poisoning 则试图在参数层改变模型本身。
6. Fine-tuning / instruction tuning poisoning
如果说 training poisoning 是“污染大池子”，那 fine-tuning poisoning 更像“污染最后一公里”。企业往往会做 domain fine-tuning、instruction tuning、alignment tuning；一旦样本来源不干净、标注流程不可信，模型会被定向塑形。
典型风险包括：
- 把错误的安全边界标成“高质量示范”
- 在 instruction-following 数据中注入偏置响应模板
- 用少量高权重样本把某些危险行为包装成“ helpful ”
与 training poisoning 相比，fine-tuning poisoning 更容易影响具体产品人格、拒答边界和执行偏好。它不一定改掉通识能力，但很可能改掉“最后会怎么做”。
7. Embedding / vector store poisoning
这一类常被误归到 RAG poisoning，但最好单独看。因为它攻击的不只是文档内容，还包括向量化与召回机制本身。
典型方式包括：
- 构造语义上异常“粘人”的文本，使其对大量查询都高相似
- 通过 chunk 切分技巧，把恶意指令嵌入高相关片段
- 在 metadata filter、namespace、tag 上做污染，影响候选集范围
- 批量灌入相似向量，挤占召回空间
与一般 RAG poisoning 相比，embedding / vector store poisoning 更偏“检索基础设施层”。前者强调内容真假，后者强调为什么这些内容总能被召回、总排得靠前、总在正确问题上出现错误答案。
8. Multimodal / OCR / image poisoning
当模型开始看图、读截图、跑 OCR、理解 PDF 扫描件后，攻击面又扩大了一圈。恶意内容不一定以清晰文本出现，也可能藏在图像、水印、版式、背景纹理、局部小字甚至视觉上不显眼的区域中。
典型载体包括：
- 截图中的隐藏指令或小号字体文本
- 扫描件 OCR 误识别后形成的危险语句
- 图片里嵌入与任务强相关的诱导内容
- 多模态文档中“文字可信、图像带偏”的混合攻击
它和文本 prompt injection 的差别在于：输入经过了 OCR、captioning、layout parsing 等中间层，污染可能发生在“感知—转写—理解”的任何一步。工程上也更难做简单的规则过滤。
9. Feedback-loop / self-improvement poisoning
这是最容易被低估、也最接近“系统性失控”味道的一类。许多 AI 产品会把用户反馈、自动评估、模型自生成样本、agent 执行日志重新喂回系统，用于排序、策略优化、自动改写 prompt、更新知识库，甚至进入后续训练。
如果这个反馈闭环被污染，攻击者就能把一次性的错误变成“被系统认可的经验”。
典型方式包括：
- 刷假反馈，让危险行为被打成高分
- 让模型自评、自改、自蒸馏时继承错误偏好
- 把异常执行结果写回知识库，形成二次传播
- 利用自动化 A/B 或 policy update，把局部漏洞升级成全局行为改变
它和 memory poisoning 的区别在于：memory 更像单个 agent 的长期记忆；feedback-loop poisoning 针对的是系统用于自我更新的机制，影响范围更广，更可能演化成供应链级问题。
为什么 agent system 比普通 chat 更危险
普通 chat 模型大多只“说错话”；agent system 则可能“做错事”。一旦模型连接检索、记忆、文件系统、浏览器、数据库、支付、消息发送、代码执行，攻击面就从内容安全扩展到行为安全。
更麻烦的是，agent system 存在天然的跨层传播：
- 一个 indirect prompt injection 可以进入 RAG 结果
- 一段错误 RAG 内容可能被写入 memory
- 被污染的 memory 又会影响下一轮 tool selection
- 工具结果再被记录进日志或反馈系统，形成闭环放大
这就是为什么 agent 安全不能只靠“在入口加一句不要相信用户”。真正要防的是链式污染、权限放大和持久化继承。
工程防御 checklist
如果只能给一份实践建议，我会把重点放在“分层隔离 + 明确信任边界 + 默认不继承”。
输入与上下文层
- 明确区分 instruction、data、tool output、retrieved content，不要混成同一优先级文本
- 对外部内容做 untrusted 标记，让模型和编排层都知道其来源
- 对 prompt injection 做检测，但不要把检测当唯一防线
检索与知识库层
- 建立文档来源分级、签名、审核与回滚机制
- 对高风险知识源做 allowlist，而不是无限开放抓取
- 检查向量库的异常召回、相似度集中、批量灌入行为
Memory 与状态层
- 严格限制什么内容可以写入长期 memory
- 把“用户说过”与“系统确认事实”分开存储
- 对摘要写回、自动记忆、跨会话继承设置人工或规则审查
Tool / MCP 层
- 不把 tool description 当可信指令源
- 对高风险工具执行做 policy gate、参数校验和二次确认
- 工具返回结果尽量结构化，减少自然语言自由污染
模型与训练层
- 训练、微调、偏好数据都要做来源治理与抽检
- 不把线上日志、用户反馈直接无清洗回灌训练
- 对持续学习链路保留可审计性、回滚点和灰度发布能力
Agent 编排层
- 最小权限原则：能读不写，能写不执行，能执行不出网
- 关键动作要求显式确认，不要让模型自己给自己放权
- 做好 step-level tracing，能定位“污染是从哪一层进来的”
结语
LLM 的“投毒攻击”真正可怕的地方，不在于某个神奇 payload 能一句话攻破所有系统，而在于现代 AI pipeline 天生就是一个会读取、继承、复述、检索、调用、再学习的复合体。只要其中某一层把不可信内容当成可信依据，污染就会顺着链路扩散。
因此，讨论 AI 安全时，别只盯着 prompt。要盯的是整个系统：谁能写入、谁会被检索、谁能进入记忆、谁能触发工具、谁又会被拿去训练下一代模型。把这些边界画清楚，LLM/Agent 安全才会真正从“玄学对抗”走向“工程治理”。
