GenAuth 是什么
GenAuth 是 Agent Identity 平台：为企业的每个 AI Agent 建立一等身份，并让人把权限显式地、可缩窄地、可撤销地委托给它。
它不替换你现有的身份系统。人的身份和权限仍然住在你既有的 Human Identity 体系里（自建 IdP、商业 IAM 或标准 OIDC 提供方）——GenAuth 做的是它上面缺的那一层：把人已有的权限，安全地借给 Agent 用一会儿。
先说清一件事：GenAuth 与 Qoni
GenAuth 是 Qoni 的身份层。Qoni 是一套 Agent 基础设施，除身份之外还包含记忆（GUMem）与行动（Web Agent）能力，三者共用一个 SDK、一个控制台、一套访问密钥。
所以 SDK 用 Anima 命名，而域名与端点沿用历史标识 eak，GenAuth 的能力挂在它下面：
| 你会看到 | 是什么 |
|---|---|
npm install @eazo/anima | Qoni 统一 SDK，本文档的所有代码示例都用它 |
dashboard.qoni.ai | Qoni 控制台，工作空间与访问密钥在这里管理 |
anima.delegateToken(...) / anima.genauth.* | GenAuth 的委托与身份能力 |
/api/v3/eak/... | HTTP 端点前缀 |
读文档时在域名或端点里看到 eak 不要疑惑——那是 Qoni 的门牌号。
权限的源头永远是人
这是全站的第一性原则，也是 GenAuth 所有设计的出发点：
Agent 拥有自己的一等身份——可注册、可审批、有责任人、可停用。但它行使的每一分权力，都是人从 Human Identity 体系里显式让渡的：可缩窄（缩权）、可审计、默认短时、可收回（分层手段与时效见吊销与应急处置）。
"人"有两种出场方式，两种都算显式授权，文档不回避任何一种：
| 出场方式 | 谁在同意 | 典型场景 |
|---|---|---|
| 用户级授权确认 | 终端用户亲自在授权页点同意 | 员工让 Agent 代自己取数据；C 端用户授权 Agent 查订单 |
| 组织级授权确认 | 组织管理员以组织名义预先同意，由受信服务端集成代为发起 | 后台批处理、定时任务、已有成熟登录体系的自有应用 |
两种都可审计、可撤回。区别只在"谁代表人说了这句话"——细节与各自的边界见 Consent 与审批。
能力：四个问题的四个答案
GenAuth 的能力清单不是功能堆叠，它是上一页那四个问题的逐条回答。每项能力都对应一个你必须答得上来的问题——答不上来的那几项，就是你现在的缺口。
最后一列是当前发布状态：可用能直接用；Beta 能用但接口可能微调；Roadmap 是设计已定、尚未发布。我们不把规划写成现状。
| 你要回答的问题 | 能力 | 具体是什么 | 状态 |
|---|---|---|---|
| 我有多少 Agent，各归谁负责？ | 注册与治理 | Agent 台账、模板与实例、注册审批、技术负责人与业务归属人、生命周期与一键熔断（身份模型、注册和管理） | Roadmap |
| 此刻以谁的身份、凭谁的授权在行动？ | 显式委托 | 授权确认（用户级/组织级）、委托令牌签发、令牌兑换（Delegate Token 与缩权、快速开始） | Beta |
| 能访问什么、不能访问什么？ | 访问控制 | scope 最小化、缩权只减不增、资源侧 sub/act/scope 交集校验（三种访问模式、保护你的 API） | Beta（资源侧集成 Roadmap） |
| 出事怎么收权、怎么追责？ | 吊销与审计 | 分层收权、audit_id 全链追溯（吊销与应急处置、审计与追责链） | Beta |
| Agent 要用户的第三方账号怎么办？ | 凭证托管与令牌派发 | 原始凭证永不出库，Agent 只拿短时令牌（Token Dispatcher、访问第三方服务） | Roadmap |
| 怎么和我现有的身份系统对接？ | Human Identity 整合 | OIDC 身份联邦、权限读取、scope 映射；MCP Server 授权（整合原理、接入已有认证体系） | Beta（部分 provider Roadmap） |
关于"多快能收回"
这是安全评审最常问的一句，直接给答案：停止继续签发是即时的（停用访问密钥）；已经签发到 Agent 手里的令牌无法单枚作废，以它的有效期为准——所以任务级委托建议只给分钟级有效期。完整的四层手段与各自时效见 吊销与应急处置。
与既有 Human Identity 的关系
一句话：Human Identity 是权限之源，Agent Identity 是委托之器。
GenAuth 通过统一的 provider 接口对接 Human Identity 体系——身份联邦解决"用户是谁"，权限读取解决"用户能做什么"，二者共同决定委托的上界。当前已实现与规划中的 provider 见 整合原理；接入路径见 接入你已有的认证体系。
部署形态与信任边界
GenAuth 掌管委托的签发，还托管第三方凭证——它在你的架构里是一个高价值组件，边界必须讲清楚：
- 两种形态：托管服务，或作为组件部署进你自己的 Kubernetes 环境（与既有身份系统同域）。
- 私有化形态下，委托数据、审计日志、托管凭证全部留在你的环境内，不出客户域。
- 访问密钥是最需要保护的东西：持有它就能以组织名义发起委托。保管要求见 安全考量。
数据边界矩阵、服务间认证、air-gapped 离线模式见 部署形态；四方信任关系见 系统全景与信任边界。
下一步
- 一次委托的完整旅程 —— 8 个瞬间，把上面这些能力串成一条线。
- 第一次委托：30 分钟跑通 —— 直接动手。
- 系统全景与信任边界 —— 架构师视角。