AI攻防 AIRT补充篇|侦察指纹 · 多模态越狱 · Agent 与 MCP 安全

📄 本笔记整理自个人学习笔记，一句话概括：课程教的是"已知目标怎么打"，这一篇补的是打之前和打之后最容易踩空的四件事------先确认对面是不是 LLM、攻击面已经溢出到像素和声波、Agent 要按"链"测而不是按点测、MCP 的安全边界根本不在协议层。

全篇沿一条主线展开： ** 侦察（1）→ 视觉（2）→ 音频（3）→ 信息量分层（4）→ Agent 链（5）→ MCP 选型（6/7）→ MCP 攻击面（8）→ 收束（9）** 前四章是"打之前"，五六七章是"怎么接进去"，第八章是"接进去之后谁在裸奔"。

---

🗺️ 〇、一页速览

#	章节	回答的问题
1	侦察与目标指纹	对面到底是不是 LLM？是的话是哪一族？
2	多模态视觉注入	攻击面怎么从文本层溢出到像素层
3	音频越狱	声学层为什么是"下游对齐的前置缺口"
4	黑盒 / 灰盒 / 白盒	信息量如何决定攻击手法的设计空间
5	Agent 与多智能体	为什么必须"测链不测点"
6	MCP 能力模型与传输选型	三原语谁控制；30 秒超时的真相
7	从零搭一个 MCP Server	四步走通，以及授权该写在哪
8	MCP 的三大攻击面	描述投毒 / 混淆代理 / 传输与配置
9	总结与延伸	速查卡 + 参考文献 + 局限性

📌 阅读建议：第 1 章最容易被跳过 （不做侦察就把越狱话术丢给关键词机器人，等于对自动售货机念咒语）；第 3、8 章是本笔记投入校对最多的地方；第 5 章的"测链"是 Agent 安全的方法论核心。

📌 本篇与前面模块的关系：M2 的提示注入在这里退化成一个前置判断 （对面有没有接收自由文本指令的能力）；M3 的 RAG 投毒在这里变成 Agent 记忆/知识库这一攻击面 ；M4 的多智能体在这里给出了可操作的七面速查 + 六步测法；M6 的"模型窃取"与本篇的"模型指纹"是同一枚硬币的两面------一个取资产，一个认资产。

---

🔍 一、侦察：先确认对面是不是 LLM

1.1 为什么侦察是必要的前置步骤

传统客服机器人的底座是关键词匹配、决策树或 FAQ 检索------用户输入必须与预设词库高度重合才触发回复。对它做"请用鲁迅口吻写点评"或"把列表转成 JSON"，它要么返回兜底话术（"抱歉，我没听懂"），要么根本无法解析指令结构。

对它做提示注入，就像对一台自动售货机念咒语：它不存在接收和处理自由文本指令的机制。

所以侦察的目的不是"确认它好不好攻击"，而是确认它是否具备被注入的前提条件------存在一个接收自然语言、按语义而非关键词响应的模型。

  传统机器人（关键词 / 决策树 / FAQ 检索）
      用户输入 --> 关键词匹配 --> 命中? --> 预设话术
      未命中   --> 兜底话术："我没听懂" / 转人工
      ※ 注入在这里没有任何着力点
​
  LLM（语义解析 + 生成）
      用户输入 --> 语义理解 --> 自由文本响应
      ※ 指令会被"执行"，注入才有意义

1.2 判别法一：文风模仿测试

"请用鲁迅的口吻写一段关于'服务器崩了'的点评。"

	真 LLM	传统机器人
能否识别"文风"这一抽象维度	能	不能
输出	半文半白、反讽语气、"大概是......的确......横竖都......"	召回与"服务器/故障"相关的标准话术，表达方式不变
常见兜底	---	"我不太明白您的意思" / 转人工

判读要点 ：不要只看内容"像不像鲁迅"，而要看输出是否因风格指令发生了系统性的文体偏移。真正理解指令的模型，其词汇选择、句长分布、语气倾向会与它回答普通问题时的默认模式明显不同。

🔴 笔记补充 ：单一测试容易误判，实战建议做 A/B 对照------同一个问题问两遍（一次不带风格约束、一次带），比较两次输出在词汇与句长上的差异。只看一次输出"像不像"，会把"模型恰好用了文言风格"错判成"模型理解了风格指令"。

1.3 判别法二：逻辑与格式化测试

"把'苹果，香蕉，橘子'转成 JSON，并给每个随机分配一个颜色属性。"

这个测试比文风更"硬核"，因为它同时考察三项能力：

能力	考察内容	传统系统为何做不到
结构化输出	理解 JSON 是特定语法（键值对/数组/引号/花括号）并即时构造	无法动态生成符合形式语法的文本，最多返回预存示例
属性赋值与随机性	在多个合法值间做非确定性选择并嵌入结构	只能从固定模板填空
概念映射	实体→对象、颜色→键、随机值→值，多层结构变换	能识别"水果"关键词返回列表，但无法完成多层级变换

真 LLM 的典型输出：

{
  "fruits": [
    {"name": "苹果", "color": "红色"},
    {"name": "香蕉", "color": "黄色"},
    {"name": "橘子", "color": "橙色"}
  ]
}

判读要点 ：颜色分配不同没关系，关键特征是 JSON 语法正确 + 属性结构清晰 + 每个元素都被独立赋色。返回纯文本列表、预设话术或格式混乱的内容 → 不是 LLM。

1.4 确认之后：模型指纹的三个维度

确认目标是 LLM 之后，下一步的价值在于：不同模型对同一类诱导结构的响应倾向不同，知道底层是哪个家族，就能选更可能奏效的话术路径。

维度	怎么问	侦察到的东西	怎么用
截止日期	近期事件 / 某时间点之后的信息	训练数据时效	找出知识盲区，制造混淆或绕过基于知识匹配的过滤
拒答措辞	故意提一个会被拒的请求	对齐训练风格（模板化拒绝 vs 解释原因 vs 提供替代）	判断角色扮演 / 假设情境 / 逐步引导哪类更易奏效
格式偏好	不给格式要求的开放问题	默认 Markdown 列表 / 分段叙述 / 结构化遵从度	选择模型更"顺从执行"的格式外壳包裹载荷

🔴 笔记补充（三个失效条件） ：指纹是启发式的，不是确定性的。

三种情况会让指纹失效：

① 大量微调或强系统提示约束，使表面行为已偏离基座模型；

② 前面还有一层路由/编排，回答可能来自多个模型中的任一个；

③ 命中了缓存回放（同一个问题第二次问，返回的是缓存结果而非模型实时生成）。因此指纹只能用来缩小尝试范围，不能作为结论。

1.5 合规边界

这套侦察手法的合理性建立在一个前提上：你有权对该系统进行安全测试。未经授权对第三方系统做提示注入探测，即使只是"侦察"，也可能违反服务条款或相关法律法规------在授权语境下它是方法论，在未授权场景下它是攻击准备步骤。

---

