为什么未来的多 Agent 系统需要 Agent Identity

摘要： 本文解释为什么未来的多 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 系统却可能出现以下链路：

1. 用户要求研究 Agent 生成市场报告。
2. 规划 Agent 将任务拆给检索 Agent和数据分析 Agent。
3. 数据分析 Agent调用代码执行器，并临时访问对象存储。
4. 审查 Agent检查引用与敏感信息。
5. 发布 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 / Transaction

Human 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 如何建立可验证的委托链

一个安全的委托链遵循“每一跳重新授权”，而不是“原凭证一路透传”。推荐流程如下：

1. 认证用户与入口 Agent。 企业 IdP 确认用户，Agent 平台确认入口 Agent 应用和运行实例。
2. 创建任务上下文。 生成不可混淆的 task_id，记录目标、数据分类、风险等级和允许的最长运行时间。
3. 父 Agent 请求委托。 它向 Token Service 声明目标子 Agent、目标资源、所需 scope、audience 和原因。
4. 策略引擎计算权限交集。 新权限不得超过用户权限、父 Agent权限、子 Agent允许能力和任务策略的交集。
5. 交换短期令牌。 按 RFC 8693 思路签发仅面向指定资源的 Token，必要时加入 actor/subject、delegation_depth 和 task_id。
6. 绑定持有者或工作负载。 使用 DPoP、mTLS 或工作负载证明降低复制令牌后的重放风险。
7. 资源服务器独立验证。 验证 issuer、audience、scope、时间、签名、持有者证明和组织边界，不能只信 Gateway 传来的普通 Header。
8. 高风险操作转审批。 付款、删除、外发、发布、修改权限和生产数据库写入必须形成审批记录。
9. 写入不可抵赖审计链。 同时记录用户、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

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包