MCP服务器安全警报：70%无认证暴露工具列表

当AI的"手脚"变成公共设施

AI智能体之所以能订机票、查数据库、发邮件，靠的是MCP（Model Context Protocol）服务器在中间牵线搭桥。你可以把它理解成AI和外部工具之间的翻译官——智能体发出指令，服务器用自己持有的凭证去执行。问题在于，这个翻译官太容易门户大开了。

据YouTube安全频道披露，Wiz Research在7月对公网可达的MCP服务器做了一次扫描，结果相当不好看：约70%的服务器会把完整的工具清单直接交给匿名调用者，不需要任何登录。换句话说，任何人路过都能看到这家"餐厅"后厨有哪些设备、能做什么菜。

不只是"看看菜单"那么简单

暴露工具列表已经够糟了，更麻烦的是42%的服务器在调用工具时真的返回了数据。这意味着匿名者不仅能知道你有什么工具，还能实际触发它们。部分服务器甚至暴露了创建和删除记录类工具——这类写操作一旦被滥用，后果远超信息泄露。

Wiz Research的扫描方法本身很简单：遍历公网IP，看谁在响应MCP协议。能扫到，说明这些服务器压根没做网络层隔离，也没配访问控制。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出并开源的协议标准，用于规范 AI 模型与外部数据源、工具之间的交互方式。它采用客户端-服务器架构：Agent 作为客户端发起请求，MCP 服务器负责对接具体系统（如数据库、邮件服务、云平台），并持有访问这些系统所需的凭证。协议本身定义了工具发现（tools/list）、工具调用（tools/call）等标准方法，使不同框架的 Agent 能以统一方式接入各类工具，无需为每个系统单独编写适配器。正因这层抽象，MCP 服务器实际上成了权限的汇聚点——谁能调用服务器，谁就能间接使用它背后的全部凭证。

mTLS（双向传输层安全）指客户端和服务器在建立 TLS 连接时互相验证对方证书，而非常见的仅客户端验证服务器。相比 API key，mTLS 的优势在于凭证不会以明文形式在请求头中传递，且证书可绑定到具体服务实例，便于在服务网格或零信任架构中做细粒度授权。OAuth 则更适合需要代表用户身份访问资源的场景，通过短期令牌和范围（scope）限制降低凭证泄露的影响。对 MCP 服务器而言，选用哪种方案取决于调用方是人、服务还是其他 Agent，但关键原则一致：匿名请求必须在网关层被拒绝，而不是依赖工具本身做判断。

为什么开发者会犯这种错

MCP协议的设计初衷是方便集成，快速把AI接到现有系统上。开发者在本地测试时，默认环境是可信的，省掉认证能少写一堆代码。等部署到公网时，很多人忘了补上这一层。本质上和当年Redis、Elasticsearch默认无密码如出一辙——技术栈换了，犯错的方式没换。

另一个因素是MCP服务器往往承载的是"内部工具"，开发者心理上觉得这些东西不敏感。但工具列表本身就是攻击面地图：知道你有"删除用户"工具，就知道该往哪打。

给开发者的三条硬建议

第一，别把MCP服务器直接扔公网。 需要远程访问就上VPN或零信任网关，至少加一层网络隔离。

第二，认证不是可选项。 API key、OAuth、mTLS，选一个能落地的方案。匿名调用在什么场景下都不该被允许。

第三，审一遍工具权限。 创建和删除类工具单独分组，加二次确认或审批流。42%返回真实数据的比例说明，很多调用并没有被拦截。

这不只是MCP的问题

每次AI基础设施出新协议，都会经历一轮"先跑起来再说"的野蛮生长期。MCP的便利性让它快速被各类Agent框架采纳，但配套的安全实践明显没跟上。Wiz Research这份扫描数据最有价值的地方，不是告诉你"有漏洞"，而是给出了量级——70%和42%这两个数字说明，默认配置就有问题，不是个别疏忽。

对使用MCP搭建内部AI助手的企业来说，现在该做的不是等官方补丁，而是先自查：你的MCP服务器，从外网能直接摸到吗？

零信任网关的核心理念是"永不信任、始终验证"，即不因为请求来自内网就默认放行，每次访问都要经过身份认证和授权检查。具体到 MCP 服务器，常见的落地方式包括：将服务器部署在私有子网，仅通过反向代理暴露；在代理层集成身份提供商（IdP）做 OAuth 校验；对工具调用按身份绑定权限，例如只读身份无法触发删除类工具。这种做法还能顺带提供审计日志，记录谁在何时调用了哪个工具，为事后追责和异常检测留下依据。