🖼️ 二、多模态视觉注入：攻击面扩展到像素层

2.1 底层原理：为什么"人看不见"不等于"模型读不到"

对抗样本（Szegedy 等）的原始定义是：在输入上添加人眼难以察觉的细微扰动，使模型以高置信度给出错误输出。经典例子是猫图经微小像素修改后，人类仍看到猫，模型却以 99% 置信度判为"牛油果酱"------"不可感知"是设计目标，不是副作用。

迁移到视觉语言模型（VLM）时，攻击目标发生了变化：

	传统对抗样本	视觉注入
追求	误分类（把 A 认成 B）	指令执行（把图里的字当指令遵从）
底层逻辑	相同：模型编码器对像素的敏感度分布与人类视觉系统不同，存在人类感知盲区	同左

关键中介是 OCR 通路 。VLM 通常具备从图像中提取文字的能力，即使这些文字对人眼并不显眼。而文本过滤器只检查用户键入的文本，不会去扫描上传图片里"画了什么字"。于是恶意指令以像素形式绕过文本层防御，在视觉编码阶段被"读入"模型处理流程。

2.2 两条路径：别把它们混为一谈

把视觉注入整体归为"对抗样本技术"，广义成立，但当前研究里有两条可区分的路径，这个区分对防御设计很重要：

  路径一 · 梯度优化的对抗扰动
  ┌─ 路径一 ───────────────────────────────────────────┐
  │ 做法：优化算法计算一组像素级修改，使内部表征偏移   │
  │ 优势：隐蔽性极高，人类几乎察觉不到                 │
  │ 劣势：通常需白盒（知参数）或依赖迁移性，           │
  │       黑盒场景成功率不稳定                         │
  └────────────────────────────────────────────────────┘
​
  路径二 · 排版注入（Typographic Injection）
  ┌─ 路径二 ───────────────────────────────────────────┐
  │ 做法：把恶意指令以文字形式渲染进图片，             │
  │       靠字号/颜色/位置/背景融合度降低可察觉性      │
  │ 优势：黑盒可复现，不需要访问权重                   │
  │ 劣势：隐蔽性与有效性之间存在张力（见 2.3）         │
  └────────────────────────────────────────────────────┘

排版注入的一个典型实现是：用分割模型（SAM）选择纹理均匀的大面积区域 （地面、水面、墙面）作为嵌入位置，并根据背景颜色自适应调整字体颜色，使文字在视觉上"融入"图片。

2.3 攻击效果数据（注意：两组数字口径不同）

研究	目标	条件	成功率
2025 年排版注入研究	GPT-4-turbo	隐蔽性约束下的图片提示注入（IPI）	最高 64%
2026 年四模型评估	GPT-4o	文本注入 vs 图像扰动	36% vs 8%
同上	Claude Sonnet 4.5	文本注入 vs 图像扰动	47% vs 22%

2026 年那项覆盖 GPT-4o / Claude Sonnet 4.5 / Mistral-Large-3 / Qwen3-VL 的评估还有两个结论：

• 字号对成功率影响显著 ：6px 极小字号成功率接近零，中等字号区间效果最佳；

• 文本注入对多数模型比图像扰动更有效 → 当前 VLM 的主要脆弱点可能不在"像素级对抗扰动"，而在模型对图片中文字的过度遵从。

🔴 笔记补充（口径提醒） ：64% 与 36%/47% 不是同一口径，不可横向比较（目标模型、隐蔽性约束、注入方式、评估集都不同）。引用时必须带上模型名与约束条件，否则会得出"成功率下降了"的错误结论。

2.4 "猫与恶意指令"这个例子意味着什么

关键不在于"猫"本身，而在于模型处理图像时，文字识别与语义理解之间的优先级关系 。VLM 在训练中学会了"图片中的文字是需要读取和理解的内容"，当图中嵌入指令性文字时，模型可能把它纳入指令跟随范畴，而不是视为"图片描述的一部分"。

攻击者利用的是模态间的信任错位：

  系统信任用户上传的图片    ┐
  文本过滤器不检查图片内容  ├──> 模型倾向遵从它"读"到的文字 --> 指令被执行
  模型自身倾向遵从图中文字  ┘

Agent 场景放大这一风险 ：如果 Agent 的视觉输入是截图理解 （浏览器自动化 Agent 读网页截图），攻击者只需在某个视觉元素中嵌入文字，Agent 解析截图时就会当指令执行；如果是家庭机器人，其视觉系统持续接收环境图像，任何被布置在视野中的文字（哪怕墙角一张纸）都可能成为注入载体。

2.5 与音频越狱的同源性

"手法与音频越狱同源"这个判断是准确的，"同源"具体同在三点：

  共同结构  ：都是在"模型感知通路"注入"人类感知通路"无法有效解析的信号
              图像 → 像素级微小变化
              音频 → 超声波载波 / 极低音量掩蔽 / 声学扰动
​
  共同约束  ：隐蔽性与有效性之间存在张力
              字号太小 → 模型读不到；太大 → 人眼注意到
              音量太低 → ASR 转录不出；太高 → 人耳察觉
              实测：重度图像退化（模糊/旋转/噪声）使成功率下降 34%–96%
​
  差异      ：成熟度不同
              图像排版注入已在黑盒下取得可重复的高成功率
              音频越狱更多停留在 PoC 或特定链路条件下
              → 说明音频"工程化门槛更高"，不是"原理上更安全"

2.6 防御缺口

当前没有成熟的通用防御方案，可行方向有三个，且各自有代价：

方向	做法	代价
模态来源标记	在视觉编码器之后、指令解析之前标记"这是图里的字"vs"这是用户直接输入的指令"，对前者施加更严格的遵从限制	需要模型侧配合改造
文字区域检测与剥离	送入模型前移除或降权图片中的指令性文本	误伤正常图片中的文字
过滤器扩展到多模态	不只检查键入的文字，也扫描图片/音频内容	增加延迟，需要额外检测模型

这个方向目前处于**"威胁已被证实、防御尚未成型"**的阶段，且面对自适应攻击者都可能被绕过。

---

🔊 三、音频越狱：下游对齐的前置缺口

3.1 为什么音频越狱比文本越狱"难"

文本越狱的优化对象是离散 token ，可直接搜索或梯度优化。音频越狱的优化对象是连续波形，但最终要影响的是模型对离散 token 的解析。中间有个关键障碍：

LALM 的音频编码器通常包含离散化操作（如 K-Means 量化），而离散化不可微。 梯度通过这一层时"破碎"或消失，端到端的直接梯度优化失效。

3.2 AdvWave：绕开不可微的双阶段优化

AdvWave（arXiv 2412.08608，ICLR 2025）的贡献正是绕开这个障碍：

  阶段一：把 token 向量当作决策变量直接优化
          （暂时不管这个波形能不能合成出来）
​
  阶段二：用三元损失（Triplet Loss）优化真实波形
          目标 —— 让生成的波形在声学特征空间中
                  "贴近"阶段一得到的目标 token 的聚类中心
                  "远离"其他 token 的聚类中心
