文章总结： 本文深入探讨了模型上下文协议（MCP）所带来的安全风险。MCP作为AI时代的关键基础设施，其安全设计存在严重缺陷，如缺少身份验证、权限过滥和审计追踪，这使其成为零信任架构下的攻击盲区12。文章详细分析了工具投毒、困惑的代理人等典型攻击原理，并指出当前MCP的部署普遍违背了规范中的安全建议3。最后，文章提出了一系列加固措施，包括将MCP连接视为特权访问通道、净化输入上下文、实施最小权限和沙箱隔离等，以应对这一紧迫的安全挑战。 综合评分： 85 文章分类： 应用安全,数据安全,AI安全,技术标准,解决方案

MCP，那个被零信任架构遗忘的后门

幻泉之洲

2026年5月3日 17:35 北京

在小说阅读器读本章

去阅读

模型上下文协议已成为AI时代的关键基础设施，但它的安全性设计近乎原始。缺少认证、权限过滥、没有审计，让无数暴露在公网的MCP服务器变成了零信任的盲区。从WhatsApp数据窃取到GitHub仓库泄露，一系列真实攻击事件证明，这不是理论风险，而是正在发生的安全灾难。

无处不在的“AI万能插头”

就在你们精心设计的网络分段、身份提供者和严格IAM策略之外，有个协议正把数据传给AI助手，其安全措施简陋得就像贴在显示器上的便利贴。

这个协议就是模型上下文协议。过去一年半，它悄无声息地成了所有主流平台上AI助手与企业工具、数据库和API之间的粘合剂。Claude用它，ChatGPT用它，微软Copilot、Cursor、VS Code、Gemini现在都说MCP。每月SDK下载量9700万，超过一万台活跃服务器在运行。这已经不是实验，这是基础设施。

而没有任何安全控制的基础设施，不过是等着被人发现的攻击面。

MCP干了什么，又没干什么

Anthropic在2024年11月推出MCP，是为了解决一个痛点问题。每当开发者想让AI助手与Slack对话、查询数据库或从CRM拉数据时，都得写专门的集成代码。MCP标准化了这些连接，就像是AI智能体世界的通用插头。

你可以把它想成AI助手的USB接口。但就像USB早期一样，没人花太多时间思考插上恶意设备会发生什么。

SC Media的分析很直白：MCP没有内置身份验证，没有最小权限控制，没有审计追踪。协议不验证谁在连接，不限制连接后能做什么，也不记录他们做了什么。

对于一个企业团队用它来让AI助手传输敏感数据的协议来说，这可不是小疏忽，而是结构性的缺口。

没人愿意看到的攻击时间线

这个缺口的后果在2025年初就不再是理论了。随后发生的事件，是安全社区多年来见证的概念验证到实际利用最快的一次升级。

• 2025年4月，WhatsApp数据窃取。 Invariant Labs演示，一个伪装成无害“每日趣闻”工具的恶意MCP服务器，可以悄悄窃取用户整个WhatsApp聊天记录。手段是工具投毒——恶意服务器的描述里藏着指令，AI助手会忠实地执行。传统DLP工具根本看不到这一切发生。
• 2025年5月，GitHub沦陷。 同一研究团队发现，官方的GitHub MCP服务器可以通过恶意公开Issue被劫持。攻击者在Issue描述里构造恰当的提示词注入，就能诱骗AI助手泄露私有仓库内容、内部项目细节，甚至薪资信息。很多开发者不假思索就给AI助手开通了权限过大的个人访问令牌。
• 2025年6月，一个月内两次打击。 先是Asana支持MCP的集成中的一个访问控制缺陷，将一个组织的项目、任务和团队结构暴露给完全不同的客户。接着JFrog披露了CVE-2025-6514，广泛使用的OAuth代理包mcp-remote存在命令注入漏洞，下载量超过43.7万。恶意MCP服务器可以发送一个陷阱重重的授权端点，mcp-remote会直接把它传给系统shell，导致远程代码执行。
• 2025年7月，Anthropic自己的服务器。 安全研究人员在Anthropic官方的文件系统MCP服务器中发现两个严重漏洞：沙箱逃逸和符号链接绕过。创建MCP的公司提供的参考实现，竟然允许攻击者访问任意文件和执行主机代码。

