MCP 正在把 Agent 身份列为协议重点，原因很直接：人在浏览器里点一次同意，覆盖不了用户离线时持续运行的云端 Agent。但截至 2026 年 8 月，MCP 还没有完成从人工同意到自主 Agent 身份的整体迁移。准确状态是一组不同成熟度的能力：已经发布的 OAuth 授权基线、稳定的企业扩展、若干底层标准，以及仍在推进的工作负载身份和持有证明提案。
这个区分很重要。路线图不等于生产控制。clientInfo 自报字段不等于已经认证的 Agent。令牌能够证明持钥，也不代表某个用户已经授权某个具体任务。
真正需要回答的问题是：MCP 资源服务器能否验证完整链条。哪个工作负载正在调用，哪个人或组织授权了它，授予的是哪个资源和动作，权限何时到期，如何撤销，以及事后能否复盘。
先看清 2026 年的成熟度地图
MCP 2026-07-28 授权规范是当前 HTTP 授权的生产基线。MCP Server 充当 OAuth Resource Server，MCP Client 充当 OAuth Client，授权服务器签发面向目标资源的 Access Token。该版本加入或强化了 issuer 校验、客户端凭据与 issuer 的绑定、resource audience、scope 指引和 Client ID Metadata Documents。授权对 MCP 整体仍是可选能力，STDIO 部署通常从环境获取凭据。
MCP 采用 OAuth 2.1 的安全模型，但OAuth 2.1 截至目前仍是 IETF Internet-Draft。更准确的说法是 MCP 按 OAuth 2.1 草案要求设计，而不是 OAuth 2.1 已经成为正式 RFC。
其余能力需要分层看待：
| 机制 | 它回答什么问题 | 2026-08-30 状态 |
|---|---|---|
| MCP Core OAuth | Client 能否访问某个 MCP Resource | 已进入 2026-07-28 正式规范 |
| Enterprise-Managed Authorization | 企业 IdP 是否允许 Client 代表员工访问 Server | 稳定的可选 MCP 扩展 |
| ID-JAG | 用户身份与委托如何跨越两个信任域 | IETF 工作组草案 |
| Workload Identity Federation | 哪个云端工作负载正在调用 | MCP SEP-1933，PR 仍为 Open |
| DPoP | Access Token 的提交者是否持有绑定私钥 | RFC 9449 已定稿，MCP Profile SEP-1932 仍为 Open |
| 父 Agent 向子 Agent 委托 | 如何把更窄权限交给子 Agent | 官方路线图方向，尚无完成的 MCP Profile |
MCP 新路线图把 Agent identity and enterprise-ready security 列为五个优先方向之一，并点名 Workload Identity Federation、ID-JAG、Token Exchange 和 DPoP。路线图描述的是后续方向，没有承诺这些能力已经进入核心规范，也没有给出确定发布版本。
一次 Agent 调用至少包含三种身份
Agent 身份这个词经常把多个主体压成一个标签。
第一层是人或组织主体。它回答谁承担责任，以及谁的权限构成授权上限。
第二层是工作负载身份。它标识 Kubernetes Service Account、SPIFFE Workload、云运行时或实际执行进程，回答哪个部署实例正在提交凭据。
第三层是逻辑 Agent 与任务权限。一个 Agent 可能跨进程迁移，也可能生成多个子 Agent；同一个工作负载也可能同时执行多个任务。这一层需要回答当前任务是什么、权限从哪里委托而来，以及它是否同时小于用户权限和工作负载的平台角色。
OAuth Client ID 无法自动覆盖三层。MCP 每次请求携带的 clientInfo 也只是自描述元数据。2026-07-28 Changelog没有把它定义成经过密码学认证的 Agent 身份。
共享 API Key 和长期 Service Account Token 的根本问题也在这里。它们能让请求通过，却把 actor、subject、task 和 authority 压进同一个可复用秘密。事故发生后，日志只能告诉你哪个 Key 被用了，无法证明哪个用户、Agent 或委托任务触发了动作。
稳定的企业扩展解决了什么
Enterprise-Managed Authorization已经是稳定的 MCP 扩展。它把企业 IdP 放在 MCP Client 与 MCP Server 授权服务器之间。用户先登录企业 IdP，Client 获得身份断言，IdP 签发 Identity Assertion JWT Authorization Grant，MCP 授权服务器再把 ID-JAG 换成自己的 Access Token。
这套机制减少了逐个 MCP Server 重复授权的浏览器流程。企业可以集中执行用户组、角色、条件访问、入职和离职策略，MCP Server 仍保留自己的 Access Token 与本地授权决策。
它解决的仍是企业用户委托，不是完整的云端工作负载身份。流程起点依然是用户 Identity Assertion。底层的 ID-JAG 规范也仍为 Internet-Draft。MCP 扩展已经 Stable，与底层 IETF 文档仍是草案可以同时成立，文章和系统设计都应保留这层差异。
Workload Identity Federation 还缺哪一步
SEP-1933提出 MCP Workload Identity Federation。Agent 工作负载不再额外持有一个长期 Client Secret，而是提交 Kubernetes、SPIFFE/SPIRE 或云运行时签发的短期 JWT。授权服务器验证可信 issuer 与 workload claims，再把该断言换成 MCP Access Token。
这个方向的价值在于复用执行平台已经管理的身份生命周期。Pod 终止后，旧凭据随之失效；工作负载迁移时获得新的平台身份；信任范围可以限定在 issuer、namespace、service account、audience 和部署策略。
SEP-1933 仍是未合并的开放提案。PR 的测试部分尚未完成，维护讨论仍把 Conformance Test 和 SDK Implementation 列为后续工作。因此它适合进入架构规划和受控实验，不适合被描述为 MCP 已完成标准化的工作负载身份。
它也只回答一部分授权问题。Workload Identity 可以证明哪个进程正在运行，却不会自动证明哪个用户授权了某个动作、任务是否落在委托范围内，以及子 Agent 获得的权限是否小于父 Agent。
DPoP 证明持钥，不证明业务授权
RFC 9449 DPoP把 Access Token 绑定到提交者控制的密钥。每次请求都携带该密钥签名的 Proof，攻击者即使窃取 Token，也难以在没有私钥时重放。
DPoP 的边界很窄。它不是 Client Authentication、Workload Identity 或授权策略。当前开放的 MCP DPoP 提案采用标准的 HTTP method、URI、Token 和 Key Binding，并没有把完整 JSON-RPC Tool Arguments 纳入 Proof。有效的 DPoP 可以证明提交者持钥，仍不能证明每个 MCP 工具参数在链路中没有被替换。
因此，各层能力应分别理解：
- Workload Identity 标识实际执行的机器主体。
- ID-JAG 在信任域之间携带用户身份与委托。
- OAuth Access Token 描述目标资源与授权 Scope。
- DPoP 通过密钥绑定降低 Token 重放风险。
- MCP 授权策略判断当前操作是否允许。
- Elicitation 或其他人工批准机制处理高风险升级。
其中任何一层都不能代替其余层。
生产环境需要一条可验证的委托链
生产设计应在每个资源边界签发专用 Token，而不是让用户原始 Token 穿过 Agent 和所有下游工具。可以把链条表示为：
人或组织策略
↓ 委托
逻辑 Agent 与任务
↓ 运行于
平台工作负载身份
↓ 交换
面向目标资源的短期 Access Token
↓ 在支持时绑定提交者密钥
MCP Resource Request
↓ 记录
Subject + Actor + Client + Resource + Scope + Task + Proof + Parent Delegation
有效权限应是四组权限的交集：
有效权限 = 用户权限上限
∩ 组织策略
∩ 工作负载角色
∩ 当前任务的专用委托
这能阻止一个高权限用户 Token 静默变成同样高权限的 Agent Token。子 Agent 也有了明确规则：它只能获得父 Agent 剩余权限的子集。
审计记录至少要保存稳定 subject identifier、workload issuer 与 subject、OAuth client、目标 resource、申请与授予 scope、token identifier、可用时的 proof-key thumbprint、task ID、parent delegation ID、policy decision 和 revocation status。只记录模型名称或 API Key，问责链仍然是不完整的。
安全测试才是迁移门槛
身份架构的可信度来自可执行的失败测试。允许无人值守 MCP 调用前，至少验证以下场景：
- 错误 issuer 或 resource audience 的 Token 必须被拒绝。
- 过期 Token 与已终止 Workload 的凭据必须失效。
- 启用 Sender-Constrained Token 后，重放请求必须失败。
- 子 Agent 申请父委托之外的 Scope 必须失败。
- 跨租户替换 subject 或 issuer 必须失败。
- 撤销父委托后，全部子委托必须同步失效。
- Agent 身份有效时，破坏性动作仍要触发权限升级或人工批准。
- 日志必须能重建人类主体、Workload Actor、任务、资源、策略决定与最终动作。
这些测试把 Authentication 与可问责的 Authorization 分开。请求可以携带有效 Workload Identity，同时仍然没有执行某个任务的权限。
现在可以部署什么
团队无需等待所有草案定稿。
现阶段可以使用 MCP 正式授权基线处理 issuer discovery、audience restriction、least-privilege scopes、issuer-bound client credentials 和短 Token 生命周期。企业用户场景可以采用稳定的 Enterprise-Managed Authorization。无人值守服务需要机器身份时，可以在受控网关后使用成熟的云平台或 SPIFFE Workload Identity 与 Token Exchange，同时把 SEP-1933 当作未来互操作目标。
MCP DPoP Profile 稳定前，相关实验应通过能力协商逐步启用。不可逆操作、权限升级和意图模糊仍应保留人工决策点。这与MCP Elicitation形成分工：身份层回答谁在什么既有权限下行动，Elicitation 在权限不足时创建可恢复的人工决策点。
这也不同于MCP 与 CLI 的接口选择。两种接口都能执行命令；远程无人值守调用额外要求每个资源边界都能证明 Actor 与 Authority。
MCP 正在接近这套答案。现行规范已经提供更强的 OAuth 地基，企业扩展解决了重要的用户委托场景，路线图也明确了剩余组件。2026 年更可靠的架构选择是保留每层差异，并用失败测试逐项验证。
常见问题
MCP Authorization 是什么？
它是 MCP HTTP Transport 的授权框架，规定 Client 如何发现授权服务器、注册、申请 Scope、获得 Access Token，并向受保护 MCP Server 证明自己可以访问目标资源。
Agent Identity 会取消人工同意吗？
不会。低风险、预授权、无人值守任务可以从每次浏览器确认迁移到显式委托和组织策略；破坏性动作、权限升级、模糊意图和新资源访问仍可能要求人工批准。
Agent Identity 与 Workload Identity 有什么不同？
Workload Identity 标识实际执行进程。完整 Agent Identity 还要关联逻辑 Agent、任务、被代表用户、父委托和权限范围。生产系统需要连接这些层，而不是把它们当成同一个主体。
MCP Workload Identity Federation 可以直接用于生产吗？
截至 2026-08-30，SEP-1933 仍是开放提案。云平台与 SPIFFE 的成熟 Workload Identity 可以先用于内部架构，但 MCP 级互操作仍应等待提案、测试与 SDK 稳定。
Enterprise-Managed Authorization 就是 Workload Identity 吗？
不是。前者传递企业用户身份与组织策略，后者标识实际调用的云端进程。无人值守企业 Agent 最终往往同时需要两者。