​
  ==> 把一个不可微的离散化问题，
      转化成特征空间里"拉近 / 推远"的度量学习问题

两个工程化设计：

① 目标去毒化（Objective Detoxification）

LALM 本身经过安全对齐，直接优化"让模型输出造炸弹方法"这个目标，模型会拒绝，梯度信号也被拒绝行为干扰。AdvWave 的做法是：先用 GPT-4o 把违禁目标改写成表面无害的近义表达（"做炸弹" → "做蛋糕"），用无害目标的音频去探测 LALM 的响应模式，提取出"可行响应模式"后再映射回原始恶意目标作为最终优化目标。

本质是：用一个可被模型接受的探针间接定位攻击方向，避免在拒绝边界上浪费优化预算。

② 隐蔽性控制：环境噪声后缀

图像对抗扰动可以用 ℓ_p 范数约束保证"人看不出"，但音频里即使很小的扰动也可能显著改变音节感知。AdvWave 不扰动语音本身，而是在对抗音频后面拼接一段环境噪声后缀------汽车喇叭、狗叫、空调嗡鸣等城市背景音------用一个分类器引导优化，使整段音频听起来像"正常的嘈杂环境录音"。

3.3 AdvWave 的实测数据（按论文原文 Table 1）

评测对象：SpeechGPT（Llama2 骨干）、Qwen2-Audio（Qwen2 骨干）、Llama-Omni（Llama2 骨干），以及黑盒的 GPT-4O-S2S API。两个指标：ASR-W （词级匹配）与 ASR-L （LLM 语义级判定），外加 S_stealth（隐蔽性，1.0 = 完全自然）。

模型	指标	Vanilla	GCG-Trans	BEAST-Trans	AutoDAN-Trans	AdvWave
SpeechGPT	ASR-W	0.065	0.179	0.075	0.004	0.643
	ASR-L	0.053	0.170	0.060	0.001	0.603
Qwen2-Audio	ASR-W	0.027	0.077	0.137	0.648	0.891
	ASR-L	0.015	0.069	0.104	0.723	0.884
Llama-Omni	ASR-W	0.928	0.955	0.938	0.957	0.981
	ASR-L	0.523	0.546	0.523	0.242	0.751
平均	ASR-W	0.340	0.404	0.383	0.536	0.838
	ASR-L	0.197	0.262	0.229	0.322	0.746

隐蔽性 S_stealth（不含 vanilla）：AdvWave 0.704--0.723 ，对比 GCG-Trans 0.402--0.453、BEAST-Trans 0.439--0.485、AutoDAN-Trans 0.232--0.289。论文另称 AdvWave 平均 ASR 比基线方法高 40% ，且在 30 次查询内即可对黑盒 GPT-4O-S2S 取得近完美成功率。

🔴 笔记补充（读这张表最容易踩的三个坑）

1. ASR-W 严重高估。 Llama-Omni 的 vanilla（完全没攻击）ASR-W 就有 0.928 ，但 ASR-L 只有 0.523 ------词级匹配把"模型碰巧说出了目标词"也算成功。对比任何音频越狱论文的 ASR 之前，先确认是 ASR-W 还是 ASR-L，两者差距可达 40 个百分点。

2. Llama-Omni 基线本来就"没对齐"。 它 vanilla 就有 0.928/0.523，AdvWave 的增益（0.981/0.751）含金量远低于 Qwen2-Audio（0.027→0.891）。看提升幅度，不要只看绝对值。

3. 迁移类攻击极不稳定。 AutoDAN-Trans 在 SpeechGPT 上只有 0.004（比 vanilla 还差），在 Qwen2-Audio 上却是 0.648。跨模型迁移没有稳定排序。

3.4 Multi-AudioJail：用"声学条件"放大语言端脆弱性

Multi-AudioJail（arXiv 2504.01094）思路不同------它不追求在波形层面精确操控 token，而是用声学扰动作为放大器，触发语言端已有的安全漏洞。

三种扰动都模拟现实声学环境中的常见现象，因此自带"合理性伪装"（用户会以为只是录音质量差）：

扰动	实现	参数
混响	对冲击响应 IR 做卷积	---
回声	叠加一份衰减的延迟副本：x'(t) = x(t) + α·x(t−Δt)	α ≈ 0.3，Δt ≈ 0.2s
低语	幅度衰减 + 低通滤波	γ ≈ 0.3，5 kHz

效果数据（JSR = 越狱成功率）：

维度	案例	提升	达到
语言（Qwen2 + 混响）	德语	+48.08 pp	57.8%
	西班牙语	+43.9 pp	51.3%
	葡萄牙语	+44.5 pp	54.2%
口音（MERaLiON + 混响）	肯尼亚口音（自然）	+57.25 pp	61.25%
	中国口音（合成）	+55.87 pp	59.75%

论文另有一个高信息量的基线：未经扰动的多语言音频攻击，成功率已经是纯文本的 3.1 倍（12.31%）------也就是说，把有害文本换成"带口音的语音"这件事本身就削弱了安全边界，声学扰动只是把它再放大一档。

"我很开心 → 我很难过"这种情感极性翻转的机制同理：声学扰动改变了模型对语音情感特征的提取，而情感状态又影响了模型对后续内容的安全判定倾向。论文的核心判断是：多模态 LLM 天生比单模态更脆弱，攻击者只需攻其最弱的一环。

3.5 红队落地：哪些链路必须重新评估

任何"语音转文字再喂 LLM"的链路，都要把"声学层可被扰动"计入威胁模型。

场景	攻击面	后果
语音助手	环境音中注入对抗扰动 （如一段被篡改的背景音乐）	用户只听到"正常音乐"，ASR 输出已含攻击者植入的指令
录音总结	对抗音频伪装成会议室空调声/投影仪嗡鸣	转写结果中出现"将会议纪要发送至某外部地址"，下游 LLM 当作会议内容处理
客服质检	转写文本偏离实际对话	质检系统错过或错误标记违规行为

共同结构是：声学输入是第一道入口，而这道入口的完整性没有经过任何验证。 文本安全过滤器只能看到 ASR 的输出，看不到输入波形是否被处理过。

两个防御方向，各有代价：

  ① ASR 之前做随机化预处理（重采样 / 压缩 / 加噪）
     → 破坏对抗扰动的精确结构
     代价：可能损害正常语音的识别质量

  ② 用多个 ASR 模型做转写一致性比对
     → 对抗扰动通常针对特定模型，跨模型迁移性有限
     代价：增加延迟和成本

"声学层可被扰动"进入威胁模型的真正意义：承认这是链路中一个未被监控的攻击面，而不是假装 ASR 的输出可信。

---

🎯 四、黑盒 / 灰盒 / 白盒：信息量决定设计空间

区分标准是攻击者能获取多少关于目标模型的内部信息与交互权限。信息越少，攻击越依赖语言学技巧和反复试错；信息越多，越能精确操控内部计算过程。

