你的智能体管道，门户大开

这里有一句话，应该能让任何在跑 AI 智能体的人坐直身子。针对远程 MCP 服务器认证情况的首次大规模测量——MCP 服务器就是让智能体接触你的工具、文件、数据库的连接器——发现约 40% 完全不做任何认证就把工具暴露了出去。 Censys 数到了 12,520 个可从公网访问的 MCP 服务，其中大部分都没有认证。没有密码，没有密钥。 任何找到地址的人都能用这些工具。

这不是理论上的风险。MCP——模型上下文协议（Model Context Protocol）——是整个智能体浪潮赖以运转的管道： 它决定了智能体怎么拿到读你代码仓库、查你数据库、发邮件、调 API 的权限。整个行业把这层管道接进生产环境的速度快得离谱， 安全显然没跟上。另一轮对 40,000 个 MCP 服务器仓库的排查产出了 67 个新的 CVE， 连 NSA 都觉得有必要发布自己关于锁紧 MCP 的指南。当 NSA 都要为你的管道写一份备忘录时，说明这管道在漏水。

让我把为什么危险、以及到底该怎么办讲清楚，因为修法大多很无聊，也大多被跳过了。

一个敞开的 MCP 服务器到底意味着什么

MCP 服务器不是一份文档。它是一组暴露给任何连上来的智能体的动作：「读这个目录」「跑这条查询」「发这条消息」「调这个付费 API」。 这就是它存在的意义——给智能体一双真正的手。

所以「没有认证」不是说有人能读一个配置文件。它是说这双手对任何找到门的人都是现成可用的。 一个挂在公网上、没有认证的 MCP 服务器，就是一组能力——你的能力——递给了全世界。 取决于它包了什么，那可能是数据外泄、被删库、API 预算被掏空，或者一个往里深挖的立足点。 而且研究者还发现某个运行时 信任一个由客户端控制的归属标志， 让一个陌生人只要声称自己是所有者就能接管整个网关。就算有锁，也未必是真锁。

为什么会这样，以及为什么这事该你负责

这不是因为 MCP 特别糟。这是技术圈最古老的套路：一项强大的新能力扩散的速度，远快于围绕它的安全规范。 搭起一个 MCP 服务器很容易，教程都奔着「能跑起来」去优化，而认证是你打算「以后再加」的那一步——只是「以后」往往意味着永远不会。 把这个乘以每一个争着给自己智能体加更多工具的开发者，你就得到了 12,520 扇敞开的门。

它和我一直在提的一件事相连：你的智能体信任那个工具， 以及记忆和连接器是新的攻击面。 我们花了十年学会保护自己的 API 和正门。MCP 是一扇新门，开在同一栋房子上，而很多团队压根没把它当成一扇门看。

今天该检查什么

这里的防御手段并不玄。都是基本功，只是用在了一层大家忘了去用的地方：

• 给每一个 MCP 服务器加认证。没有例外。 如果一个服务器暴露了工具，它前面就得有一把密钥或令牌。 哪怕是只在内网用的服务器也需要认证——「它在我们网络里」早在几年前就不再是安全边界了。
• 除非非得如此，否则别把它放到公网上。 大多数 MCP 服务器根本没必要从公网可达。 绑到 localhost 或私有网络上，你就把自己从那 12,520 里摘出去了。
• 把工具权限收到最小。 一个只需要读的智能体，不该被递上写和删的权限。在工具这一层做最小权限， 能在真出事时限制爆炸半径。
• 不要信任归属声明。 在那个「客户端控制标志」的发现之后，别假定服务器自己的访问检查是靠谱的。 在你想保护的那个东西之外去验证身份。
• 盘点你暴露了什么。 这些敞开的服务器里，很多都被遗忘了——为了一次演示搭起来，从没关掉过。 你保护不了一扇你都不记得开过的门。

归根结底

智能体时代给你的技术栈加了一层强大的新东西——把真正的手递给软件的连接器——而推出它的速度，远快于有人去给它上锁。 40% 没有认证，不是「高水平攻击者」的问题；它是「门没关」的问题，攻击者只要走进来就行。 好消息是，修法既不光鲜也早被理解透了：给它加认证，别把它暴露出去，把权限收窄，然后搞清楚你到底在跑什么。

所以在你给下一个智能体再加一件工具之前，去看看你已经铺好的那些管道。智能体令人兴奋的部分是它们能做什么； 决定你会不会后悔的部分，是还有谁能让它们去做。眼下，对很多团队来说，答案是任何人——而这是一个一下午就能修好、 你绝不想一直拖下去的问题。