MCP服务器安全危机：七成AI代理工具清单可被匿名访问

AI代理正在接管越来越多的工作流，而支撑它们与外部工具通信的MCP（Model Context Protocol）服务器，却暴露出令人不安的安全缺口。SecValley Insights第七期节目中，主持人Jessica与安全专家George围绕Wiz Research的扫描结果展开讨论，揭示了一个被忽视的事实：你为AI助手搭建的工具桥梁，可能正对全世界敞开大门。

MCP服务器到底是什么

用George的话说，MCP服务器是"AI代理与工具之间的桥梁"。代理发出请求，服务器凭借自身持有的凭证执行操作。问题恰恰出在这个"凭证"上——服务器不关心是谁在调用它，只关心自己能用什么权限去完成任务。

这意味着MCP服务器本质上是一个权限代理层。它把AI代理的意图翻译成对Microsoft Graph、数据库、SaaS平台的实际调用。一旦这个桥梁暴露在公网且缺乏认证，任何知道地址的人都能借用它背后的全部权限。

Model Context Protocol（MCP） 由 Anthropic 于 2024 年底提出并开源，是一套让 AI 代理以标准化方式调用外部工具和数据源的协议。其架构分为 Host（宿主应用，如 Claude Desktop 或 IDE）、Client（协议客户端）与 Server（工具提供方）三层，通信基于 JSON-RPC 2.0，支持 stdio 本地管道和 HTTP+SSE 远程传输两种模式。MCP 服务器对外声明三类能力：tools（可执行动作）、resources（可读取数据）和 prompts（预置提示模板），并可通过 list_tools 等接口把能力清单交给客户端。正是这个设计让服务器成为代理与外部系统之间的通用适配器，但协议本身并未强制规定认证方式——远程部署时是否要求 OAuth 或令牌校验，取决于实现者的选择，这是大量服务器默认裸露在公网上的技术根源。

Wiz扫描揭示的数字

今年7月，Wiz Research对暴露在互联网上的MCP服务器进行了一次扫描，结果相当不乐观：约70%的服务器会将完整的工具列表交给匿名调用者——不需要登录，不需要任何凭证。

更严重的是，约42%的服务器在工具被调用时返回了真实数据。部分服务器甚至暴露了可以创建或删除记录的工具。换句话说，攻击者不仅能看见这扇门后面有什么，还能推门进去改动东西。

George对此的评价很直接："比你希望的要糟糕。"

为什么这是身份问题而非配置问题

节目把讨论引向一个关键判断：MCP服务器的风险，本质上是身份（identity）问题。

设想一个典型场景：MCP服务器以应用权限调用Microsoft Graph的mail.read，而这个权限覆盖租户内所有邮箱，无需任何人登录，也没有MFA提示。那么，任何能访问该服务器的人——或者任何能向AI代理读取的内容中注入指令的人——都等于借用了这份租户级访问权。

这比传统的"弱口令"危险得多。攻击者不需要破解账号，只需要找到一台未加防护的MCP服务器，或者通过提示注入让代理替自己发出请求。凭证始终是合法的，日志里看起来一切正常。

应用权限（application permissions）与委托权限（delegated permissions） 是 Microsoft Graph 权限模型的两条路径。委托权限要求存在已登录用户上下文，操作以该用户身份执行并受其可见范围限制；应用权限则由应用自身的服务主体（service principal）持有，以守护进程方式运行，不需要任何用户登录，也不需要 MFA，作用范围往往是整个租户。典型的 Mail.Read 应用权限即可读取租户内所有邮箱，Sites.ReadWrite.All 可覆盖全部 SharePoint 站点。一旦这类权限被授予某个 MCP 服务器，服务器的凭证就成了绕过一切用户级管控的万能钥匙。审计时应重点关注 Entra ID 中授予了高权限应用角色的服务主体，并结合条件访问策略限制其来源网络。

提示注入（prompt injection） 是让 MCP 风险从被动暴露升级为主动攻击的关键环节。攻击者无需直接访问服务器，只需把恶意指令藏进代理会读取的内容中——一封邮件正文、一个网页、一份文档——代理在处理这些内容时就可能被诱导调用已连接的工具，以服务器持有的合法凭证执行读取或写入操作。由于请求确实来自被授权的代理，传统日志和权限检查都会判定为正常行为。这类攻击与 MCP 的暴露面叠加后，形成一条完整链路：公网可匿名列举工具 → 定位高权限服务器 → 通过注入驱动代理代为操作。这也是为何节目强调要将服务器访问控制与内容信任边界一并纳入设计。

本周就能做的三件事

George给出的行动建议尽量具体，避免停留在原则层面。

第一，先问一个问题： 哪个MCP服务器持有Graph凭证，谁能访问到它？找到之后立刻收紧访问控制。这是最高优先级的排查动作，因为租户级邮件读写权限的暴露影响面最大。

第二，每个远程服务器都必须有登录。 不是部分服务器，是每一个。每台服务器分配独立身份，只授予它实际需要的最小权限。共享凭证或过宽的应用权限，会让单点失守演变成全域失守。

第三，新接入的AI连接器需等待管理员审批。 让连接器的引入变成一个有记录、可审计的流程，而不是开发者随手配置就能上线。

可见性才是防护的起点

SecValley自身的做法是在每次扫描中标记那些持有租户级宽泛权限的服务主体，例如对每个邮箱都具备读写能力的情况。这个思路值得借鉴：在讨论如何加固之前，先弄清楚自己到底暴露了什么。

MCP生态仍处于快速扩张期，大量服务器由开发者自行部署，默认配置往往优先考虑可用性而非安全性。Wiz的数据说明，这已经不是个别疏忽，而是普遍现象。对使用AI代理的团队来说，盘点MCP服务器、审查其凭证范围、关闭匿名访问，是当前投入产出比最高的安全动作。

正如节目结尾那句半开玩笑的提醒：去找出那个Graph凭证。