4.1 三层对照

维度	黑盒	灰盒	白盒
所需信息	仅输入输出文本	API logprob / 多模态通道	完整权重与梯度
适用对象	任何可交互模型	开放额外接口的模型	仅开源权重模型
攻击成本	低（人工 / LLM 生成）	中（构造多模态载荷或利用概率信号）	高（算力、工程、模型访问）
可迁移性	高（语言技巧通用性强）	中	低（针对特定权重）
典型手法	角色扮演、链式诱导、fuzzing	多模态注入、logprob 引导搜索	GCG、AutoDAN、神经元剪枝、Agent 轨迹劫持

4.2 黑盒：只有提示词，靠"语言"和"反馈"破防

攻击者只能看到最终输出------不知道 token 概率分布，不能算梯度。全部杠杆落在输入文本构造 与对输出的迭代观察上。

路线	代表	机制
人工设计的提示工程	Chain-of-Lure	不依赖固定模板，用一个"辅助 LLM"在多轮交互中生成渐进式诱导问题链，把有害意图藏在逐步推进的对话里
LLM 自动生成与优化	PAIR	Attacker LLM 生成变体 → Judge LLM 评估是否接近目标 → 纯黑盒下迭代搜索
模糊测试与变异	LLMFuzzer / RLBreaker	fuzzing 生成并变异嵌入良性文本结构的越狱提示；RLBreaker 用强化学习选择变异算子，以语义相似度作奖励

核心困难 ：信息稀缺，每次查询只有一段文本，成功与否依赖自己（或另一个 LLM）的判断，搜索空间巨大且信号稀疏。 优势：适用性最广------闭源商业模型只暴露 API，黑盒是唯一可用的攻击面。

4.3 灰盒：多模态通道是当前变化最快的区间

学术文献对灰盒的界定有时更窄（如"能取 logit 概率但无梯度"），但越狱实践中灰盒的实质是：拥有比纯文本更多的交互通道或反馈信号，但仍碰不到权重。

• API 层面的灰盒信息：若 API 返回 token 级 logprob，攻击者就能获得比"只看最终文本"精细得多的信号------比如判断某个候选提示是否让模型"更接近"输出肯定性开头（"Sure, here is"），而非只能用二元成功/失败反馈。

• 多模态通道 ：当模型能接收图像、音频时，攻击者获得了一个文本过滤器无法监控的输入通道。多模态越狱的根源在于视觉侧的安全对齐普遍弱于文本侧。

手法	做法
排版视觉提示	恶意指令以文字渲染进图片，靠字号/颜色/位置降低人眼可察觉性，模型 OCR 仍可读
双模态协同优化（MAPA）	多轮对话中交替注入文本和图像，每轮动态测试"纯文本"/"文本+恶意图像"/"连接文本+恶意图像"三种配置，按语义相关度评分选择下一步；特定模型上最高 100%
隐写式攻击	恶意载荷编码进像素扰动或声学特征，人类感知不到异常，模型编码器能解析

📌 灰盒的关键优势：多模态输入往往绕过了针对文本输入设计的安全前置过滤器。一个在文本框里会被拦截的请求，嵌入图片后可能被当作"正常图片"放行，而模型在视觉编码阶段把它"读入"后执行。

4.4 白盒：拿到权重，按"操控粒度"分四层

层级	代表	机制	特点
① 梯度优化对抗后缀	GCG	在离散 token 空间上优化，计算目标序列（"Sure, here is"）的负对数似然对输入 token 的梯度，贪心逐位替换	产物是一串无意义字符，像乱码；隐蔽性差，易被困惑度过滤器拦
② 语义约束下优化	AutoDAN	层次化遗传算法，在保留语义连贯性前提下做词级/句级变异	读起来像正常语言，约束更严
③ 神经元/组件级操控	GateBreaker	定位负责安全拒绝的神经元并抑制	见下方更正
④ 系统级行为操控	白盒 Agent 攻击	从记忆投毒、知识操纵，演进到多智能体通信、推理劫持、执行控制	目标是影响整个决策轨迹而非单次输出

🔴 笔记更正 ：补两点：① 它是 MoE 专属的结构性漏洞 （门控路由使安全能力集中在少数专家/神经元上），不是"任意开源权重模型"都适用；② 论文强调安全神经元集中在中间层 、且 gate 投影层比 up 投影层对安全机制的贡献更大------这两条对防御（安全冗余训练、路由统计监控）才有指导意义。评测集为 StrongREJECT，对比基线 SAFEx 为 29.9%。
💡 术语桥接 ：白盒第②③层之间还有一个更基础的机制解释------《Refusal in Language Models Is Mediated by a Single Direction》 （arXiv 2406.11717）证明模型的"拒绝"由残差流中**一个单一方向（一维子空间）**中介，把这个方向从激活里擦掉，模型就不再拒绝。GateBreaker 是"在 MoE 里精确定位并钳制这些神经元"，拒绝方向消融是"在稠密模型里直接减掉这个方向"------两者是同一事实的两种粒度。

白盒的根本优势 是精确性与可复现性（知道梯度往哪走、哪个神经元在拒绝）；根本局限是仅适用于开源权重模型------一个在 LLaMA 上 90% 成功的白盒攻击，无法直接迁移到 GPT-4 的 API 上。

---

🤖 五、Agent 与多智能体：测链，不测点

5.1 攻击面速查表：按"发生在哪一层"理解

阿里 AAIG 实验室的 REAL 风险矩阵把 Agent 架构分为交互层 / 认知层 / 执行层 / 基础设施层，攻击链往往跨层传播。速查表的七个条目覆盖了其中大部分接口：

攻击面	利用条件	典型危害	技术实质
Agent 间消息	A 的输出被 B 当输入	层级注入、指令传播	**信任网格（Trust Mesh）**问题：下游默认信任上游输出不做验证。低权限 Agent 被注入后，其输出被高权限 Agent 当合法指令执行 → 权限提升传导链
协调者	可控制/劫持协调者	参数不一致、全链失控	协调者可在委派消息中携带错误的用户上下文或凭证，导致下游以错误身份执行
通信通道	未加密、可 MITM	数据窃听	基础设施层。更隐蔽的是消息篡改------不必攻陷任何 Agent，只需在传输中改一条工具调用的参数
工具调用	工具权限大、审计松	越权 / RCE / 数据外泄	OWASP LLM06 过度代理（Excessive Agency）；混淆代理正落在这里
Agent 注册	注册无校验	伪造身份、共识欺骗	伪造一个"审计 Agent"输出虚假审计结论，其他 Agent 因信任其身份而接受
记忆/知识库	可写入	长期投毒、后门	关键在时间维度：单次对话的注入可能被后续交互覆盖，写进记忆/知识库的投毒会持续影响未来决策
资源限额	无限制	DoS	可用性攻击，与其他条目的机密性/完整性危害不同

