研究发现 MCP 访问策略有 20% 存在缺失或配置错误

Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.

Follow TNS on your favorite social media networks.

Become a TNS follower on LinkedIn.

Check out the latest featured and trending stories while you wait for your first TNS newsletter.

Bob 上个月搭了一个排程工具。他在一个周日下午向 AI 助手描述了需求，在晚饭前接入了 Slack 和三个内部 API，到了周一已有三个部门在用。这个故事很好笑——直到你去查它跑在哪个 token 上。

三周前的变化

2026 年 7 月 28 日，Model Context Protocol 的维护者发布了一项几乎完全围绕授权的规范更新：issuer 验证、issuer 绑定的客户端凭证，以及 Client ID Metadata Documents 作为客户端注册的首选方式。直白地说，这是协议的发起人在承认原有的信任模型没能扛住生产环境的考验。

如果协议的编写者都需要这样深度的安全检修，周日搭出来的工具也不可能获得豁免——而 Bob 根本没听说过 issuer 验证。

三种实际的破坏方式

工具描述携带的是指令，而不仅仅是文档。2025 年 5 月，Invariant Labs 的研究人员发现，GitHub 自己的 MCP server 可以通过一个被投毒的公开 issue 被劫持：攻击者在 issue 正文中插入的文本被 Agent 读取为指令，并使用受害者的 token 从私有仓库中拉取数据。没有被攻陷的代码，没有恶意的工具，只是一个没人想到要清理的描述字段。

2026 年有一个名为 MCPTox 的基准测试，对 45 个在线 MCP server 和 20 个模型测试了这一模式，测得平均攻击成功率 36.5%，最差模型高达 72.8%。Bob 的工具具有相同的基本形态：它读取 Slack 消息和工单文本来决定如何重新排序。它无法区分同事的请求和一条被精心构造为看起来像请求的字符串，因为没有人要求它去区分。

作用域默认是全开。常见的失败不是缺少权限模型，而是忽略了一个已存在的模型。一个只需要只读日历访问的 server，因为教程里用了 read、write 和 admin 全套，于是就申请了全套权限。在整个 MCP 生态中，88% 的 server 需要凭证才能运行，但实际上只有 8.5% 使用了 OAuth。

大多数正在运行的系统从未做过作用域划分，所以根本不存在作用域蠕变的说法。Bob 没有坐下来选择过一个作用域。他复用了密码管理器里一张已有的管理级 API 密钥——那是两年前他搭建报表看板时留下的，因为申请一个更窄范围的密钥意味着要提工单，而提工单正是他试图绕开的整个流程。

静态 token 不会轮换，而且没有人在监视它们不轮换。Splunk 自己的 MCP Server 应用在 1.0.3 版本修复前，一直以明文形式记录会话和认证 token，追踪为 CVE-2026-20205。那可是一家有专职安全团队的公司。

据估计，野外运行的 MCP server 中，有超过一半跑在静态 API 密钥或个人访问令牌上，而这些密钥几乎从不轮换；企业 AI 活动中接近一半是通过个人账户而非服务账户流转的，这意味着正在干活的那个凭证属于某个人的身份，而不是系统的身份。

Bob 的 token 就是那张报表看板的密钥。它自发放以来就一直有效，直到有人想起来去禁用它为止，而这个月它触碰过什么的唯一记录只存在于 Bob 的记忆里——那不是日志。

我们实际看到了什么

在过去的几个月里，我们在客户和潜在客户环境中搭建自己的 MCP 集成时，发现超过 20% 的 MCP 相关访问策略要么已经损坏，要么完全缺失。

我们发现超过 20% 的 MCP 相关访问策略要么已经损坏，要么完全缺失。

在大多数情况下，出问题的 MCP server 使用的是某人的个人 token 而非服务账户进行认证。这些 token 都没有文档化的轮换计划。这些 server 都没有触碰记录。如果 Bob 的工具也在那批里——按概率来说很可能是——在出事前没有人会知道，因为它现在根本没有被监控。

这一切并不意味着每个 vibe-coded 集成都需要经过变更审批委员会。Bob 搭的大部分东西是无害的，把每个周末项目都关进正式评审流程，正是让人们重新回到没人怀念的十八个月采购周期的最佳方式。治理有其自身的成本——代价是那些因为流程吞噬了让好点子得以落地的周末动能而永远没有发布的好创意。

问题不在于这些工具存在，而在于大多数组织目前无法区分无害的工具和那个拿着生产环境 token 的工具，而他们试图用同一个审批委员会来解决这个问题——而这个委员会正是让 Bob 绕道而行的原因。

现在每个平台团队面临的问题不是要不要允许 AI 构建的集成。这个决定已经在某个周末做出了，现场没有任何人。想要知道某个 MCP server 能触碰什么，取决于你是从一个刻意构建的资产清单里了解，还是在事后的事故报告里才知道。Bob 的排程工具还在跑。它还没有引发事故，而且很可能永远不会。

但 Bob 的工具和下一个上新闻的工具之间的区别不在于代码本身，而在于有没有人能说清楚它拿着哪个 token、能触达什么、以及上次轮换是什么时候。