摘要： 本文解释为什么未来的多 Agent 系统不能继续只依赖共享 API Key、服务账号或“代表用户”的单一访问令牌。核心结论是：当一个任务被拆给规划 Agent、执行 Agent、审查 Agent和外部工具后，系统必须同时回答“谁发起、哪个 Agent 执行、运行在哪里、被授予什么权限、能否继续转委托、出了问题由谁负责”。Agent Identity 不是给机器人起名字，而是把身份、委托、最小权限、令牌绑定和审计证据连接成一条可验证的信任链。本文适合 AI Agent 开发者、MCP 平台团队、安全负责人和准备建设企业多 Agent 平台的团队，可直接用于身份模型设计、权限策略评审和分阶段改造。
核心结论
未来的多 Agent 系统需要 Agent Identity，因为“拥有凭证”不再足以证明“谁正在执行、代表谁执行、为何有权执行”。共享 API Key 只能证明某个秘密被提交，无法可靠区分用户、父 Agent、子 Agent、运行实例与本次委托；一旦多跳调用、长任务、动态工具发现和自主执行同时出现，权限膨胀、凭证重放、责任不清和审计断链就会成为结构性风险。
- 值得现在开始建设，但不应把尚在演进的标准当作全部成熟。 先建立主体模型、短期凭证、受众限制、委托深度和审计字段，再逐步接入 MCP Agent Identity、Workload Identity Federation 与 Token Exchange。
- 最重要的变化不是“Agent 拥有账号”，而是一次操作能够同时携带用户、Agent、工作负载和委托关系。 授权系统据此判断允许、拒绝或转人工审批。
- Agent Identity 必须与 Delegation 分开。 身份回答“它是谁”，委托回答“它代表谁、被允许做什么、能否继续转交”；只做身份认证仍然无法控制子 Agent 权限。
- API Key 不会立刻消失，但应退回到受控兼容层。 生产环境优先使用短期、限定 audience、限定 scope、可撤销且最好具备持有者证明的令牌。
- 企业落地重点是身份控制面。 IdP、工作负载身份、策略引擎、Token Exchange、审批、MCP Gateway 和审计系统需要共享同一套主体与委托语义。
Agent Identity 不是“给 Agent 一个用户名”
结论是：Agent Identity 是一个安全主体及其可验证上下文，不是模型名称、聊天机器人昵称或静态 client_id。一个 Agent 的“身份”至少要说明它属于哪个租户、由哪个应用实例运行、代表哪个用户或服务、使用哪个版本、处于哪个任务，以及当前凭证是如何取得的。
在传统 SaaS 中，用户登录后由后端调用数据库，身份链通常只有“用户—应用—资源”。多 Agent 系统却可能出现以下链路：
- 用户要求研究 Agent 生成市场报告。
- 规划 Agent 将任务拆给检索 Agent和数据分析 Agent。
- 数据分析 Agent调用代码执行器，并临时访问对象存储。
- 审查 Agent检查引用与敏感信息。
- 发布 Agent准备写入 CMS，但必须等待人工批准。
如果所有组件都使用同一个 TEAM_API_KEY，资源服务器只会看到“同一个调用者”。它不知道是用户直接操作、规划 Agent作出决策，还是某个被提示注入影响的子 Agent扩大了任务边界。即使日志记录了自然语言名称，也不等于密码学上可验证的身份。
因此，一个可用的 Agent Identity 模型至少需要四类主体：
| 主体 | 回答的问题 | 典型属性 | 不应被什么替代 |
|---|---|---|---|
| 用户主体 | 谁提出目标并承担业务权限 | user_id、tenant、group、assurance_level | Prompt 中的用户名 |
| Agent 主体 | 哪个 Agent 角色或实例作出决策 | agent_id、agent_version、capability、owner | 模型名或工具名 |
| 工作负载主体 | 代码实际在哪里运行 | workload_id、cluster、namespace、attestation | 长期服务账号密钥 |
| 委托主体链 | 谁把哪些权限交给了谁 | subject、actor、parent、scope、audience、depth | 单一 Bearer Token |
这里的关键不是让每个临时子 Agent都成为企业目录中的“员工”，而是让授权基础设施能够稳定识别它，并把它与用户授权、运行环境及当前任务绑定。
为什么共享 API Key 在多 Agent 环境中必然失效
共享 API Key 仍适合本地实验或单服务测试，但它不适合作为多 Agent 的核心信任机制，原因不只是“容易泄露”。更根本的问题是它缺少上下文、边界和委托语义。
无法区分主体
同一个 Key 被五个 Agent 使用时，服务端只能知道 Key 对应的账户或项目，不能证明具体调用来自哪个 Agent 实例。应用日志可以补充 agent_name，但攻击者同样可以伪造这个字段。如果 Agent 可动态创建子 Agent，身份混淆会进一步扩大。
权限通常只能做加法
为了让所有 Agent 都能完成任务，团队往往把多个权限集中到一个服务账号。规划 Agent可能只需读取工单，发布 Agent才需要修改 CMS，但共享凭证最终同时拥有读取、写入、删除和发布权限。一旦任何一个 Agent遭遇 Prompt Injection，攻击面就是全部权限的并集。
无法表达“代表用户”与“自身权限”的差异
Agent A 可以既拥有自身的机器权限，又代表用户 Alice 访问客户数据。授权判断必须同时考虑 Alice 的数据权限和 Agent A 的功能边界。只把 Alice 的 Token 传给 Agent，会让 Agent 看起来就是 Alice；只用 Agent 的服务账号，又会丢失用户授权范围。
多跳调用后审计失真
父 Agent 调用子 Agent，子 Agent 再调用 MCP Server。若每一跳都复制原 Token，所有日志都显示同一主体；若每一跳换成各自服务账号，则用户来源和委托关系消失。Agent Identity 所需的是受控 Token Exchange：每一跳产生受众更窄、权限不增加、有效期更短的新令牌，并保留 actor/subject 关系。
Bearer Token 被窃取后可重放
普通 Bearer Token 的逻辑是“谁拿到谁能用”。Agent 会接触网页、插件、工具输出和第三方 MCP Server，令牌暴露面大于传统单体应用。DPoP 等持有者证明机制把令牌与密钥绑定，可以降低令牌被复制到另一执行环境后直接重放的风险；它不是万能防护，但比裸 Bearer Token 更适合高自主调用链。
多 Agent 系统真正需要的身份模型
结论是：每次敏感操作都应形成一个“执行上下文”，而不是只附加一个 access token。这个上下文可以概念化为五元组：
Execution Context =
Human Subject
+ Agent Actor
+ Workload Instance
+ Delegation Grant
+ Task / TransactionHuman Subject：业务授权来源
用户主体决定数据可见范围、租户边界、组织角色和业务责任。例如，销售 Agent不能因为自身具有 CRM 工具能力，就越过用户原本无权查看的客户区域。
Agent Actor：自动决策者
Agent Actor 标识实际做出工具选择和参数决策的 Agent。它应至少关联所有者、用途、版本、风险等级和允许的能力集合。模型升级后如果行为发生变化，agent_version 能支持审计、灰度和撤回。
Workload Instance：代码执行位置
同一个 Agent 定义可能同时运行于开发机、CI Runner、Kubernetes 和第三方托管平台。工作负载身份用于证明“哪个受信环境正在运行它”。SPIFFE 官方将 SPIFFE ID 定义为唯一标识工作负载的字符串，SPIFFE/SPIRE 可通过工作负载证明发放短期 SVID，避免把长期秘密固化进容器镜像或环境变量。
Delegation Grant：被授予的能力
委托授权应包含目标资源、scope、audience、有效期、父级主体、最大委托深度和风险条件。RFC 8693 OAuth 2.0 Token Exchange 为交换安全令牌提供标准机制，可用于生成面向下游资源的更窄令牌。它并不会自动保证最小权限，实际收缩规则仍由授权服务器和策略系统实现。
Task / Transaction：为什么执行
相同 Agent 在不同任务中的权限不应总是相同。将 task_id、purpose、approval_id 或事务标识纳入策略与审计，可把权限限制在一次任务内，也便于在任务取消、完成或超时后撤销。
身份、认证、授权与委托必须分开设计
这四个词经常混用，但在多 Agent 系统中必须分开，否则策略无法解释。
| 概念 | 核心问题 | 示例 | 常见错误 |
|---|---|---|---|
| 身份 Identity | 主体是谁 | agent://finance/reconciler/v3 | 用显示名称当身份 |
| 认证 Authentication | 如何证明身份 | 签名、mTLS、SVID、IdP Assertion | 只检查自报字段 |
| 授权 Authorization | 当前能做什么 | 只读发票、不可付款 | 认证成功即全放行 |
| 委托 Delegation | 代表谁、能否转交 | 父 Agent将只读权限交给子 Agent | 复制原 Token |
Agent 的“自主性”不意味着它应该自行决定权限。恰恰相反，自主执行越强，权限决策越应外置到可审计的策略点。Agent 可以提出需要某项能力，但授权服务器、Gateway 或审批系统决定是否发放。
Agent Identity 如何建立可验证的委托链
一个安全的委托链遵循“每一跳重新授权”，而不是“原凭证一路透传”。推荐流程如下：
- 认证用户与入口 Agent。 企业 IdP 确认用户，Agent 平台确认入口 Agent 应用和运行实例。
- 创建任务上下文。 生成不可混淆的
task_id，记录目标、数据分类、风险等级和允许的最长运行时间。 - 父 Agent 请求委托。 它向 Token Service 声明目标子 Agent、目标资源、所需 scope、audience 和原因。
- 策略引擎计算权限交集。 新权限不得超过用户权限、父 Agent权限、子 Agent允许能力和任务策略的交集。
- 交换短期令牌。 按 RFC 8693 思路签发仅面向指定资源的 Token，必要时加入 actor/subject、delegation_depth 和 task_id。
- 绑定持有者或工作负载。 使用 DPoP、mTLS 或工作负载证明降低复制令牌后的重放风险。
- 资源服务器独立验证。 验证 issuer、audience、scope、时间、签名、持有者证明和组织边界，不能只信 Gateway 传来的普通 Header。
- 高风险操作转审批。 付款、删除、外发、发布、修改权限和生产数据库写入必须形成审批记录。
- 写入不可抵赖审计链。 同时记录用户、actor、父子关系、凭证标识、策略版本、工具参数摘要和结果。
下面是概念性的委托请求。字段用于说明设计思路，不代表 MCP 已规定统一 JSON 格式：
{
"subject": "user:[email protected]",
"actor": "agent:research-planner:v4",
"requested_actor": "agent:web-retriever:v2",
"task_id": "task_01J...",
"audience": "https://search-mcp.example.com",
"scope": ["search:read"],
"max_delegation_depth": 0,
"ttl_seconds": 300,
"purpose": "collect_public_sources"
}授权服务器签发的令牌应表达收缩后的结果，而不是照单全收：
{
"iss": "https://identity.example.com",
"sub": "user:[email protected]",
"act": { "sub": "agent:web-retriever:v2" },
"aud": "https://search-mcp.example.com",
"scope": "search:read",
"task_id": "task_01J...",
"delegation_depth": 1,
"exp": 1787702700,
"cnf": { "jkt": "BASE64URL_KEY_THUMBPRINT" }
}真实实现必须遵循所选 OAuth/JWT Profile 的正式字段定义，不能仅复制示例。尤其要验证 iss、aud、exp、签名算法、密钥来源和重放防护，拒绝未知字段覆盖策略。
MCP 为什么把 Agent Identity 列为后续重点
MCP 2026 路线图把“Agent identity and enterprise security”列为重点方向，目标是让 MCP Server 能识别 Agent 自身身份或用户委托身份。官方路线图明确提到 Workload Identity Federation、Enterprise-Managed Authorization 使用的 ID-JAG，以及标准 Token Exchange；DPoP 的最终化与推广也属于该安全方向。
这释放的信号不是“现有 MCP 已经解决所有 Agent 身份问题”，而是 MCP 正从工具连接协议向长期、跨服务的 Agent 基础设施扩展。此前 MCP 常见流程是用户在 Client 中登录，再访问某个 Server；未来一个非交互 Agent可能在后台运行数小时、创建子任务并跨多个 Server。没有身份与委托层，Agentic Messaging 越强，权限风险越大。
Enterprise-Managed Authorization 解决用户侧统一授权
MCP 的 Enterprise-Managed Authorization（EMA）允许企业 IdP 参与授权流程：Client 取得 Identity Assertion/ID-JAG，并向 MCP Authorization Server 换取可用令牌，避免用户针对每个 MCP Server 重复交互式授权。官方文档要求服务端验证 issuer、audience、签名和有效期等关键属性。
但 EMA 主要解决企业用户身份如何跨应用到达 MCP Server，不等于完整解决动态子 Agent 身份、运行时证明、委托深度和每一跳 Actor 链。企业仍需把 EMA 与工作负载身份、Token Exchange、Gateway 策略和审计结合。
Workload Identity Federation 解决“代码运行在哪里”
Workload Identity Federation 的价值是用云平台、集群或受信环境的工作负载证明换取短期凭证，避免在每个 Agent 容器中分发长期密钥。MCP 路线图提及这一方向，但具体互操作路径仍在演进。企业可先统一 workload_id 与 attestation，再适配后续标准。
DPoP 解决“拿到 Token 是否就能重放”
DPoP 是 RFC 9449 定义的应用层持有者证明机制。客户端为请求生成证明，授权服务器可签发与公钥绑定的访问令牌。资源服务器同时验证 Token 和 DPoP proof，从而降低被窃取令牌在另一处直接使用的风险。
DPoP 不会阻止已被完全控制的 Agent 在原运行环境内滥用权限，也不会替代 scope、audience、输入校验或审批。它解决的是令牌持有与请求方密钥之间的绑定问题。
企业身份控制面应该包含哪些组件
结论是：Agent Identity 不应由每个 Agent 框架各自实现。企业需要一个共享身份控制面，将身份签发、委托、策略和审计集中治理，同时让具体 Agent 框架保持可替换。
| 组件 | 主要职责 | 必须输出的证据 |
|---|---|---|
| Enterprise IdP | 用户认证、组织与组策略 | 用户主体、认证强度、租户 |
| Workload Identity Provider | 证明运行实例 | workload_id、attestation、短期证书/令牌 |
| Agent Registry | 登记 Agent、版本、所有者和能力 | agent_id、版本、风险级别、状态 |
| Token Service / STS | Token Exchange、受众限制、权限收缩 | jti、subject、actor、aud、scope、exp |
| Policy Decision Point | 统一计算允许、拒绝和审批 | policy_id、version、decision、reason |
| MCP Gateway | 执行入口控制、路由、限流和协议治理 | server、tool、request_id、decision_id |
| Approval Service | 高风险动作人工确认 | approver、scope、expiry、one-time nonce |
| Audit / SIEM | 关联完整调用链 | trace_id、task_id、parent_agent、result |
可直接采用的 Agent Identity 策略模板
下面的 YAML 是实施建议，用于把身份与委托规则显式化；它不是 MCP 官方配置格式。团队可映射到 OPA、Cedar、云 IAM 或自研策略引擎。
agent_identity_policy:
version: "2026-08-25"
defaults:
deny_by_default: true
token_ttl_seconds: 300
require_audience: true
require_task_id: true
max_delegation_depth: 2
allow_scope_expansion: false
workload:
require_attestation: true
allowed_trust_domains:
- "spiffe://prod.aistacknav.example"
sender_constraint:
required_for:
- "customer_data:read"
- "content:publish"
- "billing:write"
methods: ["dpop", "mtls"]
approvals:
always_required:
- "payment:create"
- "data:delete"
- "content:publish"
- "iam:modify"
audit:
required_fields:
- "trace_id"
- "task_id"
- "human_subject"
- "agent_actor"
- "workload_id"
- "parent_actor"
- "policy_version"
- "tool_name"策略执行时应使用权限交集：
effective_permissions =
user_permissions
∩ parent_agent_permissions
∩ child_agent_registered_capabilities
∩ task_policy
∩ resource_policy任何一层都只能缩小权限，不能通过委托扩大权限。如果某个子 Agent确实需要更高权限，应触发新的明确授权或人工审批，而不是沿用父 Agent的会话自动升级。
如需继续阅读 MCP 的基础认证、Gateway 和部署内容，可访问 AI Stack Nav 的 MCP 教程搜索，以及 企业 Agent 安全与权限治理专题。
从 API Key 迁移到 Agent Identity 的实施路线
不建议一次性替换所有凭证。更稳妥的方法是先获得可观测性，再收缩权限，最后引入强身份与跨域委托。
第一阶段：建立主体清单与调用账本
为每个 Agent 分配稳定 agent_id，登记所有者、用途、模型/代码版本、环境、可调用工具和风险等级。所有工具调用统一生成 trace_id 与 task_id，日志至少记录 human_subject、agent_actor、parent_actor、tool、resource、decision 和 result。
这一阶段即使仍使用旧 API Key，也能发现“谁在共用凭证”“哪些 Agent具有不必要写权限”“哪些调用无法追责”。不要把自报的 Agent Header 当作安全依据，它只是迁移期观测字段。
第二阶段：拆分凭证并缩短有效期
停止跨 Agent 共享 Key，为不同环境和 Agent 角色建立独立客户端；将长期 Key 放在 Secrets Manager，Agent 运行时只获得短期令牌。强制 audience 和 scope，确保给搜索 Server 的令牌不能用于 CMS Server。
第三阶段：引入工作负载身份
对 Kubernetes、云函数、CI Runner 和长期 Agent Runtime 使用平台身份或 SPIFFE/SPIRE 类工作负载身份。凭证必须由受信运行环境取得，不能通过 Prompt、工具参数或代码仓库暴露。
第四阶段：实现受控 Token Exchange
为父子 Agent和跨 Server 调用接入 STS。每次委托签发新的短期令牌，权限取交集、audience 指向唯一资源，并限制 max_delegation_depth。先在只读场景试点，再扩展到写操作。
第五阶段：加入持有者证明和人工审批
对高价值数据与写操作采用 DPoP 或 mTLS 等 sender-constrained token。付款、删除、发布、对外发送、IAM 修改和生产数据写入增加一次性审批，审批凭据只能用于指定参数摘要与短时间窗口。
第六阶段：执行撤销与攻防演练
测试以下情况：父 Agent 被撤销、子 Agent仍运行；任务取消后 Token 是否失效；旧 Agent 版本能否继续访问；Token 被复制到另一容器后能否重放；审计系统能否从资源操作反向追溯到用户与完整 Agent 链。
常见失败模式与排查方法
Token 有效但资源服务器拒绝
优先检查 aud 是否匹配当前 MCP Server、scope 是否满足具体工具、系统时钟是否漂移、DPoP proof 的 HTTP 方法和 URI 是否与真实请求一致。不要为了“先跑通”关闭 audience 校验。
子 Agent 获得了父 Agent 全部权限
通常是直接转发父 Token，或 STS 只复制 scope 没有计算权限交集。检查 Token Exchange 策略是否明确目标 audience、子 Agent登记能力与委托深度；默认应拒绝 scope expansion。
日志只能看到 Gateway
说明数据面丢失了主体链。Gateway 日志必须关联 human_subject、agent_actor、workload_id、parent_actor、task_id 和 token jti；资源服务器至少保存可信的 subject/actor 与 trace_id，不能只记录来源 IP。
Agent 重试导致审批重复消费
审批结果必须绑定操作参数摘要、task_id、actor、有效期和一次性 nonce。写操作需要幂等键。一次审批不应变成通用的“未来五分钟允许任意发布”。
工作负载身份正确但 Agent 角色错误
工作负载证明只能说明代码运行在某个受信环境，不一定证明加载的是获准 Agent 版本。应把制品签名、部署身份、agent_id 和版本登记结合，并在策略中限制允许的映像摘要或发布渠道。
风险、限制与边界
标准仍在演进
MCP 官方路线图是未来方向，不是所有能力的 GA 承诺。Agent Identity、Workload Identity Federation 和跨系统委托仍需关注后续规范与 SDK 互操作性。生产系统应通过适配层接入，不要把内部业务策略写死在单一草案字段上。
身份可信不等于行为可信
正确认证的 Agent仍可能被 Prompt Injection 影响、产生错误参数或在合法权限内做出错误决策。身份系统必须与参数校验、数据分类、最小权限、预算限制、速率限制、沙箱、输出过滤和人工审批配合。
过度细粒度会增加运维成本
如果每个短生命周期 Agent实例都需要人工登记，平台会失去弹性。可采用“Agent Definition 稳定身份 + Workload Instance 临时身份 + Task 临时委托”的分层方式，在可追溯与可扩展之间平衡。
审计数据本身是敏感数据
完整委托链可能包含用户、客户资源、工具参数和决策原因。日志应最小化、脱敏、分级授权并设置保留期限；不要把完整 Prompt、Token 或密钥写入日志。
跨组织信任最难
企业内部可统一 IdP 与策略，但外部 Agent、第三方 MCP Server 和跨云工作负载涉及不同 trust domain。必须明确谁信任谁的 issuer、如何分发密钥、如何撤销、如何限制 audience，以及发生争议时采用哪套审计证据。
事实依据与来源
- 官方已确认： MCP 2026 路线图将 Agent identity and delegation、DPoP、Workload Identity Federation、ID-JAG 与标准 Token Exchange 列为后续重点；路线图属于方向性规划，不是确定交付承诺。
- 官方已确认： MCP Enterprise-Managed Authorization 描述了企业 IdP、Identity Assertion/ID-JAG 与 MCP Authorization Server 之间的授权交换，并要求验证关键令牌属性。
- 正式标准： RFC 8693 定义 OAuth 2.0 Token Exchange；RFC 9449 定义 DPoP。本文关于它们基本作用的描述来自正式 RFC。
- 官方项目资料： SPIFFE 将 SPIFFE ID 用于唯一标识工作负载，SPIFFE/SPIRE 提供经过证明的工作负载身份与短期身份材料。
- 编辑判断： “Agent Identity 应由用户、Agent、工作负载、委托和任务五层共同表达”是本文为企业架构提炼的模型，不是 MCP 官方固定数据结构。
- 实施建议： YAML 策略、权限交集公式、审计字段和六阶段迁移路线用于项目设计参考，需要结合组织 IdP、IAM、法规和现有 Agent 平台验证。
- 未使用第三方 Benchmark： 本文没有引用性能、成本节省或攻击成功率数据，也没有宣称某一身份方案能够消除所有风险。
FAQ
Agent Identity 和用户身份有什么区别？
用户身份表示谁提出请求以及其业务权限；Agent Identity 表示哪个自动化主体作出决策并执行操作。生产调用通常需要同时保留两者：用户是 subject，Agent 是 actor。只保留用户会把 Agent伪装成人；只保留 Agent则丢失业务授权来源。
每个子 Agent 都需要一个独立账号吗？
不一定需要传统目录账号，但必须具有可区分、可验证和可审计的主体标识。可以登记稳定的 Agent Definition，再为每个工作负载实例发放短期身份，并按任务生成临时委托令牌，避免在企业 IdP 中创建大量人工维护账号。
有了 Agent Identity，还需要 API Key 吗？
兼容旧系统时可能仍需要，但 Key 应被限制在 Gateway 或受控凭证代理中，不应直接暴露给所有 Agent。新系统优先采用短期、受众限定、权限收缩且可撤销的令牌；高风险场景再加入 DPoP 或 mTLS 绑定。
MCP 现在已经完整支持 Agent Identity 吗？
不能这样理解。MCP 已有授权规范与 Enterprise-Managed Authorization 扩展，2026 路线图也明确推进 Agent identity and delegation，但完整的 Agent 自身身份、工作负载联邦与多跳委托仍在持续演进。企业应先建立内部身份控制面和适配层。
DPoP 是否等于 Agent 身份？
不是。DPoP 证明请求者持有与令牌绑定的密钥，主要降低 Token 被窃取后的跨环境重放；它不说明 Agent 的业务角色、用户授权来源、工作负载是否受信，也不决定允许哪些工具操作。
Workload Identity 与 Agent Identity 是同一件事吗？
不是。Workload Identity 证明某段代码或进程运行于哪个受信环境；Agent Identity 描述其逻辑角色、所有者、版本和能力。二者应绑定：前者防止身份材料被任意环境领取，后者支持业务授权和审计解释。
Token Exchange 会自动保证子 Agent 最小权限吗？
不会。RFC 8693 提供令牌交换机制，但是否缩小 scope、限制 audience、保留 actor 链和禁止权限升级由授权服务器策略决定。错误配置的 STS 仍可能把父 Agent的全部权限复制给子 Agent。
哪些操作必须增加人工审批？
至少包括付款或退款、删除数据、对外发送邮件或消息、公开发布内容、修改账号与权限、写入生产数据库以及导出高敏感数据。审批应绑定具体 task_id、actor、参数摘要、有效期和一次性 nonce。
如何判断 Agent Identity 改造是否有效？
从任意一条敏感资源操作出发，系统应能反向追溯到用户、Agent 版本、工作负载实例、父 Agent、任务、授权策略与审批记录；同时撤销父主体或结束任务后，下游凭证应在预期时间内失效，复制 Token 到另一环境也应无法直接使用。
参考来源
- Model Context Protocol：The New MCP Roadmap
- Model Context Protocol：官方开发路线图
- MCP Enterprise-Managed Authorization 官方文档
- MCP：Enterprise-Managed Authorization 介绍
- RFC 8693：OAuth 2.0 Token Exchange
- RFC 9449：OAuth 2.0 DPoP
- SPIFFE 官方概念文档
- SPIFFE Workload API
工具选型与提示词资料
适合阅读工具评测、工具推荐、对比测评类文章后继续转化。