这只是公开披露的事件。到2026年初，CVE数量直线上升：60天内出现30个新漏洞。

为什么零信任对此视而不见

零信任基于一个简单的原则：从不信任，永远验证。每次请求认证，每次动作授权，每次会话记录。这套机制对人类用户、API调用和服务间通信都很有效，它的架构就是为这些模式设计的。

但MCP不符合其中任何一类。

当员工通过MCP将AI助手连接到公司的Slack工作空间时，到底发生了什么？助手获得一个令牌（通常是权限过大、长期有效的），然后开始代表用户发出请求。从零信任边界的角度看，这些请求是合法的——它们来自已认证用户的会话，用的是有效凭据，网络层没有理由干预。

但决定请求什么的并不是用户。这个决定是由一个大型语言模型做出的，它处理的上下文可能来自不可信的源头：工具描述、API响应、可能包含注入指令的用户输入。模型不会区分“来自用户的指令”和“隐藏在恶意GitHub Issue中的指令”，它一视同仁地处理。

这就是那个缺口。零信任验证调用者的身份和动作的授权，但它无法、目前也做不到验证动作背后的意图。当被攻破的MCP服务器让AI助手窃取数据时，助手会使用合法凭据通过合法渠道执行。你的SIEM看到的是正常API调用，你的DLP看到的是授权数据移动，你的身份提供者确认会话有效。

云安全联盟的智能体信任框架说得很直白：传统的零信任治理模型，并不是为这些根据动态组装的上下文自主行动的AI智能体设计的。你需要一个新的安全层，一个将上下文本身视为攻击面的新方法。

解剖一次典型的MCP攻击

理解MCP为何如此易受攻击，需要看看这些攻击的实际工作原理，因为它们打破了许多安全团队甚至没有意识到的假设。

• 工具投毒。 这类攻击最让人措手不及。MCP工具带有描述和元数据，用于告诉AI助手这个工具能干什么、怎么用。这些描述作为上下文的一部分被语言模型处理。它们不是代码，是自然语言。这反而让它们成了提示词注入的投递机制。攻击者可以在工具描述里嵌入隐藏指令。研究人员调查了2614个MCP实现，发现更糟的是，MCP工具在安装后还能修改自己的定义。
• “困惑的代理人”问题。 MCP服务器通常以用户在安装时授予的任何权限运行，而大多数用户授予的权限远远超出必要。当攻击者利用MCP代理服务器在未经适当同意下获取授权码时，这个代理就成了“困惑的代理人”：它拥有合法的凭证，却代表恶意方行事。
• 供应链污染。 传统的供应链攻击针对代码依赖，MCP供应链攻击则瞄准更微妙的东西：共享上下文。一个被攻破的MCP服务器可以向其他MCP服务器消费的上下文中注入虚假信息：伪造的API端点、污染的配置、误导性数据。下游服务器不知道上下文已被篡改，它们相信这些信息，因为MCP没有提供验证上下文完整性的机制。

数字不会说谎

暴露的规模之大，怎么说都不为过。

到2026年初，研究人员已编目了近7000台暴露在互联网上的MCP服务器，约占所有已知部署的一半，很多运行起来根本没有授权控制。其他调查则把这个数字推高到8000以上。

在深入研究的那些实现中：82%使用易受路径穿越攻击的文件操作，三分之二存在某种形式的代码注入风险，超过三分之一易受命令注入攻击。

企业采用率还在增长。Block通过其开源Goose智能体在全公司范围内部署了MCP，拥有超过60个内部MCP服务器。彭博社也放弃了内部自建的方案转投MCP。在安全故事还没讲清楚之前，协议的每月SDK下载量已经达到9700万次。

这就是矛盾所在。这协议已经深入骨髓，抽不掉；却又太不成熟，信不得。

协议规范自己怎么说，以及为什么没人听

MCP规范确实包含安全指南。它说实现“应该”对敏感操作永远有人参与。它推荐输入验证、访问控制和谨慎的权限界定。

但“应该”这个词在这里承担了太多重量。OAuth支持直到2025年3月（也就是推出五个月后）才被加入规范。红帽的安全分析指出，社区已经认识到，当前的授权规范包含了与现代企业实践相冲突的实现细节。

