MCP 把信任默认开到最大，
收紧的活留给了你
MCP 解决的痛点很实在：一个协议接所有工具，不必再为每个工具、每个框架单独写胶水。但它的默认值是为「先跑起来」优化的，不是为生产安全优化的。认证可选、工具定义可变、会话级权限一上来就全发——把这三件事收紧，官方短期不打算在协议层替你做。
- HTTP 认证「可以」实现，不是「必须」
- 工具定义会话中可被悄悄替换
- 会话一开始就发放全部工具凭证
- 工具输出被当成可信上下文
- 每个 HTTP 端点强制 OAuth 2.1 + TLS
- 工具清单 pin 住哈希，变更即拦
- 按任务发权限，逐回合动态加载
- 输出走严格 schema 校验
先排掉一个流行的假漏洞
网上有一篇被广泛转的「CVE-2026-32814 / X-MCP-Authenticated header 认证绕过」。开始之前先说清楚：它是假的。
该来源（RingSafe）页面顶部自述是「Scenario Brief — not a report of a live incident」，并写明文中 CVE 编号、机构、日期、数字「均为示意（illustrative）」，正文里 CVE 号写的是「a hypothetical CVE-2026-XXXXX」。全网搜该编号只回链到它自己，NVD 无此号，X-MCP-Authenticated 这个 header 在真实 MCP SDK 里也不存在。所以它是给安全团队做桌面演练的虚构剧本。本文不采用，第六节的「在野漏洞」一律换成有 NVD 编号、有官方补丁的真 CVE。
认证在协议里是「可选」的，大多数部署就真不做
MCP 有两种传输方式。stdio 走本地 socket，压根没有认证，前提假设是两端都是同一台机器上互相信任的进程——这在本地开发成立，一旦上托管或多租户就破了。HTTP 在 2025 年 6 月加进了对 OAuth 2.1（带 PKCE）的正式支持，但规范的措辞是「server 可以实现授权」，不是「必须」。授权是可选项，而大多数公开 server 根本没做。
一个开源 AI agent，HTTP 网关默认就把认证关着，2,000 多个部署实例把凭证和完整对话历史泄给了任何知道端点路径的人。这里没有 bug 可补，端点就是没有认证层，而协议也从没要求过它有。
你批准过的工具定义，事后还能被换掉
第一次连上一个 server，客户端拉取它的工具清单（名字、描述、参数 schema），你看一眼点「同意」，agent 就开始调。多数团队不知道的是：这些定义是会话开始时动态拉取的，而协议里有个 notifications/tools/list_changed 机制，允许 server 在会话进行中推送更新后的 schema，不需要客户端重新批准。规范没要求工具定义不可变，也没要求做内容哈希。一个被批准过的 server，每次连接都可以返回一份不同的清单。
- 工具定义可经
list_changed中途变更 - 客户端只在首次连接批准一次
- 恶意指令藏在批准框可见区下方
- 首次批准时哈希整份清单，每次连接比对
- 用 mcp-scan 检测清单变化
- ETDI 工具签名（arXiv:2506.01333）
npm 上一个伪装成正经邮件集成的包，靠 15 个版本和干净的下载记录积累信誉。9 月 17 日发布的 1.0.16 版只加了一行代码，把所有外发邮件暗中抄送（BCC）到攻击者地址。批准过的 agent 继续照常调用，不会重看。下架前估计已影响约 300 家机构、每周约 1,500 次下载。
学术界也对此做过量化。2026 年 3 月一篇同行评审论文（arXiv:2603.22489）测了 7 个主流 MCP 客户端对篡改工具定义的反应，其中 5 个完全不做静态校验，server 返回什么就接受什么。就算会弹批准框的客户端也常常失守，因为恶意指令往往藏在可见区下方，利用的正是用户往往不向下滚动就点同意。
间接提示注入，从工具的返回数据里进来
针对大模型的提示注入，通常要碰到系统提示词或用户输入。MCP 多开了一条路：工具的输出。工具返回数据时，模型把它当成可信的上下文（毕竟是它自己要来的结果）。如果数据里夹着一段长得像指令的文字，模型往往会照此执行。能力越强的模型越容易受影响，因为它们对指令的服从更精确。
Cursor agent 带着 service-role 数据库权限（最高权限，绕过行级安全）在跑，用一个 MCP 工具处理用户提交的客服工单。某张工单里装的不是文字，是嵌入的 SQL 指令。agent 把工单读进来，把 SQL 当成「别人给我的上下文」执行了，结果把数据库里的集成令牌导了出去。整个攻击面就是一张工单的内容，系统提示词完全没被触及。
攻击者写了恶意 GitHub issue，专门给一个带宽泛权限个人访问令牌（PAT）的 agent 去读，内容被构造得像来自可信来源的指令。agent 执行了它，访问开发者的私有仓库，还建了个公开 pull request，把私有仓库名、项目细节、个人财务数据放了进去。
攻击面会随工具数量一起放大。agent 通过 MCP 读的每一个数据源（数据库、工单、邮箱、文档库）都是潜在注入点。FlowVerify 的对策落在数据层：用严格的输出 schema 规定每个工具能返回哪些字段，在模型看到之前就校验，任何自由格式的文本都当成惰性数据，而不是候选指令。
环境权限与「混淆代理」
这一类是结构性的。MCP 在会话一开始就把整套工具的访问权发给 agent，这些凭证整个会话期间始终有效。这就是环境权限：agent 同时持有全部权限，不是只持有当前任务需要的那点。一个暴露 20 个工具的 server，拿到的是一个覆盖全部 20 个工具的 OAuth 会话令牌；初次握手之后，工具之间没有逐个的授权关卡。
环境权限会催生「混淆代理」（confused deputy）攻击。工具 A 对低权限数据有读权限，它返回的输出被构造成给工具 B 的一条指令，而工具 B 对敏感目标有写权限。模型把工具 A 的输出当可信上下文读进来，照着去调工具 B。两个工具都没被攻破，没有任何认证检查失败。攻击之所以成，是因为两套凭证同时在线，而模型分不清「工具输出是数据」还是「工具输出是指令」。
一个「每日冷知识」MCP server，工具描述里藏着针对同机 WhatsApp server 的指令。agent 读取这段隐藏指令，用自己合法的 WhatsApp 权限读取了用户全部聊天记录，再以一条外发消息将其导出，还用空白填充混淆躲过 DLP 检测。WhatsApp server 自始至终没被攻破，攻击利用的是 agent 同时对两个 server 握着的环境权限。
"Most MCP deployments give an agent all its credentials at session start. The confused deputy attack doesn't need a compromised tool — it needs two tools that are both already trusted."
真实漏洞主线：三家官方 SDK 栽在同一处默认配置
把那条虚构的 CVE 拿掉之后，真实可查的漏洞群其实更能说明问题。它们指向同一个反复犯的错：官方 SDK 的 localhost HTTP 传输默认不校验请求的 Host / Origin header，于是被 DNS rebinding 或跨站请求打穿，归类上属于「不安全的默认初始化」（CWE-1188）。
DNS rebinding 的具体机制
因为 MCP server 暴露的常常是能读源码、执行 shell、调云 API 的工具，一个被重绑的请求就能从用户打开的任意一个浏览器标签页，驱动整个工具面。MCPSafe 特别提醒：单靠 Bearer token 防不住，因为 token 若已在之前设好的 cookie 或 header 里，重绑后的请求会带着它过去；唯一可靠的防御是逐请求做 Host 校验。
下面这组都能在 NVD 或官方 GitHub Security Advisory 上查到，且都有对应补丁版本：
createMcpExpressApp 安全默认 + Host 校验）[官方] NVD；GHSA-w48q-cv73-mx4w
[官方] NVD / SentinelOne
Content-Type: application/json，无认证部署下任意网站可触发工具执行（CSRF，CWE-352）。[官方] NVD；GHSA-89xv-2j6f-qhc8
[第三方] FlowVerify 转述
switch 漏掉 500 分支，直接放行未认证请求。default 分支）[官方] GitHub Issue
把 TypeScript、Go 两家 SDK 前后出现的几处同类缺陷放在一起看，结论跟 FlowVerify 和 NSA 一致：这不是某个实现者偶然写错，而是协议早期「先方便起来」的默认取向，把同一类风险复制到了每一个官方实现里，最后都靠后续版本补上 Host/Origin 校验来修复。
NSA 的判断：采用速度超过了安全建设
2026 年 5 月 20 日，美国国家安全局（NSA）发布《Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation》。总判断是：MCP 的快速采用已经超出了相应安全保障的建设进度，让各机构暴露在协议设计者和实现者当初没充分预料到的风险之下。左边是它点的八个风险，右边是对应的九条建议。
八个风险
- 不受控的自动化动作：AI 可自己决定用新工具、采取新动作。
- 缺少输入筛查：藏在数据里的指令能蒙混过去。
- 上下文投毒：输出被其他系统当指令而非信息。
- 缺少身份与访问控制：不验证「是谁、有没有权限」就放行。
- 数据泄露：共享信息被无意暴露给多个服务。
- 缺少人工审批：动作前不需签字，能力/权限变更不触发复核。
- 凭证重用：缺令牌过期/吊销，偷来的凭证可被复用冒充。
- 易受过载攻击：可被请求洪水冲垮（DoS）。
九条建议
- 不要只依赖官方文档的安全建议，按自己环境额外加防护。
- 只用可靠、在维护的 MCP 工具，来源可信。
- 拿你最严的软件审查流程（代码审计级）去过 MCP 工具。
- 按信任级别隔离系统和数据，公开信息工具与敏感数据工具分区。
- 最小权限：工具不需要碰的资源明确禁掉。
- 优先在本地处理私密或敏感数据，不依赖外部服务。
- 所有输入先筛后处理；一个模型的输出喂给另一个时尤其要校验。
- 把所有自动化动作都当高风险，框在严格权限边界里隔离。
- 留全量审计日志，接进现有安全监控。
"It is essential that MCP operations are brought in line with established secure computing practices without stifling the flexibility and power that make it attractive in the first place."
上生产前的加固清单
FlowVerify 给了一张对照表：哪个失败模式由什么条件触发、有什么公开案例、主要怎么缓解。
| 失败模式 | 触发条件 | 公开案例 | 主要缓解 |
|---|---|---|---|
| 工具 rug pull | 定义可经 list_changed 变更；只批准一次 | postmark-mcp（2025-09）；CVE-2025-54136 | ETDI 签名；mcp-scan 清单哈希 |
| 间接提示注入 | 工具输出被当可信上下文；无 schema 强制 | Supabase/Cursor SQL 外泄；GitHub MCP 泄露（2025-05） | 严格输出 schema；自由文本当不可信数据 |
| 混淆代理 / 环境权限 | 会话级 OAuth 令牌一次覆盖所有工具 | WhatsApp 聊天外泄（2025-04）；多 server 78.3%（Unit 42） | 按任务授权；逐回合动态加载 |
| 未认证 HTTP 网关 | HTTP 认证可选，多数部署跳过 | Clawdbot（2026-01）；CVE-2026-33032 | 强制 OAuth 2.1；网关层强制 |
除了逐行对策，FlowVerify 列了几条应当成为每个生产部署默认动作的实践：
- 在传输层全审计。每次工具调用都记下名字、参数、输出哈希。被攻破的 agent 不会主动暴露自己，异常的工具调用序列才是主要信号，这套要在事故发生前建好。
- 每个 HTTP MCP 端点强制 TLS + OAuth 2.1。规范 2025 年 6 月起就支持，生产环境没有任何理由跑一个不认证的 HTTP MCP server。
- 按任务发工具，别按会话全发。一些框架支持逐回合动态注册工具。收窄凭证面是性价比最高的架构改动。
- 在模型看到之前校验输出 schema。规定每个工具能返回哪些字段，超出的予以拒绝；外部自由文本绝不直接拼进系统提示词，也不当参数传给下一个工具。
- 用 mcp-scan 或自己的哈希固定（pin）工具清单。mcp-scan（Invariant Labs 开源）能扫 Claude、Cursor、Windsurf 的配置，标出会话之间清单的变化。
FlowVerify 也提到，MCP 规范工作组正在讨论工具定义不可变、更细粒度的权限范围、HTTP 传输强制认证这几件事，上面提到的一些缺口很可能在 2026 年的规范修订里收窄。上面这些控制，针对的是今天已经被利用的那些。