什么是 MCP?为什么它需要安全?
Model Context Protocol(模型上下文协议)由 Anthropic 于 2024 年底开源,现已成为 AI Agent 的事实基础设施。
MCP 不是插件系统,不是 API 网关,甚至不是"安全通信协议"。它本质上是一个信任传递协议。其核心设计哲学极其简单:Agent 主机信任 MCP 服务器,MCP 服务器将能力描述发送给 AI 模型,模型读取描述后调用工具,工具返回结果给模型 -- 整个过程中,协议层不做任何安全校验。
用微软安全团队的话说:"协议本身不强制执行安全 -- 它只定义通信方式,锁需要由你自己安装。"问题在于:绝大多数开发者不装锁。他们连门都没关。
MCP 的特殊之处在于:它连接的不是机器,是决策者。一个被投毒的 MCP 服务器不是偷你的数据,是让你的 AI 替攻击者干活。你不是在被攻击,你是在被借用。
OWASP MCP Top 10 十大安全风险
2025 年底,OWASP 发布了首份 MCP Top 10 安全风险清单 -- 这是继 Web 应用、API、LLM 之后,OWASP 为单一协议设立独立风险排名的第四次。
令牌管理失控与密钥泄露Token Management Failure & Secret Leakage
不要把硬编码的 API 密钥、长期令牌、云服务凭证写在 MCP 服务器配置里。但所有人都这么做。攻击者通过提示注入或调试日志就能抓走你的 GitHub Token、AWS 密钥、数据库密码。
一个 MCP 服务器的沦陷,等于连接的所有系统的全面沦陷。
攻击者通过一次提示注入,让 Agent 调用 debug_tool 列出所有环境变量,其中包含硬编码的 AWS Secret Key。随后直接访问 S3 存储桶获取敏感数据。
权限蔓延式提权Permission Creep & Privilege Escalation
这是最阴险的一种。不是一次性突破,而是渐进式侵蚀。开发者给服务器设了"临时"权限,忘了撤销。三个月后,一个只该读日志的 Agent 已经有了管理员权限。
没有自动过期机制,没有最小权限审查。权限像杂草一样,在你看不见的地方悄悄生长。
一个日志分析 MCP 服务器最初只有 read_logs 权限,经过三次迭代后,逐步获得了 write_config、execute_query、manage_users 权限,最终成为事实上的超级管理员。
工具投毒Tool Poisoning
这是 MCP 安全的核心战场。攻击者在工具的描述、schema、返回值中嵌入恶意指令。模型读取这些指令,视为"可信上下文",然后执行。工具投毒有三种子形态:
攻击者提交了一个"文件搜索"工具,描述中声称可以搜索代码仓库。审核通过后,工具的返回值中嵌入了隐藏指令,指示模型在后续操作中将匹配到的 API 密钥发送到攻击者控制的服务器。
软件供应链攻击Software Supply Chain Attack
MCP 生态建立在开源之上 -- 成千上万的社区服务器、插件、连接器。一个依赖项被入侵,所有下游 Agent 行为被篡改。
而且攻击者不需要攻破你的系统 -- 只需要攻破你信任的那个 npm 包。
一个广泛使用的 MCP Slack 集成包被劫持,更新后的版本在每次消息发送时都会将对话内容转发到外部 C2 服务器,影响了 3000+ 个使用该包的 Agent。
命令注入与执行Command Injection & Execution
Agent 用未清理的用户输入构造 shell 命令、API 调用、代码片段。一次成功的命令注入等于攻击者在你的开发机器上执行任意代码。
2026 年报告的 MCP 漏洞中,这是数量最大的类别。
用户输入文件名为 "report.csv; rm -rf /home",Agent 直接拼接到 shell 命令中执行,导致整个家目录被删除。
意图流劫持Intent Flow Hijacking
这是最高级的攻击。攻击不发生在单次调用,而是通过多轮推理逐步污染。每次操作单独看都合理 -- 但整体目标已被悄然替换。
你把"分析销售数据"交给 Agent,十步之后它在导出客户敏感信息。攻击者不劫持你的系统,劫持的是你的意图。
Agent 被要求"分析客户购买数据以优化推荐",攻击者在数据源中注入微妙偏差,经过 12 步分析后,Agent 不知不觉地将包含 PII 的原始数据导出到攻击者指定的 S3 路径。
认证与授权缺失Authentication & Authorization Gaps
MCP 生态里,多个 Agent、多个用户、多个服务交换数据和执行操作,但大多数服务器从不验证"你是谁"。
你连上了一个 MCP 服务器,它就以自己的默认权限执行一切 -- 不管操作来自谁、目的是什么。
一个内部 MCP 数据库服务器没有任何认证机制。攻击者通过网络扫描发现该服务后,直接连接并执行任意 SQL 查询,导出全量用户数据。
审计与遥测缺失Audit & Telemetry Gaps
大多数 MCP 系统无法回答三个基本问题:发生了什么?谁做的?影响多大?
没有日志,没有审计轨迹,没有告警。攻击者可以在你的 Agent 生态里逛三个月,你浑然不知。
影子 MCP 服务器Shadow MCP Servers
这是 Agent 时代的"影子 IT"。开发者为了打通一个 demo 搭了个 MCP 服务器,团队把 Agent 连上任何能用的端点 -- 没有人注册,没有人审计,没有人知道它还在跑。
你看不到的东西,你治理不了。
上下文注入与过度共享Context Injection & Over-sharing
AI 的"工作记忆" -- 上下文窗口 -- 被不同任务、用户、工具共享。一次工具返回的敏感数据,被写入全局上下文,被后续的无关任务读取。
就像你刚在浏览器里登录了网银,下一个标签页的脚本也能读到你的余额。
Agent A 查询了包含用户密码哈希的数据库记录,这些数据残留在共享上下文中。Agent B 在处理一个无关任务时,从上下文中"记住"了这些密码哈希,并在回复中泄露给用户。
五大攻击层:风险分层模型
OWASP MCP Top 10 的十大风险可以归纳为五个层层递进的攻击层面,从凭证管理到运行时审计,构成完整的威胁图景。
凭证地狱Credential Hell
令牌管理失控、认证缺失 -- 攻击者获取系统入口的钥匙
权限失控Permission Creep
渐进式提权 -- 从最小权限到超级管理员的悄无声息的演化
投毒三叉戟Poisoning Trident
工具投毒、意图劫持、上下文泄漏 -- 对 AI 决策链的三维打击
供应链噩梦Supply Chain Nightmare
依赖被篡改、影子服务器 -- 看不见的攻击面在暗处蔓延
执行地狱Execution Hell
命令注入、审计缺失 -- 当攻击已经发生,你却一无所知
"所有 AI 供应链之母":设计级 RCE 漏洞
OX Security 在 2026 年 4 月披露的 MCP SDK 设计级漏洞,将理论风险变成了血淋淋的现实。
Anthropic MCP SDK 的 STDIO 传输接口中存在一个设计级远程代码执行漏洞。不是编码错误,是设计选择。漏洞机制极其简单:
Anthropic 在被披露后确认该行为是"有意为之",理由是当开发者正确限制了 command 字段时,这代表"安全的默认行为"。他们只是更新了 SECURITY.md 文件,提示开发者"谨慎使用",未做任何架构层面的修改。
| 攻击类型 | 机制 | 严重程度 |
|---|---|---|
| 未认证 UI 注入 | AI 框架的 MCP 配置界面无需认证,攻击者可远程注册恶意服务器 | CRITICAL |
| 安全加固绕过 | 即使实施了白名单的平台也被发现可绕过(CVE-2026-40933,CVSS 10.0) | CRITICAL |
| 零点击提示注入 | AI IDE 渲染攻击者控制的 HTML/README,IDE 静默修改 MCP 配置 | CRITICAL |
| 恶意市场分发 | 11 个公开 MCP 市场中 9 个无审核即接受提交 | CRITICAL |
四维防御框架
基于 OWASP MCP Top 10 和微软安全团队的推荐,我们将防御策略收敛为四个治理维度。
| 治理维度 | 覆盖风险 | 核心策略 |
|---|---|---|
| 权限治理 | MCP01 / MCP02 / MCP07 | 最小权限原则、短期凭证、身份验证与授权、OAuth 2.1 + PKCE + 受众绑定令牌 |
| 上下文治理 | MCP03 / MCP06 / MCP10 | 上下文隔离、注入检测、意图一致性验证、将工具描述和输出视为不可信输入 |
| 供应链治理 | MCP04 / MCP09 | 签名验证、依赖监控、服务注册、固定工具定义、漂移监控 |
| 运行治理 | MCP05 / MCP08 | 命令沙箱化、容器化隔离、完整审计日志、实时告警、运行时网关 |
微软的分层防御建议
微软在其 2026 年 MCP 安全报告中提出:你不能信任任何 MCP 服务器,所以你得自己建一座"监狱"把它关起来。这包括工具管理(人工审批工具列表)、授权(OAuth 2.1 + PKCE)、最小权限(窄范围 scope、短期令牌)、供应链安全(设计时目录、漂移监控)、可见性(运行时网关)以及沙箱(容器化隔离)。
开发者可立即执行的清单
1. 永远不要在 MCP 配置中硬编码凭证,使用环境变量或密钥管理服务;2. 为每个 MCP 服务器配置最小必要权限,设置自动过期;3. 启用审计日志并配置异常告警;4. 对所有工具输出执行上下文隔离;5. 定期扫描和发现影子 MCP 服务器;6. 在执行层实施命令沙箱化。
为什么 MCP 的安全模型是系统性失败的?
设计哲学的根本冲突
MCP 的设计初衷是"让 AI Agent 连接一切"。这意味着它必须是开放的、低门槛的、易于扩展的。安全性从来不是第一优先级 -- 连接性 才是。MCP 隐含地假设了"信任链":开发者信任服务器,服务器信任模型,模型信任工具返回的数据。但在真实世界中,这条链的每一个环节都可以被攻击者打断。
安全责任的系统性下放
Anthropic 的立场:安全是你的责任,不是协议的。但 MCP 的架构设计使得安全变成了一个每个人都需要做但几乎没人做对的分布式难题。上万名开发者各自为战,一个做错,全线皆输。
攻击面的乘数效应
传统软件的漏洞通常局限于特定组件。但 MCP 的漏洞是乘数效应:因为漏洞位于基础 SDK 层,它向下传播到所有构建在 MCP 之上的平台。下游开发者不需要犯任何错误就继承了暴露面。一个 SDK 的选择,决定了整个生态的底座是否安全。
延伸阅读
- [1] OWASP Gen AI Security Project -- OWASP 生成式 AI 安全项目
- [2] OWASP Top 10 for Agentic Applications (2026) -- AI 智能体 Top 10 安全风险
- [3] OX Security CSA Research Note (2026.04) -- "所有 AI 供应链之母" MCP SDK 设计级漏洞披露
- [4] Microsoft Security Blog "The State of MCP Security in 2026" (2026.06)
- [5] arXiv:2603.22489 -- MCP Threat Modeling 学术论文 (STRIDE/DREAD 框架分析)
- [6] OWASP Top 10 for LLM and GenAI -- LLM 与生成式 AI 安全 Top 10