MCP安全核心是权限体系重设计，而非传统边界防护

Anthropic 的 Model Context Protocol（MCP）于 2024 年底投入生产。此后，它迅速传播开来。

自那以后，数千个 MCP 服务器被创建出来。Microsoft、Google 和 OpenAI 都采纳了它。Linux Foundation 接管了协议维护工作。如今，MCP 被视为关键基础设施。它位于 AI Agent 与其交互的工具和数据之间。大多数团队实现它的方式与实现任何其他集成标准相同：人们安装它，然后信任默认配置。

2026 年浮现的认知是：问题不在基础设施，而在于基础设施之下的权限层。

这一点很重要，因为它改变了人们处理 MCP 安全问题的方式。一个补丁解决的是某个特定服务器上的特定问题。而权限变更则需要提出一个复杂的问题。

"2026 年浮现的认知是：问题不在基础设施，而在于基础设施之下的权限层。"

为什么那个特定的服务器需要访问它根本不需要存在的东西？根据 SANS 2026 身份威胁调查（调查了 500 多名安全专家），76% 的企业注意到非人类身份的增加。74% 的企业使用依赖永久凭证独立工作的 AI 系统。同样的调查显示，没有任何一种防护措施（如审批流程、沙箱或日志记录）被超过 40% 的企业使用。

抛开个别披露不谈，相同的根本原因不断出现。2025 年 5 月，攻击者对 GitHub MCP 服务器使用提示词注入来获取私有仓库数据——不是因为服务器有传统意义上的 bug，而是因为它背后的个人访问令牌的作用域远比任务所需的要宽。几天后，Asana MCP 集成中的一个逻辑缺陷允许了跨租户访问，因为权限层从未强制执行客户之间的隔离边界。

安全研究人员现在将其归为几个可识别的模式：工具投毒（服务器自身的工具描述携带隐藏指令）和混乱代理问题（Agent 继承的信任超出了眼前任务所需）。

权限重设计实际要求你检查什么

不断出现的解决方案不是更好的扫描器，而是隔离访问。GitHub 的 Engineering Blog 在讨论开发安全的远程 MCP 服务器时，建议如下：每个实例必须拥有自己的、针对特定任务的密钥；所有请求必须限制为执行操作的用户；授权必须基于操作而非在用户认证后才假定。用动态生成的临时凭证替换固定的永久令牌。

"用动态生成的临时凭证替换固定的永久令牌。"

这个解决方案是分层的到目前为止一直在发挥作用。在 Webflow，我们将 MCP 集成视为与其他具有客户数据访问权限的第三方组件相同的方式对待。

团队给 AI Agent 的每个凭证在配置时可能都是个好主意。艰难的抉择不是那次访问在当时是不是个好主意——而是它现在还是不是，而大多数团队没有养成做这个决定的习惯。

集成任何 MCP 时需要考虑的事项：

这个凭证现在能访问什么，而不是它被设计的作用域是什么？访问权限很可能会蔓延。除非出了问题，否则不会安排任何审查。

授权是基于每个站点、每个仓库还是每个 Workspace授予的，还是全有或全无？对任何只提供组织级访问的集成都要警惕。如果一个集成在连接时不能让你控制作用域，这就是问题所在，不是脚注。

AI Agent 是继承了这个人的现有凭证，还是创建了完全绕过这些权限的新凭证？后者是这样的场景：GitHub 个人访问令牌可以比授权它的用户拥有更多对仓库的访问权限。

日志是否以与对人类相同的方式为 Agent 的行为分配责任？如果 Agent 的活动是不可见或无法归属的，事件响应只能从零开始。

Agent 的更改是直接进入生产环境，还是通过草稿、分支和审批队列等可审查流程？这不过是将团队已有的围绕人类访问控制的安全规范应用到一个新的实体类别上。

身份先于访问

在你能够讨论 Agent 被允许做什么之前，你必须回答一个更难的问题：就身份而言，Agent 是什么？目前对大多数行业来说，诚实的答案是"一个穿着 trenchcoat 的人类 OAuth 令牌"。Agent 没有自己的身份。它继承的是启动它的人的作用域、爆炸半径，通常还有实际凭证。

当 Agent 不再是短暂的存在时，这就是一个问题。如今大多数 Agent 的存活时间从几分钟到几小时不等：一个任务启动，Agent 运行，然后它消亡。但这种情况正在改变。我们正在走向存活数周甚至数月的 Agent，而一个存活那么长时间的东西需要自己的身份，而不是借来的身份——而且随着存活期的增长，权限应该越来越严格，而不是越来越宽松。

"目前对大多数行业来说，诚实的答案是'一个穿着 trenchcoat 的人类 OAuth 令牌'。"

把它想象成你带进来干一个下午的承包商与嵌入你的系统一个季度的临时工人之间的区别。你不会给下午的承包商一张永久徽章，你也不应该给一个运行一个季度的 Agent 与一个运行五分钟的脚本相同的访问权限。

OAuth 不是为此构建的，这不仅仅是一个缺失的功能——它是一种结构性错配，归根结底是一个 UX 失败：一个为有人类参与而设计的consent模型，被应用到了一个没有人类参与的过程上。

它的整个模型假设一个人坐在作用域对话框前做出明智的选择，我们都知道这实际上是怎么发生的：没有人阅读作用域列表，他们点击允许。当没有人类在阅读任何内容时，这个本来就不稳固的假设就完全崩溃了。

基础规范没有"此客户端是 Agent"或"此授权预期运行六个月"的概念，只有事后由服务器设置的过期时间。一些 IETF 草案开始勾勒出一个修复方案：将令牌生命周期与任务的实际生命周期绑定，并为 Agent 标记独立于调用它的人类之外的稳定身份。不过，这些仍是早期提案，不是已部署的标准。

对于"短期任务、较宽访问权限"和"长期 Agent、严格锁定"之间的界限在哪里，我们没有一个干净的答案。Webflow 的安全团队正在积极研究这个问题，我们正在与行业同行交流笔记，而不是假装我们已经解决了它。但这个框架本身很重要：将 Agent 存活期作为权限模型的一等输入来对待，而不是事后才想到的。

权限不是配置时的复选框

权限重设计、协议更新和身份模型代表了同一问题的三个不同层级。为了让每个层级保持有效，其他两个层级也必须有效。

如果你在第一天创建了具有正确作用域的凭证，但随后没有人验证该凭证仍然有效，你的努力就白费了。同样，如果你开发了一个终于能区分 Agent 与其背后的人类的新协议，但所有集成继续默认提供永久的、全有或全无的访问，你几乎没有做任何好事。这两种方法都没有解决两者根源的更深层问题：Agent 被允许做什么应该取决于它将存在多长时间。

"能够正确处理这个问题的团队，将是那些不再将作用域、身份和生命周期视为三次独立评估，而是开始将它们视为单一设置的团队。"

目前，几乎所有技术栈的组件都不知道如何提出这个问题，更不用说回答它了。能够正确处理这个问题的团队不会是那些开发了更高效扫描工具的团队。相反，他们将是那些不再将作用域、身份和生命周期视为每个 Agent 实例发生一次的三个独立评估，而是开始将它们视为每次 Agent 的功能或存在发生变化时都必须评估的单一设置的团队。

本文最初于 2026 年 9 月 9 日发表在 webflow.com 上。