结果就是：大多数MCP部署把安全问题当成别人的麻烦。规范说“人要在环”，实现却是全自动；规范说“最小权限”，开发者为了图快直接给出全权限令牌；规范说“验证输入”，服务器却把未净化的输入传给了shell命令。

MCP推荐的做法和MCP实际部署的方式之间的缺口，就是每次数据泄露发生的地方。

加固：真正有效的做法

保障MCP安全，不必等协议自己修复。认真对待这个问题的组织，开始把MCP当作一个特权访问管理问题，而不是API集成问题。实践中是这么做的。

• 把每个MCP连接都当作特权访问通道。 MCP服务器连接应该像对生产环境的API密钥一样，被清点、分类和治理。这意味着要有一个已批准服务器的中心注册表，定期访问审查，自动发现环境中未授权的MCP端点。如果你连自己的开发人员在运行多少个MCP服务器都不知道，第一回合你就输了。
• 在上下文到达模型前净化它。 所有进入智能体上下文的东西，在模型处理前都需要扫描注入指令。这是传统安全工具力有不逮的地方，因为攻击载荷不是SQL注入或XSS，而是用自然语言告诉智能体去做用户并不想做的事情。
• 用短生命周期令牌强制执行最小权限。 别再把拥有“上帝模式”权限的个人访问令牌交给AI智能体。使用权限界定明确的专用服务账户，短生命周期令牌过期后需要重新授权，配合恰当的OAuth令牌生命周期管理和轮换机制。
• 对MCP服务器实施沙箱隔离。 与主机环境交互或执行LLM生成代码的MCP服务器应该被隔离运行。容器是最低要求。对于任何接触敏感数据的服务器，还需要加上gVisor、Kata Containers或SELinux加固。
• 切实落实“人在环”机制。 不是当摆设，而是作为敏感操作的实际审批工作流。规范说“应该”让人参与，对于任何写数据、发通信、改配置或访问敏感资源的操作，你必须把它变成“必须”。记录审批，审计动作，建立熔断机制。
• 监控工具变更。 MCP一个让人不安的特性是工具在安装后能改变自己的描述。你的安全团队需要检查这一点。在批准时对工具定义进行哈希处理，任何变化都要告警。一个在周一审查时看起来安全的工具，不应该在周五能悄无声息地变成一个数据窃取器。

治理难题

这一切发生的时间点很有趣。就在昨天，Anthropic将MCP捐赠给了Linux基金会新成立的自主智能体AI基金会，该基金会由OpenAI和Block共同创立。协议现在由供应商中立治理，并得到AWS、谷歌、微软等巨头的白金级支持。

这是正确的结构性举措，但它解决不了眼前的安全问题。基金会治理有助于长期的规范演进和社区标准，但它不能修补那7000台暴露在公网的服务器，不能给那些当初没有认证机制就上线的部署打补丁，也阻止不了明天可能发生的下一轮工具投毒攻击。

云安全联盟和红帽都发布了将零信任原则扩展到自主智能体AI系统的框架。微软正在努力统一身份和网络访问层，以处理AI智能体的认证。这些框架很重要，但它们在马厩门大开一年多之后才姗姗来迟。

令人不安的底线

MCP不会消失。它获得了所有主要云供应商、领先的AI公司，以及成千上万个已投入生产的部署的支持。问题不是要不要采用MCP，你的开发人员很可能已经用了。

问题是你的安全团队知不知道。

此时此刻，在成千上万的组织里，AI智能体正通过MCP服务器连接到内部工具。这些服务器由单个开发人员临时搭建，配置着全权限令牌，部署时没有认证，安全运营中心对此一无所知。这些连接中的每一个，都是你的零信任架构看不到也控制不了的特权访问通道。

这不是理论风险。过去十二个月的攻击时间线已经证明。工具投毒、命令注入、供应链攻击、跨租户数据暴露——这些攻击已经大规模发生，针对的正是大型组织。

修复方法并不复杂。只是之前没人为此做预算，因为MCP本应是一个图方便的开发者工具，而不是一个安全攻击面。清点你的MCP服务器，严格控制它们的权限，隔离它们的运行环境，净化上下文，监控工具变更，在关键环节引入人的审批。

或者，等着下一个CVE出来，然后在别人的数据泄露报告中读到它。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《MCP，那个被零信任架构遗忘的后门》