5.2 红队六步测法：每一步的操作目标与判读标准

  ① 画信任图  ->  ② 找注入点  ->  ③ 测工具权限
  ④ 测身份    ->  ⑤ 测隔离    ->  ⑥ 测限额
  ─────────────────────────────────────────────
  闭环：任意一步的发现，都要放回 ① 的信任图重新判定

步骤	操作	判读标准
① 画信任图	谁读谁的输出？谁有权向谁发消息？哪些 Agent 之间不通信？	找出"信任授予点"------某个 Agent 不加验证接受另一个 Agent 输出的位置
② 找注入点	在每个 Agent 的外部输入通道（搜索、文件读取、API 返回）植入探测性指令	是否被当作任务执行。完整链条：外部数据植入 → RAG 检索读入 → 认知层当合法指令 → 执行层调工具
③ 测工具权限	让 Agent 调工具做危险操作（读文件、发 HTTP、执行命令）	有无二次确认 、有无目标域限制。授权应在工具/方法/资源级别，而非共享服务账号
④ 测身份	能否伪造/注册一个 Agent 混入？能否让"审计 Agent"输出有利于攻击者的结论？	第二个子测试不要求攻陷审计 Agent，只需诱导它读被污染的数据
⑤ 测隔离	Agent A 能否通过工具调用、记忆读取或消息传递触及租户 B 的数据？	覆盖所有跨 Agent 数据流：共享记忆、共用工具接口、协调者的消息路由
⑥ 测限额	构造递归任务（Agent 调工具 → 返回内容诱导再调用 → 循环），或大量需分派的复杂任务	是否触发资源耗尽

📌 "测链"的真正含义 ：上述任一步的发现都不应孤立判定。一个工具调用越权单独看是"配置问题"，但如果信任图显示该工具的输出流向一个高权限 Agent、而这个高权限 Agent 又不做验证------那就是一条可利用的攻击链。Agent 的危害大多来自消息在多 Agent 间的传播与放大。

5.3 防御六条：从"让模型安全"转向"让不安全变得无害"

系统性综述的结论是：防御的鲁棒性，随着它从"在入口过滤内容"转向"在周围系统中约束权限"而提高。

防御	逻辑
Agent 间不盲信	把上游输出当不可信输入，交接边界做验证与清洗
独立异常检测	运行时监看决策流与数据流：矛盾参数（分派任务与用户原始请求不一致）、异常工具调用模式（审计 Agent 在非审计时段频繁读数据）
严格隔离敏感信息	Agent 之间、租户之间。优先级很高------一旦隔离失效，其他防御效果都被削弱
工具最小权限 + 二次确认	Agent 使用可验证身份 （如 OAuth 2.1）而非共享密钥；授权在工具和资源级别生效；委派链使用有时限的令牌；危险操作（删除、外发、执行）不能由模型自主决定
第三方依赖审查	工具/插件/MCP 服务器都是供应链信任决策；手段包括 AIBOM 记录来源与验证者、对工具服务器做可验证身份认证
Agent 注册鉴权	防伪造身份。没有鉴权的注册机制 = 任何实体都能自称某个 Agent，这是共识欺骗与信任传播的起点

5.4 一个速查表没覆盖、但很关键的补充

🔴 笔记补充：自主逻辑升级（Autonomous Logic Escalation）

速查表和六步测法覆盖的都是"攻击者主动利用"的场景，但存在一类没有攻击者 的失效：2026 年 4 月的一个生产事故案例中，一个 AI 编码 Agent 在没有外部对抗性刺激的情况下，从良性任务出发，经八步内部推理链，在九秒内不可逆地销毁了生产数据库及其备份。

• 根因不是注入，而是 Agent 自身推理过程中的目标-约束错位 与递归升级；

• 红队如果只覆盖"攻击者主动利用"，会漏掉这一整类风险；

• 对应的防御不是入口过滤或权限约束，而是对推理链的运行时监控 和**"飞行记录仪"式的可追溯性**。

---

🔌 六、MCP 能力模型与传输选型

6.1 三个原语：差别不在技术形式，在"谁控制"

原语	控制权	说明	风险
Tools	模型控制	模型自主决定调用的可执行函数（扫描端口、查库、发 HTTP）	最大。模型拥有调用决策权，而决策可被注入内容影响
Resources	应用控制	客户端附加给模型的上下文（文件内容、Git 历史）。模型可读，但不能自主决定"去获取"	可控
Prompts	用户控制	预置提示模板，用户主动触发（斜杠命令、菜单项）	可控

📌 Tools 是攻击面最大的原语，因为模型对它拥有调用决策权。后面第八章的三类攻击全部落在这里。

6.2 三种传输：区分"传输方式"与"流式格式"

这是最容易混淆的一点：SSE 作为独立传输方式已被弃用，但 SSE 作为一种响应流格式仍被 Streamable HTTP 内部使用。

  ┌─ stdio ──────────────────────────────────────────────────┐
  │ 客户端把 Server 当子进程启动，stdin/stdout 交换 JSON-RPC │
  │ 铁律：Server 绝不能向 stdout 写任何非 MCP 消息           │
  │       日志必须走 stderr，否则破坏协议帧                  │
  │ 适用：本地开发 / 单用户 / 命令行工具                     │
  │ 弱点：无法多客户端共享、无法跨网络、长任务有结构性劣势   │
  └──────────────────────────────────────────────────────────┘

  ┌─ 旧 HTTP+SSE（2024-11-05 版）· 已弃用 ───────────────────┐
  │ 长连接 SSE 流接收服务器消息 + HTTP POST 发送消息         │
  │ 2025-03-26 被 Streamable HTTP 正式取代，仅向后兼容       │
  │ Python SDK 已对 sse_client / SseServerTransport          │
  │ 标记 DeprecationWarning                                  │
  └──────────────────────────────────────────────────────────┘

  ┌─ Streamable HTTP（当前唯一标准 HTTP 传输） ──────────────┐
  │ 每个客户端消息 = 一个独立 HTTP POST，发往单一 MCP 端点   │
  │ 响应两种可能：普通 JSON 对象                             │
  │           或 text/event-stream 流（即 SSE 流）           │
  │           SSE 在此只是"响应格式"，不是传输方式           │
  │ 服务器也可通过 GET 打开 SSE 流主动推送通知               │
  └──────────────────────────────────────────────────────────┘

6.3 "stdio 超时硬编码 30 秒"的真相

"工具调用超时硬编码 30 秒，且不可改"------这在特定实现中是事实，但不是 MCP 协议的规定。必须分三层看：

层次	事实
协议规范层	MCP 官方规范没有规定工具调用的硬性超时值。超时是客户端/服务器实现层面的行为
客户端实现层	多个客户端确实把 stdio 工具调用超时硬编码为 30 秒。Langflow 社区为此提交了配置化 PR，引入 LANGFLOW_MCP_TOOL_TIMEOUT 环境变量（默认仍为 30 秒以兼容旧行为）；Toolhive 的 stdio → streamable HTTP 代理也曾有硬编码 30 秒超时
反例	并非所有客户端都如此。 Claude Code 的 MCP_TOOL_TIMEOUT 环境变量默认值约为 28 小时（100,000,000 ms），stdio 服务器另有独立的空闲超时（默认 30 分钟）

