RAG投毒与MCP协议安全

4433 字
0 浏览

RAG投毒与MCP协议安全

适用范围：LLM 应用安全、Agent 安全、RAG 安全、工具调用安全
整理日期：2026-05-24
这篇笔记的目标：把 RAG投毒 和 MCP协议安全 这两个经常一起出现、但本质不同的概念彻底分开讲清楚。

一、先用一句话区分

  • RAG投毒：攻击者污染模型在推理时会检索到的知识、记忆或上下文。
  • MCP协议安全：保护模型通过 MCP 连接外部工具、资源和服务时的身份、授权、会话和执行边界。

可以直接这样记：

RAG投毒关注“模型读到了什么”，MCP协议安全关注“模型连到了什么、能做什么”。

二、什么是 RAG 投毒

1. 基本定义

RAG（Retrieval-Augmented Generation，检索增强生成）的核心机制是：

  1. 先根据用户问题去知识库、文档库、向量库中检索相关内容
  2. 再把检索结果作为上下文喂给 LLM
  3. 最后由模型基于这些上下文生成答案

RAG 投毒就是攻击者想办法让 恶意、错误、带偏见或带隐藏指令的内容 进入这条检索链路，使模型在回答时读到被污染的内容。

这类攻击并不一定去修改模型参数本身，而是修改 模型推理时会读取的外部上下文。

2. RAG 投毒投的到底是什么

RAG 投毒的对象通常包括：

  • 原始知识文档
  • FAQ、Wiki、共享文档、邮件、网页缓存
  • 向量库中的 chunk
  • embedding 生成前后的处理流水线
  • Agent 的长期记忆、共享记忆、总结记忆
  • 被系统默认信任的外部数据源

OWASP 在 2025 的 LLM01 Prompt Injection 页面给了一个很直观的场景：
攻击者修改了一个被 RAG 应用使用的文档仓库内容，当用户查询命中这份内容时，恶意指令会改变 LLM 的输出，导致误导性结果。
来源：OWASP LLM01:2025 Prompt Injection

OWASP 2026 Agentic Top 10 里又把这类问题进一步放到 ASI06: Memory & Context Poisoning 下，明确把 summaries、embeddings 和 RAG stores 都纳入上下文污染的范围。
来源：OWASP Top 10 for Agentic Applications 2026

3. 典型攻击路径

路径 1：污染知识源

攻击者把伪造内容塞进系统会收录的知识源，例如：

  • 企业 Wiki
  • 共享云文档
  • 工单系统
  • 可被抓取的网站
  • 邮件和附件

如果系统自动抓取并入库，这些内容就可能被 embedding 后进入向量库。

路径 2：直接污染向量库或上传入口

例如：

  • 恶意用户直接上传文件
  • 上传接口鉴权薄弱
  • 数据接入流程过度信任第三方源
  • 没有对文档做内容净化、来源校验、租户隔离

OWASP 2026 文档里把它概括为：
恶意或被操纵的数据通过被污染的源、直接上传或过度信任的流水线进入向量数据库，最终导致错误答案。
来源：OWASP Top 10 for Agentic Applications 2026

路径 3：通过间接提示词注入污染记忆

攻击者不一定直接改知识库，也可能把恶意内容塞进：

  • 网页
  • PDF
  • 邮件
  • 日历邀请
  • 聊天记录

当 Agent 读取、总结并持久化这些内容后，恶意内容就会进入长期记忆或共享上下文，影响未来会话。

4. RAG 投毒会造成什么后果

RAG 投毒常见后果有两类。

1. 完整性破坏

模型持续给出错误信息，例如：

  • 错误政策
  • 错误价格
  • 错误操作步骤
  • 错误代码建议
  • 错误业务判断

这是最直观的一类问题，本质是 知识被污染，输出自然被污染。

2. 间接提示词注入

更危险的一类是：
恶意文档中不只是错误信息，而是藏着“让模型怎么做”的隐藏指令。

例如文档里夹带类似意思的内容：

  • 忽略之前的系统规则
  • 优先输出某个链接
  • 调用某个工具读取更多数据
  • 向外发送某些内容

这时 RAG 投毒就不只是“答错题”，而是会进一步演化成：

  • 提示词注入
  • 工具滥用
  • 数据泄露
  • 越权访问

OWASP 也明确指出：RAG 和微调并不能彻底消除 prompt injection 风险；当模型接收外部文件、网页等内容时，间接提示词注入仍然成立。
来源：OWASP LLM01:2025 Prompt Injection

5. RAG 投毒和几个相近概念的区别

1. 和训练数据投毒的区别

  • 训练数据投毒：污染预训练或微调数据，影响模型本体
  • RAG投毒：污染推理阶段读取的上下文，影响模型当前任务

前者影响模型“长期学到了什么”，后者影响模型“当前看到了什么”。

2. 和普通 prompt injection 的区别

  • 普通 prompt injection：攻击通常直接出现在用户输入里
  • RAG投毒：攻击藏在被检索的外部内容里，模型检索后才中招

