MCP 爆发两年后的安全账单：企业级 AI Agent 风险实战解析
摘要： MCP 协议在不到两年内成为企业 AI 标配，28% Fortune 500 已部署生产环境。但安全跟进严重滞后：仅 8.5% 使用 OAuth，53% 仍用静态 API key。本文深入分析提示注入、工具投毒、供应链攻击等新风险，并给出企业级安全基线。
从实验室到生产线：MCP 的爆发速度超出了所有人的预期
2024 年 11 月 25 日，Anthropic 推出 Model Context Protocol（MCP）时，行业普遍认为这只是一个”把语言模型和工具连接起来”的实验性协议。两年后回头看，这个判断错得离谱。
到 2025 年 12 月，MCP SDK 月下载量已经突破 9700 万次。全球活跃的公共 MCP 服务器超过 1 万个。更惊人的是，根据 Truto 的估算，到 2026 年初，约 28% 的 Fortune 500 公司已经在生产工作流中运行 MCP 服务器。这是什么概念？一个协议从首次发布到被三成 Fortune 500 采用，只用了不到两年——在企业软件历史上，这几乎是前所未有的 adoption curve。
但伴随快速采用的是一幅令人担忧的安全画卷。
一组令人不安的安全数据
Aydahwa 最近发布的 MCP 安全调研揭示了企业部署背后的真实安全状态：
| 安全指标 | 比例 |
|---|---|
| 使用 OAuth 认证的 MCP 服务器 | 8.5% |
| 使用静态 API Key 认证 | 53% |
| 完全没有认证机制 | 约 25% |
| 暴露公网且零认证（MVP 研究，2025.7） | 492 个 |
这意味着，你走进一家看起来很成熟的企业 IT 环境，可能会发现：一个能用的 AI Agent、一套有用的工具集，但——没有一个人真正设计过它的信任模型。
攻击面到底改变了什么
在讨论具体攻击手法之前，有必要先厘清三个常被混为一谈的概念：
- – MCP（Model Context Protocol）：一个开放协议，为模型提供连接外部工具和数据的标准方式——无论是 API、数据库，还是 Gmail、Slack、GitHub 这类应用。
- – RAG（检索增强生成）：一种架构模式，模型在查询时从文档、PDF 或数据库中拉取最新信息，用当前数据回答问题，而不是仅依赖训练语料。
- – AI Agent：一个能自主规划和行动的系统，自己决定调用哪些工具、以什么顺序调用，而不是停留在简单的请求-响应循环里。
从”你问我答”到”我自己干”，这是最根本的范式转变。当一个模型可以调用删除记录、转账、修改防火墙规则、给客户发邮件这些真实世界的操作时，一个错误的决策不再只是一个”答案不对”的问题——它会变成现实世界中的实际后果。
企业必须面对的五大新风险
1. 提示注入：直接的和间接的
直接提示注入很简单：用户在输入框里敲点东西，覆盖系统的原始意图。真正棘手的是间接注入——恶意指令被埋在 Agent 自己抓取的内容里。
2025 年中期的 Supabase MCP 事件是教科书级别的案例：攻击者在支持工单里埋入 SQL 指令，当 Agent 通过数据库工具处理这些工单时，它不仅执行了那些 SQL，还顺带窃取了集成 token。没有人输入恶意提示——payload 是通过正常业务数据混进来的。
HackerOne 报告称，截至 2025 年 10 月，提示注入相关漏洞报告增长了 540%。这个数字和我们在实际测试中看到的情况完全吻合。
2. 工具投毒：供应链上的定时炸弹
2025 年 9 月，一个攻击者发布了一个假的 postmark-mcp 包——模仿 Postmark 合法邮件服务的 MCP 服务器。前 15 个版本都是干净的，到 16 版本突然加了行代码：把所有邮件抄送给攻击者。两个月内，Enkrypt AI 扫描了超过 268,000 个工具，横跨 25,000 个 MCP 服务器，发现了 143,000+ 个漏洞，影响了 73% 的服务器。
一个 MCP 服务器，就是一个攻击面入口。而这个入口的供应链审查，在大多数企业里几乎是零。
3. 2026 年的 LiteLLM 供应链攻击
2026 年 3 月 24 日，攻击者使用窃取的凭证向 PyPI 发布了两款恶意版本的 LiteLLM。GitHub 上的代码从未改变过。任何从流水线中拉取这个更新的系统，实际上是在运行攻击者的代码——带着自己的凭证。
一个 AI Agent = 一个模型 + 一套技能 + 一组 MCP 服务器 + 一棵 Python 依赖树。Agent 加载的每一个层，都是攻击面。
4. MCP 服务器的身份与访问管理真空
Astrix 的审计揭示了一个更根本的问题：MCP 服务器的身份认证机制几乎不存在。8.5% 用 OAuth 是例外，53% 用静态 API Key 是常态，还有约四分之一完全没认证。
这意味着：当一个 Agent 说”我要调用这个 MCP 工具”时，它实际上在没有任何实质验证的情况下，代表一个真实用户在做权限之外的事。
5. A2A 与 MCP 的协议碰撞
Google 主导的 A2A（Agent-to-Agent）协议和 Anthropic 的 MCP 正在成为企业 AI 的两大互操作标准。但这两种协议的交互带来了新的攻击面：A2A session smuggling（会话夹带）和被污染的 MCP 包正在成为新的威胁载体。
企业安全基线：我们实际在用什么
基于过去一年在多个企业环境中的实践，以下是我们认为必须落地的安全基线：
图：安全 MCP 部署架构——策略网关（Policy Gateway）位于 agent 与工具之间，把提示注入、工具投毒、凭证窃取三条攻击路径都卡在中间层（图源：Aydahwa）
认证与授权
- – 强制 OAuth 2.0：所有 MCP 服务器必须使用 OAuth 认证，静态 API Key 立即淘汰。
- – 最小权限原则：每个 MCP 工具的权限范围应该精确到具体操作，而不是”能访问这个数据库”。
- – 会话级 token：不要用长期 token，用短期会话 token。
供应链安全
- – MCP 服务器白名单：只允许从已审核的服务器列表中拉取工具。
- – 依赖扫描自动化：每一次 CI/CD 流水线都必须跑 MCP 依赖和 Python 包的安全扫描。
- – 签名验证：对 MCP 服务器和所有外部包做签名校验。
运行时防护
- – 输入清理：对所有外部数据做严格的清理和验证，包括 MCP 工具返回的数据。
- – 操作审批：高危操作（数据库写、文件删除、外部 API 调用）必须走人工审批或二次确认。
- – 审计日志：每一个 MCP 调用、每一次工具执行、每一个模型决策——全链路记录。
协议层
- – A2A + MCP 混用时的隔离：不同协议的 agent 之间必须有网络和数据的硬隔离。
- – 协议版本锁定：生产环境锁定 MCP 协议版本，拒绝降级。
小夏点评
- 1. MCP 的 adoption 曲线和安全的差距，已经大到不能用”还在早期”来解释了。 28% Fortune 500 在生产环境跑 MCP，但 8.5% 的 OAuth 渗透率说明绝大多数部署是在”裸奔”。这个差距不是技术问题，是认知问题。
- 2. 对国内企业的警示：不要重蹈覆辙。 看到国外已经踩过的坑（静态 key、无认证、供应链攻击），国内团队应该直接把这些加入安全基线，而不是等事故发生了再补救。
- 3. RAG + Agent 组合的安全风险被严重低估。 传统安全关注的是”谁能访问什么”，但 Agent 时代需要关注的是”一个自主系统能代表我做什么”。这个思维转换比买任何安全产品都重要。
参考链接
- – 原文：How to Secure MCP and AI Agents in the Enterprise
- – OWASP Top 10 for Agentic Applications：https://owasp.org/www-project-top-10-for-agentic-ai-applications/
- – MCP 官方文档：https://modelcontextprotocol.io/
- – Anthropic MCP SDK：https://github.com/anthropics/mcp