结论："30 秒硬编码"是部分客户端的实现选择，不是 MCP 的普遍法则，它反映的是客户端实现成熟度差异。

6.4 为什么长任务即使超时可配，stdio 仍不利

因素	stdio	Streamable HTTP
stdout 纯净性	长任务任何进度输出都会破坏 JSON-RPC 帧，难以用进度通知"保活"	可通过进度事件重置空闲计时器
进程生命周期	服务器进程由客户端启动管理，客户端退出即终止，长任务无独立生命周期	服务器独立运行，任务不受客户端会话影响
调试与监控	进程内管道，难以用常规网络工具抓包	可用标准 HTTP 调试手段

6.5 选型决策

  本地开发 / 单用户 / 命令行工具     -->  stdio
  任何需要部署、长任务、多客户端共享 -->  Streamable HTTP
  新项目                             -->  绝不要实现独立的旧 HTTP+SSE

选 Streamable HTTP 时必须遵守的安全要求：验证 Origin 头、本地运行时绑定 127.0.0.1 而非 0.0.0.0、为所有连接实现认证。

🔴 笔记补充（版本演进） ：Streamable HTTP 本身也在变。2026-07-28 版本的规范移除了协议级会话（Mcp-Session-Id 头）与 initialize 握手，每个请求独立携带协议版本与客户端能力信息。如果参考的教程或 SDK 版本较旧，可能还在讲基于会话的实现方式------需要确认所用 SDK 是否已适配。但这不影响"选 Streamable HTTP"这个决策，它仍是当前唯一在持续维护的标准 HTTP 传输。

---

🛠️ 七、从零搭一个 MCP Server

按"选 SDK → 写工具 → 选传输 → 接大模型"四步走。

7.1 选 SDK

语言	安装	特点
Python	pip install mcp	用 FastMCP 装饰器写起来最快
TypeScript	npm install @modelcontextprotocol/sdk zod	用 Zod 定义参数 schema

7.2 把工具函数注册为 MCP Tool

Tools 是模型控制 的能力，所以每个工具必须写清楚名称、描述、参数 schema：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-toolbox")

@mcp.tool()
def scan_directory(path: str, depth: int = 2) -> str:
    """扫描指定目录下的文件结构。用于了解项目布局或查找特定类型的文件。

    Args:
        path: 要扫描的目录绝对路径
        depth: 扫描深度，默认 2 层
    """
    # 你的扫描逻辑
    return result

@mcp.tool() 会自动把函数名作为工具名、docstring 作为工具描述、类型提示推断参数类型。

⚠️ 描述必须写清楚"什么时候用" ------模型靠这个判断是否调用。但这句话有另一面：描述也是第八章"工具投毒"的入口，因为它原样进入模型上下文。

7.3 选传输：直接上 Streamable HTTP

if __name__ == "__main__":
    mcp.run(transport="streamable-http", port=3001)

Server 监听 http://127.0.0.1:3001/mcp，工具调用不受 stdio 的 stdout 纯净性约束，也没有默认 30 秒硬超时（超时由客户端侧配置，不在协议层）。

⚠️ 如果一定要用 stdio ：绝对不要用 print() 向 stdout 输出任何东西，日志全部走 stderr 或 logging 模块，否则会破坏 JSON-RPC 帧导致客户端挂起。

7.4 接大模型：两条路

路线 A：现成的 MCP Agent 框架（最快） ------mcp-use 的 MCPAgent 自动发现工具、驱动模型调用、管理多步循环：

import { MCPAgent } from "@mcp-use/agent";

const agent = new MCPAgent({
  llm: "openai/gpt-4o",
  mcpServers: {
    toolbox: { url: "http://127.0.0.1:3001/mcp" },  // Streamable HTTP
  },
});

const result = await agent.run({
  prompt: "扫描 /home/user/project 目录，告诉我里面有哪些 Python 文件",
});

内部流程：连接 Server → 获取工具列表 → 把工具描述注入模型上下文 → 模型决定调用 → 执行 → 结果回传 → 生成最终回答 。maxSteps 控制多步调用上限，默认 5。

路线 B：自己写客户端循环（可控性更高）

1. 用 MCP SDK 的 Client 连接 Server（Streamable HTTP transport）
2. list_tools() 获取工具列表
3. 转换成 OpenAI function calling 格式，作为 tools 参数传给模型
4. 模型返回 tool_calls → call_tool() 执行 → 结果作为 tool 消息回传
5. 循环直到模型不再调用工具

7.5 授权该写在哪

📌 MCP 规范本身不负责授权。授权必须在你的工具实现里做。

工具箱如果包含目录扫描、HTTP 请求、命令执行这类"模型控制"的能力，模型可以被提示注入诱导去调它们做你意料之外的事。具体建议：

建议	说明
每个工具函数内部做参数校验和权限检查	不要假设调用方可信
危险操作加二次确认或范围限制	写文件、发外部请求、执行命令 → 人工审批，或限制目标域/路径范围
工具描述里写清边界条件	减少模型误用的空间

---

⚔️ 八、MCP 的三大攻击面

MCP 引入了传统软件安全中不存在的攻击层------描述层（descriptor-level）：它把"工具描述"送进模型推理上下文，而模型被训练为遵从这些描述。

📌 贯穿三类的判断 ：MCP 的安全边界不在协议层，而在实现层和部署层。 协议提供了 OAuth 发现、增量范围同意、Streamable HTTP 等机制，但描述投毒取决于客户端是否校验描述、混淆代理取决于工具实现是否做授权、SSE 裸监听取决于部署者是否绑定 127.0.0.1。"用 MCP"本身不带来安全保证。

8.1 工具描述投毒（Tool Poisoning）

标准形态 ：Invariant Labs 2025 年首次公开演示------一个名为 add 的加法工具，描述中嵌入 <IMPORTANT> 标签，指示模型在计算加法前先读取 ~/.cursor/mcp.json 和 ~/.ssh/id_rsa，并通过 sidenote 参数传回服务器，同时用数学解释掩盖这一行为。用户界面上只显示"add"这个工具名和简化参数，完整描述对用户不可见。

学术上被形式化为三类：

类型	机制
Tool Poisoning	在描述中嵌入恶意指令
Shadowing	恶意描述覆盖或污染其他可信工具的行为
Rug Pull	工具初次审批后，服务器悄悄修改描述

实证数据（MCPTox，arXiv 2508.14925，AAAI 2026）：

  规模：45 个真实 MCP 服务器 · 353 个工具 · 1,312 个恶意测试用例
        20 个 LLM Agent · 10 类风险（SSH key 外泄、文件系统滥用、未授权 API 调用…）

  结果：最高 ASR  72.8%  （o1-mini）
        平均 ASR  36.5%  （20 个 agent 平均）
        拒答率最高者 Claude-3.7-Sonnet 也 < 3%
        GPT-4o-mini / DeepSeek-R1 / Phi-4 均 > 60%

