15465个未治理MCP服务器暴露的授权鸿沟

一个数字背后的安全隐忧

一份新的注册表审计给出了一个引人深思的数字：15465个MCP（Model Context Protocol）服务器处于未治理状态。这项审计统计的是服务器数量，而非安全控制措施——但正是这一点让这个数字比它表面看起来更值得警惕。

当我们谈论MCP服务器时，实际上是在谈论AI模型与外部工具、数据源之间的连接桥梁。每一个服务器都可能是模型访问敏感数据、执行操作的入口。当超过一万五千个这样的入口缺乏统一的授权与治理机制时，安全边界的模糊程度可想而知。

MCP（Model Context Protocol）是由Anthropic于2024年底提出的开放协议，旨在为AI模型提供一种标准化的方式来连接外部工具、数据库、API和本地文件系统。可以将其类比为AI领域的"USB接口"——无论是搜索引擎、代码执行环境还是企业内部系统，只要实现了MCP协议，AI助手就能通过统一的方式与之交互。MCP服务器是协议的核心组件，负责将外部能力封装成模型可调用的工具（Tools）、可读取的资源（Resources）或提示模板（Prompts）。由于协议开源且接入门槛较低，社区在短时间内涌现出大量面向不同场景的MCP服务器实现，覆盖从文件操作、数据库查询到浏览器控制等数十个类别。

为什么“数量”比“安全控制”更值得关注

审计报告的核心洞察在于：它统计的是服务器的存在，而不是这些服务器是否配备了必要的安全控制。这种区别至关重要。

一个被治理的服务器意味着有人对其访问权限、身份验证、操作范围负责；而一个未治理的服务器则处于一种“无人认领”的灰色地带。当组织内部部署了大量这类服务器时，往往连基本的资产清单都难以维护，更不用说实施细粒度的授权策略。

授权鸿沟的本质

所谓“授权鸿沟”（authorization gap），指的是MCP生态在快速扩张过程中，工具连接能力的增长速度远超过安全治理能力的建设速度。开发者可以轻松地拉起一个MCP服务器，将其接入AI工作流，但很少有配套的机制去回答几个关键问题：

• 谁有权调用这个服务器？
• 服务器能访问哪些数据、执行哪些操作？
• 这些权限是否遵循最小权限原则？
• 出现问题时，能否追溯责任？

当这些问题在一万五千多个服务器上普遍得不到回答时，鸿沟就形成了。

最小权限原则（Principle of Least Privilege，PoLP）是信息安全领域的基础原则之一，要求任何系统组件只应拥有完成其预定任务所必需的最低限度权限。在MCP场景中，这意味着一个仅用于读取日历数据的服务器不应同时拥有写入文件系统或调用外部API的能力。违反这一原则的后果在AI代理场景下尤为严重——当AI模型被提示注入（Prompt Injection）攻击或意外触发错误指令时，过度授权的MCP服务器可能成为攻击者横向移动或数据泄露的跳板。提示注入攻击是指攻击者通过构造恶意输入，诱使AI模型忽略原有指令并执行攻击者意图的操作，而宽泛的工具权限会显著放大此类攻击的危害半径。

MCP快速普及带来的治理挑战

MCP协议的价值在于标准化了AI模型与外部世界的交互方式，这也是它迅速被社区采纳的原因。但标准化了“连接”并不等于标准化了“治理”。协议本身聚焦于互操作性，而授权、审计、合规这些企业级需求往往需要额外的框架来补足。

这种“先连接、后治理”的模式在技术采纳早期非常常见。企业为了抢占AI能力红利，倾向于优先部署，把安全治理留待日后处理。问题在于，未治理的服务器一旦规模化，事后治理的成本会呈指数级上升。

组织应如何应对

面对这样的现状，组织需要将MCP服务器纳入常规的资产与身份治理体系，而不是把它们当作临时的实验性工具。几个务实的方向包括：

建立MCP服务器的资产清单，做到心中有数——你无法保护你不知道存在的东西。为每个服务器明确责任归属和权限边界，落实最小权限原则。将MCP的访问纳入现有的身份与访问管理（IAM）框架，而不是另起炉灶。同时建立审计日志，确保每一次调用都可追溯。

审计报告提供的这个数字，本质上是一记警钟：AI工具生态的扩张不应以牺牲授权治理为代价。随着MCP在企业中的渗透加深，谁先补上这道鸿沟，谁就能在享受AI能力的同时守住安全底线。

身份与访问管理（IAM，Identity and Access Management）是企业安全体系的核心组件，负责管理"谁可以在什么条件下访问什么资源"。主流的IAM框架通常包含身份认证（Authentication）、授权（Authorization）、角色管理（RBAC/ABAC）和访问审计四个层面。将MCP服务器纳入现有IAM框架，意味着为每个服务器分配机器身份（Service Account），通过OAuth 2.0或API密钥等机制实现调用方身份验证，并基于角色而非个人设置访问策略。目前Anthropic正在推进MCP协议对OAuth 2.1的原生支持，部分企业级MCP网关产品也开始提供与Okta、Azure AD等主流IAM系统的集成能力，但在大多数自部署场景中，这些安全层仍需组织自行搭建。