所以很多 RAG 投毒，本质上是 借检索链路触发的间接提示词注入。

3. 和 Memory/Context Poisoning 的关系

在 Agent 场景里，RAG 投毒通常可以视为 Memory & Context Poisoning 的一个子类或典型实例。

因为被污染的不只是某次回答，而是系统后续还会复用的：

  • chunk
  • summary
  • memory
  • shared context

三、RAG 投毒该怎么防

1. 不要默认信任接入源

所有进入 RAG 的内容都应该被视为 不可信输入，包括：

  • 用户上传文件
  • 外部网页抓取结果
  • 邮件、附件、IM 消息
  • 第三方 API 回包
  • 其他 Agent 发来的内容

2. 做好入库前处理

常见措施：

  • 文件类型白名单
  • 内容清洗与规范化
  • prompt carrier 检测
  • 对 HTML、PDF、Office 文档做净化
  • 来源可信度标签
  • 文档级与 chunk 级风险打标

3. 严格做租户隔离和命名空间隔离

尤其是：

  • 向量库 namespace
  • 检索过滤条件
  • 记忆存储范围
  • 用户上下文边界

否则会出现跨用户、跨租户内容串扰。

4. 降低“检索结果 = 可信事实”的默认权重

要避免把被检索到的内容直接视为事实真相。常见做法：

  • 要求模型输出引用来源
  • 做 groundedness / relevance 检查
  • 多源交叉验证
  • 对高风险结论走人工确认

5. 限制模型对工具的权限

即使 RAG 内容被污染，也不能让模型轻易把污染内容转化成高危动作。

例如：

  • 读取敏感数据
  • 发邮件
  • 对外请求
  • 改数据库
  • 执行代码

这类能力都需要最小权限、参数约束和高风险动作确认。

四、什么是 MCP 协议安全

1. MCP 是什么

这里的 MCP 指 Model Context Protocol。

MCP 官方把它描述为一种让 AI 应用连接外部工具、资源和提示模板的开放协议。其核心架构是：

  • Host
  • Client
  • Server

官方架构文档明确指出，MCP 采用 client-host-server architecture，并强调 Host 负责连接权限、用户授权和安全边界，Client 对不同 Server 连接保持隔离，Server 可以是本地进程，也可以是远程服务。
来源：MCP Architecture

这意味着 MCP 安全本质上不是“模型回答是否安全”，而是：

当模型通过协议接入外部能力时，身份、授权、隔离、会话和调用边界是否安全。

2. 为什么 MCP 会成为安全问题

一旦 LLM 不只是“说”，而是能通过 MCP：

  • 读文件
  • 读数据库
  • 请求 SaaS
  • 调内部 API
  • 触发自动化流程

那么风险就从“错误回答”升级成“错误行动”。

这也是为什么 MCP 安全本质上属于 Agent 工具调用安全 的重要组成部分。

3. MCP 协议安全主要在保护什么

可以把 MCP 安全拆成 5 个核心点：

1. 身份

  • 连过来的 client 到底是谁
  • server 信不信这个 client
  • 用户身份有没有被正确映射

2. 授权

  • 谁能调用哪个 server
  • token scope 是否过大
  • 是否按最小权限发放

3. 会话

  • session ID 是否安全
  • 是否可被猜测、复用、劫持
  • 多 server、多连接下边界是否清晰

4. 隔离

  • 一个 server 能看到多少上下文
  • 能不能看到别的 server 不该看的内容
  • 本地 server 和远程 server 的权限边界是否明确

5. 动作边界

  • 模型是否能被诱导去调用不该调用的工具
  • 参数是否被滥用
  • 返回结果是否会继续污染后续决策

五、MCP 官方文档重点提到的风险

以下内容基于 MCP 官方文档中可直接找到的安全章节。

1. OAuth 2.1、PKCE、HTTPS 和重定向校验

MCP 授权规范明确要求：

  • 实现必须基于 OAuth 2.1
  • PKCE 对所有 client 都是必需项
  • 授权端点必须使用 HTTPS
  • server 必须校验 redirect URI

这些要求的目的很明确：
防止 token 被截获、授权流程被劫持、重定向被利用。

来源：MCP Authorization

2. Token Passthrough

MCP 官方明确把 token passthrough 定义为一种反模式：
server 接收来自 client 的 token，但不验证这些 token 是否真的是签发给自己使用的，然后直接把 token 转发给下游 API。

这会带来：

  • 绕过安全控制
  • 审计追踪失效
  • audience 边界失效
  • 下游 API 被错误地暴露给上游调用者

来源：MCP Security Best Practices

3. Confused Deputy

如果 MCP server 作为代理去连接第三方 API，就可能出现典型的 confused deputy 问题：

  • 攻击者利用代理型 server 的授权流程
  • 让它代表错误对象拿到授权码或 token
  • 最终越权访问第三方服务

官方建议的重点防护是：
按 client 做明确的 consent，不能只做粗粒度授权。

来源：MCP Security Best Practices

4. SSRF