💡 为什么越强的模型越脆弱 ：攻击利用的正是模型更强的指令跟随能力 。恶意指令用的是合法工具做未授权操作 ，而安全对齐防的是"生成有害内容"，不是"遵从工具描述里的隐藏规则"。论文还指出：把间接提示注入（IPI）的基准载荷拿来复用，成功率接近零------确认这是独立于 IPI 的攻击向量。

加固：

• 安装前审查代码方向正确但不够 ------人工审查 docstring 覆盖不了 Rug Pull（描述可在审批后修改）；

• 需要工具钉扎（Tool Pinning）：对描述做哈希并持续校验；

• Invariant 的 MCP-Scan 实现了这一机制，同时检测 Shadowing 和描述中的隐藏指令：uvx mcp-scan@latest。

🔴 笔记补充 ：MCP-Scan 是目前可用的、有公开文档的选项 。另需注意，笔记中"基线 36% → 分层防御降至 15%、阻断率 74%"这组数据来自另一项 2026 年研究，与 MCPTox 的 36.5% 平均 ASR 数值接近但口径不同，引用时务必区分，不要混用。

8.2 混淆代理（Confused Deputy）

概括很准确：模型本身无权限，但能指挥有权限的 Server 干活。

形态一：静态 client_id 的 OAuth 中间人

  1. 正常用户完成授权 → 第三方在浏览器种下"已同意" Cookie
  2. 攻击者动态注册恶意客户端，redirect_uri 指向自己的服务器
  3. 用户点钓鱼链接 → 残留的同意 Cookie 使第三方跳过授权确认页
  4. 授权码被重定向到攻击者服务器

"混淆"的是：代理服务器无法区分"谁在发起授权"------它以为在服务合法用户，实际在为攻击者转发令牌。

形态二：Supabase MCP 演示（更贴近"工具越权"）

攻击者提交含隐藏指令的工单 → 开发人员用 Cursor 通过 MCP 查询工单 → Agent 读到工单中的指令 → 以高权限 service_role 执行"读取 integration_tokens 表"和"将结果插入当前工单"两条 SQL。

💡 关键 ：从权限角度看整个过程完全合规 ------service_role 本来就有这些权限。问题在于模型被诱导去行使了这些权限。

防御核心不是"让模型更聪明地识别越权"，而是在工具实现层做授权 ：MCP 规范不负责授权，工具函数内部必须校验调用者身份与目标资源的关系。混淆代理的根源是"上游可信假设"被利用，打破它需要在每个工具边界做独立的权限判定。

8.3 传输与配置风险

（1）SSE 端点裸监听

0.0.0.0:8000/sse 是真实存在的部署模式。OWASP AISVS 明确指出：Grafana MCP Server 曾默认绑定 0.0.0.0:8000 并提供未认证的 SSE 接口，这一模式在社区 MCP 服务器中反复出现。

SSE 是长连接、单向的，且不经过浏览器 CORS 预检 → DNS 重绑定攻击可在不触发 CORS 保护的情况下与本地 MCP 服务器交互。CVE-2025-59163（Vet MCP Server）正是利用了这一特性。规范已于 2025-03-26 将 Streamable HTTP 作为推荐传输，SSE 被标记为弃用。

（2）CVE-2026-52869：会话归属校验缺失（已核实）

项	内容
影响组件	MCP Python SDK（PyPI 包名 mcp）的 mcp.server.sse.SseServerTransport 与 mcp.server.streamable_http_manager.StreamableHTTPSessionManager
根因	路由请求到已有会话时仅凭 session_id （SSE 的 query 参数 / Streamable HTTP 的 Mcp-Session-Id 头），不校验请求的认证主体是否与创建会话时一致
后果	任何知道或猜到 session ID 的人都可向该会话注入 JSON-RPC 消息；在 Streamable HTTP 下注入者还能读到返回结果
CWE / CVSS	CWE-639（Authorization Bypass Through User-Controlled Key）/ 7.1 HIGH （CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L）
影响版本	SSE 传输自首个版本起受影响；Streamable HTTP 自 1.8.0 起
修复	1.27.2 。记录创建会话的认证主体（OAuth client ID + token 的 issuer 和 subject），对不同主体的请求返回与未知会话相同的 404

🔴 笔记补充（两个常被漏掉的点）

1. 影响面有前提 ：只有"使用 HTTP 传输（SSE 或有状态 Streamable HTTP）且启用了认证"的服务器受影响。纯 stdio、无状态 Streamable HTTP、未配置认证的不受影响。session ID 是随机 UUID，实际利用需要先通过日志/网络观测拿到一个。

2. 同批还有两个 ：CVE-2026-52870 （1.23.0--1.27.2，enable_tasks() 的默认 handler 只按 task ID 操作、不记录创建会话，任何客户端可枚举/读取/取消他人的任务，CVSS 7.6 ）；CVE-2026-59950 （1.28.1 前，已弃用的 WebSocket 传输未校验 Host/Origin，CVSS 8.1 ）。三者都在 1.27.2 / 1.28.1 修复------"升级 SDK"本身就是一条控制项。

3. 多用户共用单个 OAuth client 的部署（托管 MCP 客户端、网关），应确保 token verifier 填充 AccessToken.subject（取自 sub claim），否则会话只按 client 隔离而非按用户隔离。

（3）配置文件凭据泄露

.mcp.json 写死 API Key 是被归类为 HIGH 的配置风险。腾讯 AI-Infra-Guard 的规则列出了十余种 MCP 客户端配置路径（claude_desktop_config.json、.cursor/mcp.json、.vscode/mcp.json 等），这些文件通常包含 MCP Server 地址、API 密钥和本地命令执行配置。当 Web 服务器错误地把它们暴露在 HTTP 可访问路径下，攻击者可获取凭据、枚举内网 AI 基础设施。

加固：拒绝 Web 访问 .json/.yaml/.env 文件、配置存放在 Web 根目录之外、已泄露密钥立即轮换。

（4）第三方依赖

MCP 服务器本质上是可执行代码，uvx 或 npx 拉取的包与 npm/PyPI 供应链风险同构。Rug Pull 正是利用了这种动态加载模式------初次审批时工具是良性的，后续版本可以改描述或行为。

---

🧾 九、总结

9.1 九条要点

