MCP 发布了一个稳定的“Enterprise-Managed Authorization”规范；而其他的机器对机器（machine-to-machine）身份草案——包括一个 OAuth client-credentials 草案和两个开放提案——仍未完成。对于任何试图使用 Model Context Protocol 运行自主代理（autonomous agents）的人来说，这意味着目前的协议可以验证人类用户，但无法提供现成的、可证明无人值守进程身份的方法。

路线图为何至关重要

Model Context Protocol (MCP) 的路线图将代理身份和安全性列为重中之重。原计划发布四项内容：以人为中心的浏览器流程、面向服务的 OAuth client-credentials 流程、基于 DPoP 的令牌绑定，以及工作负载身份联合（workload-identity federation）机制。目前只有第一项——Enterprise-Managed Authorization——已达到稳定状态。

稳定规范的具体作用

Enterprise-Managed Authorization 让 IT 管理员能够通过单个控制台授予服务器访问权限，而无需每位员工都去批准每一次连接。该流程使用浏览器重定向和用户登录，因此笔记本电脑前的用户可以进行身份验证，随后服务器便会信任该用户的会话。

其局限性显而易见：该过程需要有人在键盘前操作。对于通宵运行、处理数据或响应警报的代理来说，没有人能去点击登录按钮。因此，任何依赖无人值守代理的部署都无法使用 MCP 目前唯一保证的规范。

草案选项及其缺点

两项草案扩展旨在为代理提供自身的身份：

  • SEP-1932 (DPoP) – 将令牌与公私钥对绑定，使被盗令牌失效。
  • SEP-1933 (Workload Identity Federation) – 让代理能够继承云平台中已配置的身份。

两者目前都以开放式 Pull Request 的形式存在，尚未合并到官方规范中。与此同时，另一个已记录的选项是需要预注册密钥（secrets）的 OAuth client-credentials 流程。将这些密钥存储在代理可以读取的地方会产生经典的攻击面：如果密钥泄露，任何攻击者都可以冒充该代理。

当前生产环境的实践步骤

由于该协议尚未提供原生的代理身份，团队仍可以通过将身份管理移至 MCP 之外来保障代理的安全：

  1. 在工作负载层签发可验证身份。 像 SPIRE 这样的系统可以生成与主机信任根绑定的短期证书，从而消除静态密钥。
  2. 在网关处终止凭据。 由前端服务持有 API 密钥或令牌，并代表代理转发请求，从而使密钥远离运行时环境。
  3. 基于验证后的身份进行授权，而非基于令牌内容。 将身份验证（谁在调用）与授权（他们可以做什么）分离，这样即使身份验证方法发生变化，策略仍能得到执行。

后续关注点

这两个开放的 Pull Request —— DPoP 绑定和工作负载身份联合 —— 是在 MCP 内部实现真正的机器对机器身份标准的唯一途径。如果社区将其合并，代理将能够在不暴露密钥的情况下，证明其拥有私钥或继承云端签发的身份。在此之前，任何生产部署都必须依赖外部身份框架，或者承担静态凭据带来的风险。

结论很明确：MCP 目前可以验证请求背后的“人”，但尚无法验证发起请求的“软件”。需要安全自主代理的团队不应等待规范落地；他们现在就必须在工作负载层构建身份，并密切关注待定的 DPoP 和身份联合提案。