夜雨聆风
过去两年，我们讨论AI安全时聊的是幻觉、越狱、对齐。但真正的威胁已经换了方向——攻击者不再试图让AI"说错话"，而是通过AI"偷走你的密钥"。MCP的安全危机，是这个转变的标志性事件。
引言：安全团队盯错地方了
过去两年，如果你问一个企业安全负责人"AI最大的安全风险是什么"，他大概率会说：模型幻觉、数据投毒、越狱攻击、对齐问题。
这些确实是问题。但2026年上半年发生的一系列事件表明，真正在造成损失的，不是模型本身，而是模型连接外部世界的那根管道。
这根管道叫MCP（Model Context Protocol）。Anthropic在2024年底推出，2025年底捐给Linux Foundation，现在Python SDK月下载量超过1.64亿次，7000+个公开服务器，Cursor、Claude Code、Windsurf、Gemini CLI全在用。说它是AI Agent的"USB-C接口"不夸张。
过去半年，这个"USB-C接口"被发现千疮百孔：架构级漏洞、实战攻击、30多个CVE、OWASP专门立项。但这篇文章不只是在说MCP的问题——MCP只是一个切面。我们想说的是一个更大的判断：
AI安全的战场已经从模型层转移到了执行层。安全团队如果还在盯着"模型会不会说错话"，可能盯错了方向。
一、先说清楚MCP是什么——以及为什么攻击者盯上了它
MCP（Model Context Protocol）是一个开放协议，干的事情很简单：让AI Agent能调用外部工具。读文件、查数据库、跑Shell命令、调API——都通过MCP这个统一接口。
它有两种工作模式：STDIO（本地进程间通信，你在IDE里用的就是这个）和HTTP/SSE（远程服务器通信，云端MCP服务用这个）。
理解MCP的安全意义，关键是想清楚一件事：AI模型本身是沙盒化的，它不能直接碰你的文件系统、不能直接连你的数据库。MCP就是那个把沙盒打开的协议。 它是模型和真实世界之间的桥梁——也是攻击者从"让AI说错话"升级到"通过AI偷你东西"的必经之路。
当Cursor、Claude Code、Windsurf全都依赖同一座桥的时候，这座桥的结构缺陷就不是某个工具的问题了——是整个生态的问题。
二、协议层：STDIO的"原罪"
2.1 一个设计决策，感染了整条供应链
2026年4月，OX Security发了一份报告，标题很直接："The Mother of All AI Supply Chains"（AI供应链之母）。
他们发现的问题说出来有点荒谬：MCP的STDIO传输层在启动子进程时，对传入的命令参数不做任何校验。你传什么，操作系统就执行什么。进程启动失败？没关系，命令已经跑完了。
更要命的是，这不是某个开发者的代码写得烂。这个行为存在于Anthropic官方SDK的所有语言版本：Python、TypeScript、Java、Rust。也就是说，任何基于官方SDK搭建的项目，从出生那天起就带着这个漏洞。
打个比方：这不是你家门锁坏了，而是锁厂的模具就是歪的，所有用这个模具造出来的锁都打不住。
2.2 Anthropic说"这是Feature，不是Bug"
Anthropic的回应让安全社区相当不满。他们的官方立场是："STDIO执行模型是安全的默认设置，输入清洗是开发者自己的责任。"
9天后，Anthropic更新了SECURITY.md，加了一句"STDIO适配器应谨慎使用"。SDK架构？一行没改。
OX Security的回应很尖锐：
"一个架构决策，做一次，就悄无声息地传播到每一种语言、每一个下游库、每一个信任这个协议的项目中。把责任转移给实现者，不等于转移了风险——只是模糊了谁制造了风险。"
说实话，这场争论到现在也没有结论。但它触及了一个真实的行业困境：当一个协议变成了事实标准，安全到底该谁兜底？ Anthropic说"我只定协议，安全你自己管"，但现实是大多数开发者默认信任官方SDK——他们不会想到要在SDK之上再做一层输入校验。
2.3 暴露规模：三个月扩大八倍
这不只是理论风险。看一下实际扫描数据：
2025年12月：Bitsight TRACE扫描到约1000个MCP服务器在线暴露、无授权。其中一些可以直接管理Kubernetes集群——这意味着攻击者能直接碰到你的生产环境 2026年1月：Invariant Labs的扫描结果是8247个，翻了8倍 2026年2月：Trend Micro确认492个服务器零认证零加密；对官方MCP注册表518台服务器的审计发现，41%连协议层认证都没有 2026年1-2月：30+个CVE针对MCP提交，43%是Shell注入
三个月，从一千到八千。这个增速比MCP本身的普及速度还快。
三、四类实战攻击：不是理论推演，已经在发生
3.1 STDIO直接命令执行
最朴素的一种：控制MCP服务器的配置参数（command或args字段），操作系统就替你执行了。不需要什么高级手法，协议本身就是这么设计的。
3.2 AI编程工具集体沦陷
这部分最让人不安。不是一个工具有问题，而是市面上主流的AI编程工具几乎全军覆没：
Windsurf（CVE-2026-30615）：零用户交互。攻击者在一条PR标题里嵌入恶意指令，你的IDE打开PR的一瞬间就中招了 Cursor（CVE-2025-54136）：类似的注入路径 Claude Code：Adversa AI发现一个很阴的问题——安全deny规则在执行50个子命令后会静默失效。也就是说，你以为有安全围栏，但用着用着围栏自己消失了（已在v2.1.90修复） GitHub Copilot / OpenAI Codex：BeyondTrust发现构造一个特殊的GitHub分支名就能窃取Codex的OAuth token，OpenAI把这个列为Critical P1
VentureBeat做了一个很好的总结：6个独立研究团队分别攻破了这些工具，没有一个瞄准的是模型本身——全部瞄准的是凭证。 SSH密钥、AWS凭证、GitHub Token，这些才是攻击者真正想要的东西。
这就是我们说的"战场转移"：攻击者已经不关心模型输出什么了。他们关心的是模型能碰到什么——你的SSH密钥、你的AWS凭证、你的代码仓库。MCP就是通往这些东西的大门。
3.3 MCP应用市场投毒：从"官方渠道"安装的也不安全
还记得npm投毒事件吗？同样的事情正在MCP市场重演。
OX Security做了一个实验：用测试载荷去污染MCP注册表。结果是11个注册表中成功了9个，在6个有付费客户的生产平台上确认了命令执行。你从"官方渠道"安装一个MCP服务器，它可能在你不知情的情况下执行恶意命令。
更扎心的数据来自OWASP的基准测试：工具投毒在自动批准模式下成功率84.2%。 而你用Cursor、Claude Code的时候，默认是什么模式？自动批准。
3.4 ContextCrush：一个"只读"MCP服务器是怎么偷走你源码的
这个案例值得展开说，因为它颠覆了很多人的直觉。
Context7是一个很火的MCP服务器，5万GitHub Stars，800万+npm下载。它的功能就是给AI编程助手提供实时文档查询——只有两个只读工具，不能执行代码、不能写文件、不能发网络请求。听起来很安全对吧？
Noma Security找到了一条绕过路径：Context7允许库作者设置Custom Rules，这些规则会原样传递给AI Agent。攻击者注册一个库，在Custom Rules里写入恶意指令，再用自动化请求把这个库刷到"trending"和"top 4%"排名。
当你的AI助手查询这个库时，恶意指令进入Agent上下文。MCP服务器本身没有执行任何危险操作——但它让AI Agent替它干了：读取.env文件、SSH密钥，然后通过Agent自己的工具链外传。
攻击面不在MCP服务器能做什么，而在它能"说服"AI Agent做什么。 传统安全审查会看一个组件有没有危险权限——Context7没有。但在Agent时代，一个没有任何危险权限的组件，照样能通过操纵AI的决策来窃取数据。这是安全团队的思维模式需要更新的地方。
该漏洞2026年2月23日已修复，但攻击思路已经公开，同类MCP服务器还没有全面排查过。
3.5 连接越多，越危险
Palo Alto Unit 42的研究揭示了一个反直觉的结论：MCP服务器连得越多，整体越不安全。
他们的测试场景是这样的：一个AI Agent同时连接5个MCP服务器，其中1个被攻陷。被攻陷的服务器可以劫持对话、注入持久指令、在用户不知情的情况下调用其他工具。
攻击成功率？78.3%。
这意味着你装了5个MCP插件，只要有一个有问题，四分之三的概率你的整个工作环境都会被渗透。装得越多，风险不是线性增长——而是加速膨胀。
四、OWASP出手了：给MCP立规矩
OWASP做了一件以前没干过的事：给一个单独的协议专门出了一套安全框架。 这本身就说明问题有多严重。
OWASP MCP Top 10目前还在beta，列了10大风险。和企业最直接相关的几个：工具投毒（恶意指令藏在工具描述里，AI看得见人看不见）、影子MCP（未经审批的MCP服务器绕过治理）、Token泄露（密钥硬编码或留在日志里）、认证缺失（MCP服务器压根不验证身份）。完整清单见OWASP官方项目页。
配套的基准测试数据很直观：
34/100：17个主流MCP服务器的平均安全评分。满分100，平均34，不及格 **84.2%**：工具投毒在自动批准模式下的成功率 **100%**：被评估的MCP服务器中，没有一个声明了自己需要什么权限 **66%**：社区MCP服务器中含至少一个严重代码异味
OWASP MCP Top 10最大的价值不是发现了新问题，而是终于给了企业安全团队一个可以拿着逐项对照检查的清单。之前想审查MCP安全？你得自己拼凑十几份报告。现在有了一个统一的框架。
五、生态层：谁在堵窟窿
5.1 Docker的逻辑：协议不修，我在下面接着
Docker的做法最务实。2025年9月收购MCP Defender，逻辑很清楚：Anthropic不改协议，那我就在基础设施层兜底。
MCP Defender做的事情是拦截AI工具（Cursor、Claude Desktop、VS Code）和MCP服务器之间的流量，用签名检测+LLM分析来抓工具投毒、数据外泄和跨工具操纵。同时开源了MCP Gateway，和Docker Compose集成，作为Agent和外部工具之间的安全检查站。
思路对不对？方向没问题。但这本质上是在一个不安全的协议上面糊了一层安全——能挡一些攻击，但底层的设计缺陷还在。
5.2 MCP规范在补课，但只补了一半
MCP规范自己也在打补丁。最大的更新是给远程传输层加了OAuth 2.1 + PKCE认证，远程MCP服务器必须作为OAuth 2.1资源服务器运行，强制PKCE防止授权码拦截。2026路线图把"企业就绪"列为首要目标，包括会话级授权（任务结束权限自动撤回）和SSO集成。
但说白了：OAuth 2.1解决的是远程传输的认证问题。STDIO本地传输的架构缺陷？没动。 MCP安全不是打一个补丁就能收工的。
5.3 安全厂商闻到了钱的味道
MCP安全从"研究课题"变成了"商业赛道"，速度很快：
Palo Alto收购Portkey进入AI Gateway赛道，Unit 42持续发攻击向量研究 Invariant Labs开源了mcp-scan扫描工具 SentinelOne出了MCP安全指南 Noma Security靠ContextCrush研究一炮打响 Adversa AI每月发MCP安全资源月报
当头部安全厂商集体涌入一个赛道的时候，说明这个问题不是昙花一现。
5.4 不只是MCP：整个执行层都在出问题
如果你觉得"这是MCP一个协议的问题"，那再看一件事。
2026年5月7日，微软自己的Agent框架Semantic Kernel曝出两个高危漏洞（CVE-2026-25592 CVSS 10.0 / CVE-2026-26030），路径遍历+任意文件写入+RCE。微软给安全博客起的标题很直白："When prompts become shells"——当Prompt变成Shell。
MCP有问题，Semantic Kernel也有问题。这不是巧合，而是同一个结构性趋势的两个症状：当AI Agent开始真正"做事"（执行命令、读写文件、调用API），安全威胁就从模型层转移到了执行层。 这个转移是系统性的，不是修一个协议就能解决的。
六、如果战场已经转移，安全团队的优先级也该调一调
很多企业安全团队还在把AI安全的精力花在模型评估、prompt安全、输出审核上。这些当然要做，但如果执行层已经千疮百孔，模型层管得再严也挡不住攻击者从侧面进来。
具体到MCP，等Anthropic修协议可能等到明年，等OWASP从beta毕业也得几个月。企业不能等。
本周就能做的事
摸底：问一句"我们有多少团队在用MCP？有没有没经过审批的影子MCP服务器？"——很多企业连这个数字都不知道 关掉自动批准：所有AI编程工具的MCP工具调用改为手动确认。84.2%的投毒攻击成功率建立在自动批准上，关掉这一个设置就干掉了大部分风险 把密钥挪走：SSH密钥、AWS凭证、API Token、.env文件从AI Agent能碰到的地方移出去。攻击者要的就是这些 更新工具版本：确认Cursor、Claude Code、VS Code都升到了最新版。前面说的很多漏洞已经有修复了
一个月内建立基线
跑一次mcp-scan：扫描所有MCP配置，建立调用行为基线 最小权限：每个MCP服务器只给完成任务需要的最小权限，不给多余的 拿OWASP MCP Top 10当检查清单：逐项对照审查一遍 建MCP准入机制：新装MCP服务器必须过安全团队审查
季度级的体系化建设
上MCP安全网关（如Docker MCP Gateway），在Agent和工具之间卡一个统一的策略执行点 运行时监控：对MCP调用行为做实时检测和异常告警 供应链安全流程：版本锁定、签名验证、依赖审计 纳入整体Agent治理：统一身份、授权、审计、合规
七、回到核心判断
写这篇文章不是为了说"MCP很危险"——这个结论太浅了。我们想说的是一个更大的事：
AI安全的战场已经转移了。
过去两年，行业讨论AI安全的方式是：模型会不会产生幻觉？会不会被越狱？输出有没有偏见？对齐做得好不好？这些问题仍然重要，但它们属于"模型层安全"。
2026年上半年MCP的密集爆发告诉我们，真正在造成实际损失的威胁已经转移到了执行层：命令注入、权限失控、供应链投毒、认证缺失——全是安全团队熟悉的老问题，只是出现在了新环境里。
这个判断的实际含义是：
安全团队该问的不再是"模型会不会说错话"，而是"Agent能碰哪些系统，权限边界在哪，出了事谁能在30秒内阻断" 企业AI安全的优先级需要调整：模型评估继续做，但执行层的权限管控、工具链审计、运行时监控需要提到同等甚至更高的优先级 MCP安全不是一个临时话题。Docker、Palo Alto、OWASP、学术界同时入场，说明这个方向会持续好几年
结语
回到开头的那个问题：AI最大的安全风险是什么？
如果是2024年，答案可能是模型幻觉和越狱。但到了2026年，答案应该更新了：是你的AI Agent能碰到什么、能做什么、以及出了事你能不能发现和阻断。
MCP的安全危机不是终点，它只是一个开始。随着AI Agent越来越深地嵌入企业工作流，执行层的安全问题只会越来越多、越来越复杂。
好消息是，应对这些问题的工具和框架正在快速成熟。坏消息是，大多数企业的安全意识还停留在"模型安全"阶段。
战场已经转移了。该跟上了。
本文基于OX Security、OWASP、Noma Security、Palo Alto Unit 42、Docker、Invariant Labs、Adversa AI、Microsoft、Bitsight、SentinelOne等机构的公开研究整理。不含未公开漏洞细节或可复现攻击步骤。
