🧪 Beta — 能力已可用，接口契约可能微调。本页为混排页：〔三方交集〕与〔缩权只减不增〕两节属路线图能力，已在节内单独标注。

委托令牌（Delegate Token）与缩权（Attenuation）

委托令牌是一份可验证、带期限的授权凭据——它记录"哪个用户，把哪些权限，授予了哪个 Agent，多长时间"。它是一个 JWT（RFC 7519）：自包含、可离线验签，谁签的、给谁的、到什么时候，令牌自己说得清。

为什么不直接给凭证

把密码或长期 API Key 交给 Agent，等于交出整个身份：权限过宽、行动者不可区分、收不回来。这是经典 OAuth 客户端模型（RFC 6749）没有为 Agent 回答的问题——它假设"应用"的行为是设计时就确定的，而 Agent 在运行时推理，每次任务要的权限都不一样。

委托令牌把方向倒过来：Agent 拿到的不是你的身份，而是一份缩权的、带期限的、可撤销的授权切片。张三让报表 Agent 出周报，Agent 拿到的是"只读、仅报表类接口、两小时"，而不是张三的账号。任务结束，切片过期，什么都不留下。

三方交集：Agent 实际权限从哪来

🚧 Roadmap — 本小节描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。

一份委托能兑现多大的权力，不由任何单方说了算：

Agent 实际权限 = 人的真实权限 ∩ 显式委托范围 ∩ 企业批准边界

集合	谁定义	何时校验
人的真实权限	企业既有身份系统（Human IAM）	签发前评估——对应主骨架跳③：不能委托你没有的权限
显式委托范围	用户在授权确认（Consent）页勾选	签发时写入委托令牌
企业批准边界	管理员在 Agent 模板与策略上定义	签发与兑换时核验

三个集合缺一个，模型就有洞：没有第一个，员工能把自己没有的权限"慷慨"出去；没有第二个，授权失去用户的知情同意；没有第三个，企业对 Agent 的治理形同虚设。

缩权只减不增

🚧 Roadmap — 本小节描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。

缩权（attenuation）是贯穿全链的单向阀：权限沿着"人 → Agent → 资源访问令牌 → 下一跳"传递时，每一跳只能收窄，永远不能放大。

委托范围 ⊆ 人的真实权限（委托那一跳）；
兑换出的访问令牌 scope ⊆ 委托令牌 scope（兑换那一跳）；
多跳链上，每个 Agent 拿到的 ⊆ 上一跳（见三种访问模式的多跳小节）。

这不是 GenAuth 的私房规则。IETF 的 AAT 草案（Attenuating Agent Tokens）正在把"逐跳衰减的 Agent 令牌"标准化——缩权是 Agent 授权的标准演进方向，GenAuth 的设计与它对齐。

生命周期：签发、使用、终止

一份委托令牌的一生分三段：

签发——两条路径：用户级授权确认（interactive，用户亲自在确认页同意）或组织级授权确认（组织管理员以组织名义预先同意的受信服务端路径）。两条路径的定位与边界见 Consent 与审批。签发即分配 grant_id 与 audit_id，审计链从这一刻开始（见审计与追责链）。
使用——委托令牌不直接访问资源，先经令牌兑换换成访问令牌（见下节）。
终止——自然过期（有效期 60–86400 秒，按需从紧设置），或被主动吊销。吊销分层与各层生效时效，如实记录在吊销与应急处置。

令牌兑换：委托令牌不直接开门

委托令牌是"授权的存证"，不是"访问的钥匙"。要访问资源，Agent 先把它兑换（Token Exchange，RFC 8693）成目标资源的访问令牌。对应主骨架跳④⑤（全图见一次委托的完整旅程与端到端业务时序）：

签发（责任方：User × GenAuth，跳④）——用户确认授权后，GenAuth 签发委托令牌。它的受众（aud）不是任何业务资源，而是 GenAuth 自己的兑换服务：这份令牌只能用来换，不能用来开门。
发起兑换（Agent → GenAuth，跳⑤）——Agent 出示委托令牌，声明要访问的目标资源与所需 scope。
核验与铸造（GenAuth，跳⑤）——GenAuth 验证委托令牌的有效性与状态，将请求 scope 与委托 scope 取交集，铸造目标资源的访问令牌：sub = 用户、act = Agent、aud = 目标资源。
受限访问（Agent → App，跳⑥）——Agent 携访问令牌调用资源，资源侧校验 sub / act / scope 后只返回授权范围内的数据。资源侧怎么做校验，见保护你的 API：资源侧集成。

为什么要拆成两种令牌？三个理由：受众绑定——一份访问令牌只对一个资源有效，偷走也开不了别的门；策略重估——每次兑换都是一次实时裁决点：委托令牌已过期、发起它的密钥被停用、请求 scope 超出授权范围，兑换当场失败；审计连续——audit_id 从签发透传到兑换与访问，全链一条线（见审计与追责链）。

两种令牌的字段速览

委托令牌（示意，节选）：

json

{
  "sub": "usr_demo_0001",
  "agent_id": "report-agent",
  "scope": ["webagent.web_search:run", "webagent.web_search:read"],
  "audit_id": "audit_demo_7f3a2c41"
}

注意：委托令牌本身没有 act 字段——它记录的是授权关系，还没有发生"行动"。

兑换后的访问令牌（示意，节选）：

json

{
  "sub": "usr_demo_0001",
  "act": { "type": "eak_delegation", "agent_id": "report-agent" },
  "scope": ["webagent.web_search:read"],
  "exchange_id": "exch_demo_2b91d4"
}

act 是 GenAuth 扩展结构（非 RFC 8693 标准 act 的嵌套 sub 形式），资源侧解析注意事项与两种令牌的完整字段表，见 Token 与 Claim 参考。示例中 scope 从 run + read 收窄到只剩 read——这就是兑换环节的缩权在起作用。

标准与协议

RFC 8693（OAuth 2.0 Token Exchange）——令牌兑换与 delegation 语义的协议基座；GenAuth 实现其兑换流程，act 结构做了扩展（标注见 Token 与 Claim 参考）。
RFC 7519（JSON Web Token）——委托令牌与访问令牌的载体格式；GenAuth 实现。
RFC 6749（OAuth 2.0 Authorization Framework）——整个授权体系的底座；委托模型是其客户端授权在 Agent 场景的演进。
IETF AAT 草案（Attenuating Agent Tokens）——"每跳只收窄"的标准化方向；GenAuth 的缩权设计与之对齐。
ID-JAG / XAA——跨应用授权断言的同类演进路线，GenAuth 声明兼容路线图。

下一步

参考：Token 与 Claim 参考 —— 两种令牌的全字段契约
上手：让 Agent 代表用户调用你的 API —— 签发与兑换落到代码
概念：Consent 与审批 —— 授权切片是怎么被"同意"出来的

委托令牌（Delegate Token）与缩权（Attenuation） ​

为什么不直接给凭证 ​

三方交集：Agent 实际权限从哪来 ​

缩权只减不增 ​

生命周期：签发、使用、终止 ​

令牌兑换：委托令牌不直接开门 ​

两种令牌的字段速览 ​

标准与协议 ​

下一步 ​