MCP 文档专门把 SSRF 列为需要关注的风险。
如果 server 发现机制、回调 URL、资源 URL 或重定向链校验不严，攻击者可能借 client/server 发起对：

  • localhost
  • 内网地址
  • 云 metadata 服务
  • 只在企业网络内可访问的接口

的访问。

这类问题在“模型可自动发请求”的环境里尤其危险。

来源：MCP Security Best Practices

5. Session Hijacking

MCP 文档把会话劫持描述为：
server 给 client 分配了一个 session ID，而未授权方拿到这个 session ID 后，冒充原始 client 执行操作。

在多 stateful server 场景里，这可能进一步演化成：

  • 事件注入
  • 重放
  • 冒名恢复会话

官方建议包括：

  • session 不能用于认证
  • session ID 必须安全、随机、不可预测
  • 所有入站请求都要验证

来源：MCP Security Best Practices

6. 本地 MCP Server 风险

MCP 官方明确提醒：
本地 MCP server 运行在用户机器上，可能直接接触文件系统、系统进程、浏览器状态、本地凭据，也可能被同机其他进程接触。

文档列出的本地风险包括：

  • 恶意 startup 命令
  • 恶意 server 负载
  • 没有沙箱时直接接触用户系统
  • DNS rebinding 访问留在 localhost 的不安全服务

所以本地 MCP server 的安装、启动、授权和沙箱策略都非常关键。

来源：MCP Security Best Practices

六、MCP 安全的本质理解

如果只从概念上理解，可以把 MCP 安全看成下面这句话：

它不是保护“模型说错话”，而是保护“模型借助协议和工具做错事”。

也就是说，MCP 安全面对的核心问题包括：

  • 错连
  • 越权
  • 滥用
  • 劫持
  • 穿透边界
  • 本地权限升级

七、RAG投毒和 MCP 协议安全是怎么串起来的

真正危险的地方，往往不是单点漏洞，而是 攻击链。

1
2
3
4
5
6

flowchart LR
    A["攻击者污染文档/网页/记忆"] --> B["RAG 检索命中恶意内容"]
    B --> C["LLM 把恶意内容当作上下文"]
    C --> D["间接提示词注入/目标偏移"]
    D --> E["通过 MCP 调用工具/资源/API"]
    E --> F["数据泄露、越权操作、错误行动"]

这条链路的含义是：

  1. 攻击者先投毒 RAG 或记忆层
  2. 被污染内容进入模型上下文
  3. 模型被诱导改变行为
  4. 如果它又接着拥有 MCP 工具权限
  5. 那么问题就从“答错”升级成“做错”

所以从防守角度看：

  • RAG投毒 是上下文完整性问题
  • MCP安全 是工具执行边界问题

两边都做好，系统才稳。

八、工程上该怎么做

1. 对 RAG 层

  • 任何接入源都按不可信处理
  • 做来源校验和可信度分级
  • 做内容净化、风险打标和 prompt carrier 检测
  • 做向量库 namespace 隔离和租户隔离
  • 高风险回答要求引用和交叉验证
  • 重要动作不能仅凭被检索内容直接触发

2. 对 MCP 层

  • 严格使用 OAuth 2.1、PKCE、HTTPS
  • 最小权限 scope
  • 不做 token passthrough
  • 对 redirect URI、metadata discovery、回调做严格校验
  • 本地 server 默认不可信，要求显式同意和沙箱
  • 工具调用参数做 allowlist、schema 校验和二次确认

3. 对 Agent 层

  • 把“知识输入”和“工具权限”分开建模
  • 高危工具调用增加 human-in-the-loop
  • 做完整日志、审计和告警
  • 对多 Agent / 共享记忆场景做额外隔离

九、最适合记忆的极简版

一句话版

  • RAG投毒：污染模型会检索到的上下文
  • MCP协议安全：保护模型连接工具和资源时的权限边界

风险版

  • RAG投毒的核心风险：把模型带偏
  • MCP安全的核心风险：让模型越权行动

联动版

  • 被污染的 RAG 内容可以触发间接提示词注入
  • 被诱导的模型可能再通过 MCP 调用高权限工具
  • 所以两者组合后，风险会从“错误输出”升级成“真实破坏”

十、最后总结

在 LLM 安全里，这两个概念最好这样理解：

  • RAG投毒 是“上下文被污染”
  • MCP协议安全 是“工具连接和授权边界是否安全”

前者主要解决：

  • 模型看到什么
  • 模型是否被错误知识或隐藏指令带偏

后者主要解决：

  • 模型能连什么
  • 模型能调用什么
  • 调用时身份、token、会话和权限是否被正确约束

如果系统既用了 RAG，又用了 MCP 工具，那么最危险的不是单独某一层，而是：

恶意内容先进入上下文，再借助工具权限变成真实动作。

这就是为什么在 Agent 安全里，RAG安全、Prompt Injection、防越权工具调用、MCP权限设计 必须一起看。

参考资料

Licensed under CC BY-NC-SA 4.0
2026 ChenOvo