🧪 Beta — 能力已可用，接口契约可能微调。
Consent 与审批
授权确认（Consent）是委托体系里唯一不能自动化的环节：必须有人说了算。
但"人说了算"有三个不同的时刻，对应三种不同的产品形态和三种不同的风险画像。把它们分清楚，是设计一套既安全又不烦人的授权体验的前提。
为什么 Agent 需要它
没有授权确认，委托就只是"系统替你决定"。三个后果立刻出现：用户不知道 Agent 拿了什么权限（不可解释）、合规问不出"谁批准的"（不可追责）、出事无法界定责任边界（谁的锅）。
授权确认要解决的不是技术问题，是归责问题：让每一份 Agent 权限都能指回一个做过决定的人。
三种"人说了算"的时刻
| 时刻 | 谁在同意 | 什么时候用 | 代价 |
|---|---|---|---|
| 用户级授权确认 | 终端用户亲自点同意 | 面向具体个人的数据与操作 | 需要用户在场，有交互往返 |
| 组织级授权确认 | 组织管理员以组织名义预先同意 | 后台任务、成熟登录体系的自有应用 | 密钥即权力，加固要求高 |
| 运行时异步人审 | 特定操作触发时临时找人批 | 敏感、不可逆、高金额操作 | 打断自动化，需要审批通道 |
用户级授权确认
最直白的一种：Agent 要什么，就让用户看着答应。
用户被带到授权确认页，看清三件事——哪个 Agent、哪些权限、多长时间——点同意后回跳，你的应用换取委托令牌。整个流程见 快速开始 的 Step 2–3。
工作原理（责任方标注）：
- 你的应用 向 GenAuth 发起委托请求（
mode: "interactive"），声明 Agent、scope、有效期与回跳地址。 - GenAuth 返回授权确认页地址，同时落一条待确认的授权记录。
- 用户 在授权确认页完成身份认证并做出选择。身份从哪来取决于你的接入方式（见 整合原理）。
- GenAuth 校验批准人确实是被授权用户本人，签发一次性回调 code（消费一次即失效）。
- 你的应用 用 code 兑换委托令牌，拿到
grantId与audit_id。
一次性 code、批准人身份校验、回跳 state 校验——这三道是防止授权被劫持或重放的关键，都在 GenAuth 侧强制执行。
组织级授权确认
不是所有场景都有"用户在场"这个条件：夜间批处理没有人盯着；已有成熟登录体系的应用不愿把用户再赶去一次授权页。
这类场景走受信服务端集成：组织管理员预先以组织名义同意"本组织的这类 Agent 可代本组织用户执行这些 scope"，随后由持有访问密钥的服务端直接发起委托，无需用户逐次确认。
这条路径的真实含义与硬约束
组织级授权确认等同于以组织名义授权：持有访问密钥的一方可以为组织内的用户发起委托。因此——
- 访问密钥只能存在于服务端受控环境，绝不进客户端；
- 密钥的
allowedScopes/allowedAgents必须配置为最小集合，这是委托的第一道闸门； - 有效期给短，Agent 标识专用，审计要有告警。
访问密钥泄露即组织级风险。 完整硬约束清单与威胁分析见 安全考量。选择这条路径前，先读 接入你已有的认证体系 判断哪种接入方式更适合你。
两种确认方式都产出可审计、可撤回的委托令牌，区别只在"谁代表人做了这个决定"。文档不把组织级确认当作绕过授权的后门——它是授权，只是授权主体是组织。
运行时异步人审
🚧 Roadmap — 本节描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
有些操作不该由任何预先授权覆盖：转一笔钱、删一批数据、给客户发一封不可撤回的邮件。
这类操作的正确形态是运行时找人批：Agent 执行到关键一步时暂停，通过带外通道（推送、IM、邮件）找到负责人，负责人批准后才发放仅限该次操作的授权。这个模式在标准侧对应 CIBA（Client-Initiated Backchannel Authentication）——由后端发起、用户带外确认的认证流程，正是"审批人不在 Agent 会话里"这个难题的标准答案。
设计要点：审批请求要说清"Agent 想做什么、影响什么、为什么现在问你"；超时未批默认拒绝；每次审批独立入审计链。规划形态见 需要人批准时：异步授权。
标准与协议
- OAuth 2.1 授权码 + PKCE：用户级授权确认的交互流程基础。
- RFC 8693 Token Exchange：授权确认的产物（委托令牌）经令牌兑换换出资源访问令牌（见 Delegate Token 与缩权）。
- CIBA（OpenID Foundation）：运行时异步人审的标准形态。
下一步
- Delegate Token 与缩权 —— 确认之后签出的是什么。
- 第一次委托：30 分钟跑通 —— 亲手跑一遍用户级确认。
- 安全考量 —— 组织级确认的硬约束清单。