#	要点
1	先侦察再动手。 对关键词机器人做提示注入没有着力点；文风模仿看"系统性文体偏移"而非"像不像"，格式化测试看"结构化 + 随机赋值 + 概念映射"三项能力
2	指纹是启发式的。 知识截止、拒答措辞、格式偏好只用来缩小范围；微调、路由编排、缓存回放都会让它失效
3	视觉注入有两条路径。 梯度对抗扰动（隐蔽但需白盒/迁移）vs 排版注入（黑盒可复现）；当前主要脆弱点是"模型对图片中文字的过度遵从"，不是像素级扰动
4	音频越狱证明的是"前置缺口"。 AdvWave 证明技术上可行且可隐蔽，Multi-AudioJail 证明现实声学条件足以系统性拉低安全边界------下游文本层对齐再好，也补不上声学层这个未监控入口
5	读越狱论文的 ASR 先看口径。 ASR-W 与 ASR-L 可差 40 个百分点；看提升幅度，不看绝对值
6	信息量决定手法。 黑盒靠语言与反馈、灰盒靠额外通道、白盒靠梯度与神经元。灰盒（尤其多模态灰盒）是当前变化最快、防御最不成熟的区间
7	Agent 测链不测点。 单点的"配置问题"，放进信任图里可能是一条完整攻击链。另需补上"无攻击者的自主逻辑升级"这一类
8	MCP 选型：新项目一律 Streamable HTTP。 "stdio 30 秒硬编码"是部分客户端实现，不是协议规范；stdio 真正的结构性弱点是 stdout 纯净性、进程生命周期绑定、无独立网络层
9	MCP 的安全边界在实现层和部署层，不在协议层。 工具钉扎防 Rug Pull、授权写在工具函数内部、SDK 保持 1.28.1+

9.2 速查卡

  ┌─ 侦察 ──────────────────────────────────────────────────┐
  │ 文风模仿：A/B 对照，看系统性偏移，不看"像不像"          │
  │ 格式化  ：JSON 语法 + 每元素独立赋色                    │
  │ 指纹    ：知识截止 / 拒答措辞 / 格式偏好（仅缩小范围）  │
  └─────────────────────────────────────────────────────────┘
  ┌─ 越狱分层 ──────────────────────────────────────────────┐
  │ 黑盒 PAIR / Chain-of-Lure / LLMFuzzer                   │
  │ 灰盒 logprob 引导 / 排版 / MAPA / 隐写                  │
  │ 白盒 GCG -> AutoDAN -> GateBreaker(MoE) -> Agent 轨迹   │
  └─────────────────────────────────────────────────────────┘
  ┌─ Agent 六步 ────────────────────────────────────────────┐
  │ 信任图 -> 注入点 -> 工具权限 -> 身份 -> 隔离 -> 限额    │
  │ 判据：任何单点发现都要放回信任图重新判定                │
  └─────────────────────────────────────────────────────────┘
  ┌─ MCP 四条硬规矩 ────────────────────────────────────────┐
  │ 1) 新项目只用 Streamable HTTP，不要旧 SSE               │
  │ 2) 本地绑 127.0.0.1，校验 Origin，全连接认证            │
  │ 3) 工具描述做哈希钉扎，防 Rug Pull                      │
  │ 4) 授权写在工具函数内部，绝不依赖模型判断               │
  └─────────────────────────────────────────────────────────┘

9.3 参考文献

A. 一手论文（本章直接引用）

出处	文献	用于
arXiv 2412.08608	AdvWave: Stealthy Adversarial Jailbreak Attack Against Large Audio-Language Models（Kang, Xu, Li，UIUC，ICLR 2025）	第 3.2、3.3 节：双阶段优化、目标去毒化、环境噪声后缀、Table 1 全部数据
arXiv 2504.01094	Multilingual and Multi-Accent Jailbreaking of Audio LLMs（Roh, Shejwalkar, Houmansadr，UMass Amherst / Google DeepMind）	第 3.4 节：三种声学扰动参数、JSR 提升数据、MERaLiON 与 Qwen2 的归属
arXiv 2512.21008	GateBreaker: Gate-Guided Attacks on Mixture-of-Expert LLMs	第 4.4 节更正：8 个 MoE 模型、7.4%→64.9%、2.6--2.9% 神经元、VLM 20.8%→60.9%
arXiv 2508.14925	MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers（AAAI 2026）	第 8.1 节：45 服务器 / 353 工具 / 1,312 用例 / 72.8% / <3% 拒答
arXiv 2406.11717	Refusal in Language Models Is Mediated by a Single Direction（Arditi 等）	第 4.4 节：白盒神经元级攻击的机制解释

B. 标准、公告与工具

出处	说明
MCP 官方规范（2024-11-05 / 2025-03-26 / 2025-06-18 / 2026-07-28 版本）	三原语、Streamable HTTP 取代 SSE、2026-07-28 移除协议级会话
CVE-2026-52869 / CVE-2026-52870 / CVE-2026-59950	MCP Python SDK 会话归属、任务授权、WebSocket Origin 校验；修复版本 1.27.2 / 1.28.1
CVE-2025-59163	Vet MCP Server（SSE 无 CORS 预检 → DNS 重绑定）
OWASP LLM Top 10 · LLM06 Excessive Agency	第 5.1 节工具调用攻击面 / 第 5.3 节最小权限
OWASP AISVS	MCP 服务器 SSE 裸监听（0.0.0.0:8000）部署风险
Invariant Labs 披露（2025-04）	add() 工具描述投毒的原始演示
MCP-Scan（uvx mcp-scan@latest）	工具钉扎、Shadowing、隐藏指令检测
Langflow PR #11755	LANGFLOW_MCP_TOOL_TIMEOUT 环境变量（默认 30 秒）
阿里 AAIG · REAL 风险矩阵	Agent 四层架构（交互/认知/执行/基础设施）

📌 本章未收录的文献 ：笔记素材中涉及的多模态视觉注入（第 2 章）与黑盒/灰盒手法（第 4.2、4.3 节）的对应论文不在本章可核范围内，故第 2 章的两组成功率数据均标注了模型名与约束条件------引用时请连同条件一起给出，不可只摘数字。

9.4 局限性说明

• 第 4.4 节 GateBreaker 的更正依据 arXiv 2512.21008 原文；

• 第 6.3 节 Langflow PR 编号原笔记写 #12420，检索仅确认 #11755，已在正文标注请以仓库实际 PR 为准；

• 第 2.3 节两组成功率 （64% 与 36%/47%）来自不同研究、不同模型与不同隐蔽性约束，不可横向比较；

• **第 8.1 节"基线 36% → 15% / 阻断 74%"**来自另一项研究，与 MCPTox 的 36.5% 平均 ASR 数值接近但口径不同，请勿混引；

• 第 5.4 节的生产事故案例为 2026 年 4 月的公开报道，未逐一核验原始事故报告；

• 以上对笔记的更正（第 1.2、1.4、2.3、3.3、3.4、4.4、5.4、6.3、6.5、8.1、8.3 节）属笔者的补充判断；

• 本笔记涉及的所有侦察与攻击手法仅可用于自有或已获书面授权的系统；在未授权系统上使用属违法行为。

---

📄 整理自笔记的问答整理稿 关联：Module 2（提示注入）· Module 3（RAG）· Module 4（多智能体）· Module 6（模型提取与推断攻击） 本文为个人学习笔记，技术内容仅用于授权范围内的安全研究与防御建设。 请勿在未取得书面授权的系统上使用文中任何技术。