Keycloak 26.8 Token Exchange 委托机制解读：Agent 的身份 ID 是怎么进入令牌的

张善友2026-10-14 7:12

写于 2026 年 10 月 12 日。起点是 Skycloak 那篇《Keycloak 26.8 Token Exchange Delegation for AI Agents》，往下挖了 Keycloak 官方文档、RFC 8693、IETF 几个相关草案和主流厂商的方案。所有事实都带原始出处。

这篇博客在说什么

Keycloak 26.8.0 在 2026 年 10 月 1 日发布，其中一个不大不小的变化是：Token Exchange 的委托（Delegation）功能从实验状态升到了预览状态，并且加了一个新的委托类型------客户端委托（Client Delegation），官方定位就是给 AI Agent 用的（Keycloak Release Notes）。

机制本身不复杂。用户登录时，客户端在 scope 里带上 delegation:client:actor-app 这样的参数化 scope，Keycloak 校验这个叫 actor-app 的客户端存在、开着服务账号、并且拿到了 FGAP V2 里针对当前用户的 delegate 权限，然后弹一个同意页。用户点了同意，签发的令牌里就多一个 may_act 声明，里面写着这个 Agent 的服务账号用户 ID 和 client_id。之后 Agent 拿着这张用户令牌加上自己的 client_credentials 令牌去做一次标准令牌交换，换回来的是一张委托令牌：sub 还是用户，act 声明指向 Agent，没有刷新令牌，受众和范围取自 actor-app 自己的客户端配置（Keycloak Token Exchange Guide）。

就这么个东西。但它的意义在于，下游 API 第一次能在令牌里同时读到两个答案：数据是谁的（sub），这次调用是谁发的（act）。在这之前，Agent 要么拿着用户本人的令牌到处跑，要么用一个权限大得没边的服务账号冒充所有人------日志里根本分不出来。

为什么之前没法好好做

在 26.8 之前，让 Agent 接进系统基本只有两条路，都不体面。

第一条是把用户的访问令牌直接塞给 Agent。Keycloak 的 Token Exchange 文档把这条路的毛病列得很清楚：令牌没有受众控制，aud 绑的是用户登录用的那个客户端，Agent 拿着它可以去任何接受这张令牌的服务；没有范围收敛，用户能干什么令牌里就带什么；没有审计轨迹，出事的 Agent 在日志里和用户本人长得一模一样；用户从头到尾没被问过愿不愿意（Keycloak Token Exchange Guide）。

第二条是给 Agent 配一个服务账号，有时候顺手挂上 Admin REST API 的角色。Skycloak 博客说得直白：这种凭据一旦泄露，攻击者拿到手的攻击面就等同于一个管理员账号（Skycloak）。这不是假设------2025 年 8 月的 Salesloft-Drift 事件里，UNC6395 只靠从 Drift 集成偷到的 OAuth 令牌就波及了 700 多家组织的 Salesforce，全程没用恶意软件（Suzu Labs）。

背景数据也摆在那儿。CyberArk 2025 年的调查（20 个国家、2600 名安全决策者）显示企业里机器身份和人类身份的比例已经超过 80:1，接近一半的机器身份握着敏感或特权访问；CSA 2026 年 5 月的白皮书给出的平均值是 45:1，云原生环境高达 144:1（AccuroAI）。CSA 和 Oasis Security 2026 年 1 月的联合调查更难看：92% 的受访者不认为传统 IAM 管得住 AI 和非人身份的风险，78% 的组织连一份成文的 Agent 身份创建/注销制度都没有（AccuroAI）。OWASP 2025 年 12 月发布的 Agentic Applications Top 10 把"身份与权限滥用"排在第三位，定义就是利用被委托的信任、继承的凭据或角色链去拿不该拿的访问（Promptfoo）。

Gartner 2025 年 8 月的预测给这个话题又加了把火：到 2026 年底，40% 的企业应用会集成任务型 AI Agent，而 2025 年这个比例还不到 5%（Gartner）。微软在 Entra Agent ID 的发布材料里引 IDC 的数据说未来三年会出现 13 亿个 Agent（Microsoft Entra Blog）。数量上来之后，"这个调用是谁发的、代表谁、被谁授权的"就从可选项变成了审计和合规的硬需求。委托机制就是在这个夹缝里被推上台前的。

机制细节

版本脉络：从实验到预览，中间拆了一次

这个特性的演进速度值得留意，因为它直接影响你敢不敢用。2026 年 7 月 9 日的 26.7.0 第一次引入委托，当时是实验状态，scope 叫 delegation，授权靠 realm-management 里的 impersonation 角色（Keycloak 26.7.0 发布公告）。三个月后 26.8.0 升到预览，顺手做了两处破坏性改动：scope 改名成 delegation:user，另加了 delegation:client；授权整体搬到 FGAP V2，不再用 impersonation 角色（Keycloak Release Notes）。

预览状态在 Keycloak 里有明确定义：默认禁用、不建议上生产、后续版本可能改也可能删（Skycloak）。26.7 到 26.8 这次改名换模型就是这个风险的实景演示。另外 26.8 是个要停机的次版本升级------从 26.6.0 起 Keycloak 只支持同一版本线内的补丁级滚动升级，跨次版本得停掉所有旧节点迁 schema，进行中的登录流程会丢（WZ-IT）。用托管服务的话，特性开关在服务商手里，Skycloak 建议先问清楚集群上 token-exchange-delegation 和 parameterized-scopes 开没开、预览特性变更怎么通报。

三个构件怎么咬合

整套机制靠三个东西配合。参数化 scope 让客户端在 scope 名字里塞参数，delegation:client:<client_id> 指定客户端做 Actor，delegation:user:<username> 指定某个用户（一般是管理员）做 Actor。特性一启用，这两个 scope 会自动以 Optional 类型创建到所有 realm 里，包括已有的（Keycloak Release Notes）。

may_act 是事前授权的那一半。RFC 8693 第 4.4 节对它的定义是"声明某一方被授权成为 Actor 并代表另一方行事"，授权服务器可以凭它判断交换请求合不合法（MojoAuth）。有篇文章说得更到位：act 只是记录已经发生的事，may_act 才能阻止事情发生------两个声明里真正该被强制执行的是后者（AgenticFabriq）。

act 是事后归因的那一半。委托令牌里的 act 对象从 may_act 复制过来，资源服务器读它就同时拿到了数据属主和调用方。一个实现上的细节：delegation:client 会自动把 Actor 客户端塞进用户令牌的 aud，因为标准交换要求请求方必须在主体令牌的受众里；delegation:user 不做这件事，管理员要是从别的客户端发起交换，得自己用 Audience 映射器补齐（Keycloak Token Exchange Guide）。

完整流程

以 actor-app 这个 Agent 客户端为例，流程分两段：带同意的登录，和双令牌交换。

登录段：登录客户端带 scope=openid delegation:client:actor-app 发授权请求（这个客户端必须开 Consent required，不然直接 invalid_scope）；Keycloak 校验 actor-app 存在、启用、有服务账号，且服务账号通过 FGAP V2 持有当前用户的 delegate 权限；用户在同意页批准；签发的用户令牌带上 may_act（Actor 的服务账号用户 ID 加 client_id），actor-app 自动进 aud。交换段：actor-app 先用 client_credentials 拿自己的令牌，然后带着用户令牌做 subject_token、自己的令牌做 actor_token 调令牌端点；换回来的委托令牌 sub 是用户、act 是 Agent、无刷新令牌、受众和范围全部来自 actor-app 自己的配置（Keycloak Token Exchange Guide）。两次调用长这样：

http 复制代码 
# Agent 先拿自己的 actor_token
POST /realms/myrealm/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&
client_id=actor-app&
client_secret=XXXXX
http 复制代码 
# 再做委托交换，带上 actor_token 就走委托分支
POST /realms/myrealm/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
client_id=actor-app&
client_secret=XXXXX&
subject_token=eyJhbGci[...]&
subject_token_type=urn:ietf:params:oauth:token-type:access_token&
actor_token=eyJhbGci[...]&
actor_token_type=urn:ietf:params:oauth:token-type:access_token

交换时的校验列出来挺长一串：Actor 令牌验不过或类型不对；请求客户端对两张令牌里的任何一张既不是签发对象也不在受众里（这个返回 403 access_denied，其余失败是 400 invalid_request）；Actor 令牌解析出来的用户和主体令牌是同一个；主体令牌没有 may_act 或者它不是对象；may_act.iss 对不上本 realm 的签发者；may_act.sub 不是这个 Actor；may_act.client_id 和 Actor 令牌或请求客户端对不上（Keycloak Token Exchange Guide）。

还有个容易踩的坑：Keycloak 只校验 may_act 里的 sub、client_id、iss 三个字段，你用映射器往里塞的任何其他声明都会被原样复制进 act。所以那些扩展声明只能给日志和人看，绝对不要拿去做授权判断（Keycloak Token Exchange Guide）。

和服务账号、冒充摆在一起看

委托不是唯一选项，把它和另外两种常见模型放一起比较，选型就清楚了：

维度 纯服务账号 Agent 管理员冒充 客户端委托（26.8 预览）
令牌 sub 是谁 Agent 的服务账号 被冒充的用户 用户本人
调用方记录 Agent act 声明（26.8 起强制存在） act 声明，带 Agent 的 client_id
用户同意 无 无 每个登录会话都要
Admin API 暴露面 服务账号的全部角色 被冒充用户的权限 委托本身不给任何 Admin API 访问
适合的场景 无用户在环的自主任务，比如夜间对账 管理员进用户会话做支持排障 Agent 经用户同意后碰该用户的数据

纯服务账号在 Agent 完全自己干活的时候依然是对的。它的尴尬出现在 Agent 要碰具体某个用户的数据时------下游 API 要么信任它能访问所有人的数据，要么只能接受一个 Agent 自己报的、没法验证的用户标识（Skycloak）。

冒充在 26.8 里也有变化：冒充会话签发的令牌现在在访问令牌和 ID 令牌里都带 act，而且关不掉；CODE_TO_TOKEN、REFRESH_TOKEN 这些生命周期事件会带上 impersonator 和 impersonator_id；自省端点返回的 act.sub 从用户名改成了用户 ID，需要名字的消费方得改用新增的 preferred_username（Keycloak Release Notes）。三种模型真正的分野在于意图和同意：冒充是管理员走进用户的会话，委托是用户对一个指名的 Actor 预先授权，授权边界就是 Actor 客户端自己的配置。

安全保证和它的边界

委托令牌被故意做得很窄：只发访问令牌，签在瞬态会话里，不携带会话标识，所以没有刷新令牌。Agent 要持续干活就得反复走交换（Keycloak Token Exchange Guide）。内建的保证有几条：客户端委托不授予 Admin API 访问，哪怕客户端拿着服务账号凭据，泄露的委托令牌也提不了权；同意永不落盘，每个登录会话重新批准；委托令牌的 aud 和 scope 解析自 Actor 客户端配置而不是主体令牌，天然收窄；不带 actor_token 的请求走标准交换，而标准交换会拒绝任何带 may_act 或 act 的主体令牌------想借普通交换把委托声明"洗掉"是行不通的（Keycloak Release Notes）。

边界也有三条，架构设计时都得算进去。第一，may_act 理论上有旁路：直接配在客户端上的 Hardcoded claim 映射器也能造出这个声明，那条路没经过同意和权限检查。26.8 的应对是新增 may-act 客户端策略执行器，在每个带 may_act 的令牌响应上重新校验签发者、Actor 用户、delegate 权限和同意状态，还提供一个 Reject any may_act claim 开关------给所有不在 Agent 流程里的客户端默认挂上，很值（Keycloak Token Exchange Guide）。第二，撤销有缺口：撤销原始令牌不会撤销从它换出去的令牌，Keycloak 只在交换产出刷新令牌时才维护撤销链，所以短寿命访问令牌是主要手段（Skycloak Token Exchange 指南）。第三，一个 2026 年 9 月 24 日刚公开的漏洞 CVE-2026-97846：标准 Token Exchange V2 不执行 mTLS 持有者密钥绑定，一个配了"只发证书绑定令牌"的客户端，照样能通过交换端点在不出示证书的情况下拿到普通 Bearer 令牌。Red Hat 评 Moderate（CVSS 6.8，CWE-287），触发条件是同一客户端同时开着标准交换和证书绑定、且用客户端密钥这类非证书方式认证；写这篇的时候还没有修复版本（OpenCVE, GitHub Issue #53187）。Skycloak 给的临时缓解是把这类客户端的认证器换成 X509 证书认证、让资源服务器强制要求 cnf 声明、轮换可能泄露的密钥、盯 TOKEN_EXCHANGE 事件里的异常来源（Skycloak CVE 分析）。

配置清单和 26.7 迁移

给一个 Agent 客户端开委托，按官方文档整理出来的步骤如下。最大的坑放最前面：没有匹配的 FGAP V2 delegate 权限时，委托 scope 会被静默丢掉，登录照样成功，只是令牌里没有 may_act------Keycloak 会以 WARN 级别记下每一条被丢的 scope 和原因（Keycloak Token Exchange Guide）。

  1. 启动加特性：bin/kc.sh start --features=token-exchange-delegation,parameterized-scopes，两个委托 scope 自动建好。
  2. 建 Actor 客户端：机密客户端，开服务账号，开 Standard Token Exchange。
  3. 配下游受众：委托令牌的 aud 和 scope 来自 actor-app 自己的客户端 scope 和角色映射，只配 Agent 真正要调的 API。
  4. 登录客户端开 Consent required。
  5. Realm Settings → Admin Permissions 里启用 FGAP V2。
  6. 建委托权限：Users 资源类型上建带 delegate scope 的权限（保留 All users 就是任何用户都能被代理），策略选 Client 类型指向 actor-app；要按组收敛就改用 Groups 资源类型的 delegate-members。
  7. 登录请求带 scope=openid delegation:client:actor-app。
  8. 建议顺手把 may-act 执行器配上，流程外的客户端开 Reject any may_act claim。

从 26.7 实验版迁移过来有两处要改：scope 从 delegation 改成 delegation:user（比如 delegation:admin1 变成 delegation:user:admin1），授权从 realm-management 的 impersonation 角色改成 FGAP V2 的 delegate/delegate-members 权限------FGAP V1 完全不支持委托（Keycloak Upgrading Guide）。迁移过程中 delegation:user 和 delegation:client 会自动创建，确认没问题后旧的 delegation scope 可以删。还有一点：26.7 里没有 delegation:client，之前用管理员身份跑 delegation 的 Agent 应该挪到客户端委托，后者不需要任何管理员角色（Skycloak）。

标准层：这套东西不是 Keycloak 发明的

RFC 8693 里一个参数决定两种命运

Keycloak 的委托是 RFC 8693（OAuth 2.0 Token Exchange，2020 年 1 月发布）委托语义的实现。规范第 1.1 节区分了两种"代表他人行事"：冒充是 A 拿到 B 的全部权利、在那个上下文里和 B 分不出来；委托是 A 保持自己独立于 B 的身份------规范原话是"尽管 B 可能把自己的部分权利委托给了 A，任何行为都是 A 代表 B 做出的"，然后补了一句在 2026 年读起来很有预见性的话："某种意义上，A 就是 B 的 agent"（AgenticFabriq）。协议层面两种语义只差一个请求参数：带上 actor_token 产出的是带 act 的委托令牌，不带就是冒充令牌，附录 A.1.1 写得很死------"只有 subject_token 而没有 actor_token 时不可能发生委托"（MojoAuth）。

链式委托是 RFC 8693 里和多 Agent 系统直接相关、也最容易被实现错的部分。Agent A 代表用户干活，再把活转给 Agent B，规范用 act 嵌套来表达这条链：最外层 act 是当前 Actor，往里嵌的是更早的 Actor，最深的是最久远的那个。第 4.1 节有一条 MUST 级约束：资源服务器做访问控制时只能看顶层声明和最外层 act 标识的当前 Actor，嵌套的历史仅供参考（MojoAuth）。换句话说，五跳的 Agent 链不等于五个能强制执行的权限边界。还有一条常被忽略的："可见"不等于"受限"------act 让委托变得可见，但不自动收窄权限，范围收敛得靠每次交换时显式下放 scope，不然 Agent 拿着的还是用户会话期内的全部权限，这在语义上就又滑回冒充了（MojoAuth）。学术界的批评更尖锐：RFC 8693 把执行语义留给了实现方，资源服务器拿到的还是 Bearer 令牌，想还原委托链得自己解析嵌套 JSON（arXiv 2509.13597）。

IETF 的现状：个人草案很热闹，工作组很谨慎

2026 年的 IETF 是 Agent 身份标准化最热闹的地方，但热闹和成熟是两码事。查一遍 Datatracker 会发现：OAuth 工作组目前没有任何一份被采纳的文档是专门讲 AI Agent 的；截至 2026 年 8 月初，以 "agent" 为关键词的活跃互联网草案超过 200 份（搜索结果还被截了，实际更多），但全部停在个人提交状态，没有 IETF 背书（Crux Digits, SecurityBoulevard）。主要文档的成熟度分布画在下面这张图里。

规范 状态（2026 年 10 月） 和 Agent 身份的关系
RFC 8693 Token Exchange 正式 RFC（2020-01） act/may_act 委托语义的地基（RFC 8693）
OAuth Identity and Authorization Chaining -17 版，IESG 已通过，在 RFC 编辑队列 跨信任域传身份和授权上下文；全文没出现过 "agent"（IETF Datatracker）
Transaction Tokens -11 版，过了工作组最后征求意见 同一域内调用链的上下文传递（IETF Datatracker）
ID-JAG -04 版（2026-05-21），工作组草案 Okta XAA 和 MCP 企业托管授权的底层许可（AI Stack Current）
WIMSE 套件（架构/标识符/凭据/证明令牌） 多份工作组草案，零 RFC 把 Agent 当工作负载，发短期可验证身份（NHI Governance）
AIMS（AI Agent Authentication and Authorization） 2026-09-15 被采纳为工作组草案 AWS、OpenAI、Okta 等六方作者合写，主张用 WIMSE+OAuth 组合解决问题，不发明新协议（Mahasbini, llm4agents）
SCIM Agent Resource 扩展 个人草案 draft-wzdk-scim-agent-resource-00 Agent 的注册和生命周期供给，不管运行时授权（Pablo Formoso）
draft-mcguinness-oauth-ai-agent-instance 个人草案 -00 版（2026-07-04） 在 act 里携带经 attest 的 Agent 实例身份（SecurityBoulevard）
draft-niyikiza-oauth-attenuating-agent-tokens 个人草案 -01 版（2026-06-15） 批评嵌套 act 不可密码学验证、逐跳往返拖垮授权服务器可用性，提出可单调衰减的 Agent 令牌（MojoAuth）

从这张表能看出两件事。一是快要成为正式标准的文档都不是为 Agent 写的，而是被 Agent 场景复用的：Identity Chaining 已经过了 IESG、就差一个 RFC 编号，它把 RFC 8693 的令牌交换和 RFC 7523 的 JWT Bearer 许可串起来解决跨信任域问题。有观察者说得很准："对 SaaS 厂商的 Agent 访问客户数据这个场景，它是最接近标准的东西，而全文没有出现过 agent 一词"（Boston Identity）。二是真正为 Agent 写的东西正在向 WIMSE 收敛：这个工作组 2026 年 3 月才获批成立，宪章把"工作负载"定义成"为特定目的运行的软件实例"，通篇不提 AI；但 8 月工作组就 AIMS 草案（原来的 draft-klrc-aiagent-auth，核心主张是 Agent 不需要新协议，把 WIMSE 和 OAuth 2.0 家族组合对就行）发起了正式采纳征集，9 月 15 日收编为工作组文档（Freenode, Crux Digits）。这条"组合既有标准"的路线和 Keycloak 26.8 的做法如出一辙------委托就是 RFC 8693 语义加参数化 scope 加同意加 FGAP 策略，没有一行新协议。

ID-JAG 和 MCP 企业托管授权：跨域的那一半

Keycloak 的委托解决的是同一信任域内、用户和自家 Agent 的问题。跨信任域的场景------企业 IdP 替 Agent 向第三方应用做背书------靠 ID-JAG（Identity Assertion JWT Authorization Grant）。机制分两步：Agent 的客户端先在用户所在企业的 IdP 用 RFC 8693 交换把用户身份断言换成一张短期、单受众、签名的 ID-JAG，内容大致是"这位用户、在这家公司、被允许让这个客户端以这些 scope 访问那个资源服务器"；然后用 RFC 7523 JWT Bearer 许可把它递给目标应用的授权服务器换正式访问令牌。IdP 当经纪人，资源服务器保留自己发令牌的独立控制权（WorkOS）。草案由 Okta、Ping Identity 和独立贡献者合写，2026 年 5 月 21 日更新到 -04，目标是标准轨道但目前还是草案（TechJack）。Okta 的产品化实现叫 Cross-App Access（XAA）；MCP 规范已经把基于 ID-JAG 的企业托管授权收为官方扩展，2026 年 6 月 18 日达到 Stable------管理员在企业 IdP 里一次性授权某个 MCP 服务器，全员的客户端就免逐服务器同意页自动接入。Okta 是第一个支持的 IdP，Anthropic 在 Claude、Claude Code、Cowork 全线实现，Asana、Atlassian、Canva、Figma、Slack、Supabase 等已经接受这个扩展（WorkOS, ExplainX）。

放回 Keycloak 的坐标系看：Skycloak 的对比认为 26.8 的委托覆盖了那些厂商"Agent SSO"产品里的令牌层------用户交互式同意一个指名 Actor、Actor 是普通机密客户端、产出 RFC 8693 委托令牌------但不覆盖清单和发现层，信任锚定方式也不同（Skycloak）。怎么选大致有个判断：Agent 和它要调的 API 都在你手里、又希望用户逐会话批准，就用委托；Agent 要调信任你企业 IdP 的第三方 SaaS，就走 ID-JAG 这类跨域断言。Keycloak 在 ID-JAG 上算半个玩家：26.5 起以预览特性支持消费侧（RFC 7523 JWT 授权许可），发行侧------自己签身份断言和 ID-JAG------还停在提案阶段（Issue #43971）（Skycloak XAA 分析）。已经有人把两条链拼起来用了：Okta 当企业 IdP 签 ID-JAG，Keycloak 当资源侧授权服务器承兑，中间处理 SAML 到刷新令牌再到 ID-JAG 的两段兑换------说明"IdP 经纪人加 Keycloak 资源域"的跨域架构工程上跑得通（Christian Posta）。

调用链层和 Agent 之间

Transaction Tokens（TraT）管的是更微观的问题：一次外部请求触发的内部多服务调用链，怎么携带不可变、防篡改的上下文。入口服务向 TraT 服务器换一个绑定事务 ID 的短期令牌，链上每一跳都能验证调用上下文没被改过，草案到了 -11 版、过了工作组最后征求意见（IETF Datatracker）。业界的看法是它和 Identity Chaining 互补：一个管同一信任域内的调用链，一个管跨域交接，两份都被多篇 Agent 草案当组合件引用（Insights Boston Identity）。

Agent 和 Agent 之间的交互层是 A2A（Agent2Agent）：Google 发起、2025 年 6 月移交 Linux 基金会、2026 年 3 月发布 1.0.0 规范。它用 Agent Card------挂在 /.well-known/ 路径下的 JSON 元数据------声明 Agent 的能力、端点和认证要求，认证方案直接复用 OpenAPI Security Schemes（API Key、Bearer、OAuth2、OIDC、mTLS），Agent Card 可选 JWS 签名（Emissar）。学术研究基于 MAESTRO 威胁建模点出了 A2A 身份面的典型风险：伪造 Agent Card 投毒、任务重放、跨 Agent 权限提升，缓解靠 Agent Card 数字签名、可信注册中心和严格的 JWT 校验（arXiv 2504.16902）。但要清醒一点：A2A 规范本身不定义身份签发体系，它只说"需要什么认证"，不回答"这个 Agent 是谁"------后者还是得回到 OAuth/OIDC、SPIFFE 或 DID 这些身份层。

产品层：各家厂商的 Agent 身份答卷

2026 年"Agent 身份"从概念变成了采购清单，主要身份厂商基本都交卷了。微软在 2026 年 4 月让 Entra Agent ID 正式 GA：Agent 成为一种一等非人身份，有不可变的 Object ID，从可复用的"Agent 身份蓝图"派生来继承策略，不用密码不用密钥，只通过运行平台签发的令牌认证，条件访问、身份保护这些零信任控制面和人一样接入；发现和清单层在 2026 年 5 月 1 日并进 Microsoft Agent 365（每用户每月 15 美元，同日 GA），由它当统一的 Agent 注册表和控制平面（Microsoft Learn What's New, Wintive, CloudPartner）。Okta 走"目录加开放协议"路线：Okta for AI Agents 在 2026 年 4 月 30 日 GA，负责发现影子 Agent、指派人类属主、生命周期治理和一键熔断；Agent SSO 在 2026 年 8 月 24 日 GA、含在核心 SSO 计划里不另收费，把支持 XAA 的 Agent 注册成 Universal Directory 里的一等身份，通过 ID-JAG 向企业应用发身份治理下的短期令牌，首批生态伙伴有 Anthropic、Atlassian、Slack、Notion、Datadog、Figma 等 25 家以上（Okta 新闻稿, TechNode）。

方案 身份模型核心 怎么代表用户身份 状态（2026-10） 适合什么
Keycloak 26.8 客户端委托 机密客户端 + 服务账号，act/may_act RFC 8693 委托令牌（sub=用户、act=Agent） 预览，默认禁用 自建 IdP、Agent 和 API 同域、要逐会话用户同意（Keycloak）
Microsoft Entra Agent ID 蓝图派生的一等 Agent 身份（Object ID），无密钥认证 OBO 流程和自主流程分别发受众正确的令牌 GA（2026-04），治理要 Agent 365 许可 以微软 365/Azure 资产为主的企业（O-Mega）
Okta Agent SSO / XAA 注册进 Universal Directory 的 Agent 身份 ID-JAG 断言 → 资源域短期令牌 GA（2026-08-24），核心 SSO 免费 跨 SaaS、跨域的 Agent 连接（Okta）
Auth0 Token Vault 不给 Agent 发身份，改成保管下游凭据 用用户会话凭据换下游 token，Agent 碰不到原始密钥 GA，Privileged Worker 早期试用 Agent 要调 Google/GitHub 这类第三方 API 的场景（Auth0）
AWS Bedrock AgentCore Identity 入站校验 OIDC 令牌，出站用 Credential Provider 管凭据 默认出站用 Agent 自己的主体；可经 XAA/ID-JAG 桥接用户身份 GA，功能持续扩展（托管同意门户 2026-09） AWS 上的 Agent 运行时（Okta Blog）
SailPoint Agentic Fabric 用身份图谱治理 Agent（认证、访问评审、问责链） 治理层，不发行令牌 2026-05-11 发布，收购了 Entro 补 NHI 已有 IGA 体系的大企业（Futurum）
CyberArk → Palo Alto Idira 从特权访问管理切入：零常驻权限、JIT 特权凭据托管和会话监控 Secure AI Agents 2025 年底 GA 高特权 Agent 和 PAM 存量客户（TechInformed）
SPIFFE/SPIRE（开源） 运行时 attest 出来的 SVID（X.509/JWT），自动轮换 不承载用户身份，只回答"这个工作负载是谁" CNCF 毕业项目，生产成熟 云原生基础设施层的 Agent 身份底座（Stacklok）

拿这张表对照前面的机制分析，Keycloak 26.8 的位置就出来了：它是目前唯一把 RFC 8693 委托语义以标准形态内置进开源 IdP 的方案，而且刻意不做 Agent 注册表。Skycloak 说得直接------委托"覆盖了那些厂商 Agent SSO 产品所售卖的令牌层，但没有覆盖清单与发现层"（Skycloak）。资本市场的动作也印证了这个领域的热度：Palo Alto Networks 2026 年 2 月 11 日完成约 250 亿美元收购 CyberArk，是史上最大的身份安全交易；SailPoint 2026 年 6 月收了 Entro Security，Cisco 宣布收 Astrix，CrowdStrike 收了 SGNL------独立的 NHI 纯玩家基本不剩了（AccuroAI, GuptaDeepak）。

拆开看：Agent 的身份 ID 到底是什么

回到最初的问题。把各标准和产品实践摆在一起，Agent 身份标识可以拆成三个正交的层，不同方案在不同层给出了不同的标识符形态。第一层是稳定身份------这个 Agent 是谁：Keycloak 里是机密客户端的 client_id 加服务账号的用户 UUID（进 may_act/act 的 sub）；Entra 里是不可变的 Object ID，而且 Object ID 和 App ID 同值，授权决策引用起来方便；Okta 里是 Universal Directory 的 Agent 记录；SPIFFE 里是 spiffe://trust-domain/path 形式的 URI，靠运行时 attest 绑定到"这个进程、这个部署、这个上下文"，而不是一份静态密钥（Admindroid, Web of Mike）。第二层是实例身份------哪一个运行实例在干活：draft-mcguinness-oauth-ai-agent-instance 指出 OAuth 目前表达不了"Agent 平台的哪个实例在行动"，主张在 act 里带经 attest 的实例身份；AWS AgentCore 的会话和运行时标识也算这层。第三层是委托上下文------代表谁、被谁授权、为哪个任务：RFC 8693 的 act 嵌套链、Keycloak 的 may_act、ID-JAG 里的 sub 加 client_id 加 scope 组合都在这层。

标识符形态 示例 签发方 生命周期 强度和局限
客户端 ID + 服务账号 UUID actor-app / 9b8c7d6e-... IdP（Keycloak realm） 长寿命（对象级） 简单、和 OAuth 原生兼容；依赖 IdP 目录，不跨域
目录对象 ID Entra Agent ID 的 Object ID 企业目录 长寿命，带赞助人/属主 治理强（条件访问、生命周期）；厂商绑定
SPIFFE ID（URI） spiffe://prod.example/agents/analyst SPIRE 信任域 SVID 分钟到小时级轮换 和运行时 attest 绑定、免静态密钥；只认证不授权，得配策略层
ID-JAG 断言里的复合身份 sub(用户)+client_id(Agent)+aud(资源) 企业 IdP 分钟级一次性 跨域经纪人模式；要双方共同信任同一 IdP
DID（去中心化标识符） did:web:... / 链上注册 自治注册中心 长寿命，可验证凭据 跨组织互认潜力大；企业 IdP 生态集成弱
Agent Card URL /.well-known/agent-card.json Agent 运营方自发布 静态文档 发现友好；可被投毒，得靠签名和可信注册中心背书

这三层的划分背后有一条被反复引用的设计共识：Agent 应该持有自己的常驻工作负载身份，用户授权用每次调用的委托令牌单独承载------让 Agent 拿人的凭据会永久破坏归因，因为下游日志再也分不出 Agent 行为和人类行为（NHI Governance）。Keycloak 26.8 的委托恰好是这条共识的标准实现：sub 永远是用户，act 永远是 Agent，委托令牌本身是短寿命、窄受众的任务上下文。前面提过的那个工程细节在这里也说得通了------Keycloak 只校验 may_act 里的三个字段、其余原样透传，等于承认了身份声明的描述层和决策层必须分开：你可以给 Agent 贴各种标签用于日志和画像，但授权决策只能基于校验过的最小集合（Keycloak Token Exchange Guide）。

治理和合规的跟进

Agent 身份进入监管视野的速度比很多人预想的快。OWASP 2025 年 12 月发布、汇集了上百位安全研究者意见的 Agentic Applications Top 10 把身份与权限滥用列在第三位，缓解建议是拿"每个工具的最小权限画像"去约束 Agent 的凭据使用（NiteAgent）。NIST 这边，NCCoE 在 2026 年 2 月 5 日发了概念文件《Accelerating the Adoption of Software and AI Agent Identity and Authorization》，直接点破"AI Agent 常被当成没有专属身份、授权和问责控制的通用服务账号"这个企业安全缺口，提出以 OAuth 2.0、OIDC、SPIFFE/SPIRE 为基础做示范工程；2 月 17 日 CAISI 正式启动 AI Agent 标准计划，意见征集 2026 年 4 月 2 日截止，目前状态是评审意见中（arXiv 2605.06738, Armosec）。新加坡 IMDA 在 2026 年 1 月 22 日的达沃斯上发了全球首个 Agentic AI 治理框架，白纸黑字要求"每个 AI Agent 应具备可验证的数字身份"，配套措施包括作用域 API 密钥、逐 Agent 身份令牌和工具调用日志（arXiv 2605.06738）。

国内也在动。中国信通院 2026 年初牵头编写了《可信 AI 云 智能体交互安全 第 1 部分：身份与访问控制安全要求》，已经启动首批能力评估，评估覆盖智能体交互身份安全、访问控制安全、身份标识安全、身份凭证生命周期管理、身份认证审计与追溯五个维度（Zone.ci）。体系层面，信通院提出按"需求牵引、开放兼容、对等互认、互联互通"的原则建智能体身份标识体系：用 DID 构建智能体可信身份，用许可公有链做信任锚点，分布式部署的可信互联中心负责注册发现、DID 解析和资源管理，并且特别强调"互认而非接入"------各方保留自己的标识体系和治理自主权，靠共同规则实现跨体系的可验证互认（科技日报）。这条 DID 路线和 IETF 的 OAuth/WIMSE 路线是个有趣的对照：一个用去中心化标识解决跨组织信任，一个用既有身份基础设施的组合解决企业内外委托，但在"Agent 必须有自己的、可验证的身份标识"这一点上完全一致。

还没解决的问题

到 2026 年 10 月，Agent 身份标识还是一栋施工中的建筑，下面几个问题没有标准答案。

多跳委托链的可验证性。RFC 8693 的嵌套 act 是声明不是密码学证明，资源服务器被要求只信最外层 Actor，跨组织三跳以上的委托链目前没有任何厂商平台能给完整可见性------有人这样描述现状："你的内部 Agent 调外部服务、外部服务的 Agent 再委托给另一个，到第三跳身份链已经离开你的边界"（LinkedIn/Proof Not Promises）。draft-niyikiza-oauth-attenuating-agent-tokens 这类个人草案提的可单调衰减令牌是学术候选解，但没被任何工作组采纳。

撤销语义的系统性缺口。Keycloak 明说"撤销原始令牌不会撤销已交换出的令牌"，只能靠短寿命缓解。SSF/CAEP 的连续访问评估是业界给的方向------OpenID 互操作画像 2026 年 9 月底进入成员投票------但和委托交换的集成还没标准化（ControlArch）。

预览标签和版本漂移。Keycloak 委托从实验到预览的一次跃迁就带来了 scope 改名和授权模型更换两处破坏性变更；ID-JAG 至今还是可能逐版变动的草案，"实现方应钉住 -04 版并把协议视为进行中工作"（AI Stack Current）。

同意疲劳和自动化的张力。Keycloak 选了"同意永不持久化、每会话重新批准"，对交互式 Agent 合理，对长时间跑的后台任务就是反复打断；Okta/XAA 的答案是把决策集中到企业 IdP。两种哲学还没收敛，Okta 在 Oktane 2026 上也承认"控制不能变成又一层把 Agent 拖回人类速度的审批"（SecurityPointBreak）。

注册表层的碎片化。Entra 有 Agent Registry/Agent 365，Okta 有 Universal Directory，A2A 有 Agent Card，信通院在推 DID 注册中心，但跨体系的 Agent 发现和信誉机制基本空白------A2A 规范自己都说清楚不回答"当你只有一个品牌名时怎么找到可信的 Agent"（Emissar）。另外凭证泄露的土壤还在恶化：GitGuardian 统计 2025 年公开 GitHub 新增泄露密钥约 2900 万个（同比 +34%），AI 服务类密钥泄露涨了 81%，AI 辅助写的代码泄露密钥的比率约为人类基线的两倍（HackerStorm）。

怎么落地

对平台和身份团队：先在非生产 realm 开 token-exchange-delegation 和 parameterized-scopes 把流程跑通，第一步永远是建 FGAP V2 的 delegate 权限------缺了它 scope 被静默丢弃且不报错，这个坑会浪费你半天排查时间。确认用户令牌里出现 may_act 再做交换测试；顺手给所有不在 Agent 流程里的客户端挂上 may-act 执行器的 Reject any may_act claim；委托令牌寿命压到业务能接受的最短，接受"没刷新令牌、到期重新交换"这个设计（Skycloak）。客户端开了 mTLS 证书绑定的话，CVE-2026-97846 修复版出来之前，把认证器换成 X509 证书认证，让资源服务器强制校验 cnf（Skycloak CVE 分析）。

对应用和 Agent 开发者：把"Agent 持自己的身份、用户授权用委托令牌承载"当默认架构，别再把用户访问令牌往 Agent 上下文里塞。下游 API 的授权策略同时读 sub 和 act，就能写出"这个 Agent 可以读用户的日历但永远不能删事件"这种细粒度策略------这就是委托相比冒充的核心红利（Keycloak Token Exchange Guide）。涉及 MCP 的场景优先评估企业托管授权扩展（已 Stable），跨 SaaS 场景盯 ID-JAG 的草案演进、实现时钉住版本号。

对安全和治理团队：先盘点------哪些 Agent 在代表用户干活、哪些用服务账号自主跑、哪些还在用硬编码凭据；给每个 Agent 建身份档案（属主、用途、权限边界、退役日期）；把 delegate/delegate-members 权限的评审排进和管理员角色一样的周期；拿 OWASP ASI03 做一次专项威胁建模。最后再泼一次冷水：Keycloak 26.8 的委托是预览特性，不建议直接上生产。本文所有内容仅供技术研究参考，不构成安全合规或采购决策的专业意见。

本文基于 2026 年 10 月 12 日可获取的公开资料写成，涉及草案状态的描述有时效性，请以 IETF Datatracker 和各厂商官方文档的最新版本为准。

引用来源清单

Keycloak 官方文档

Skycloak 博客系列

标准与草案

技术分析与评论

学术论文

厂商资料

行业数据与安全研究

中国相关

热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会05如何新建文件夹？ 电脑新建文件夹的4种方法06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07Telegram APK 下载安装完整指南 — 2026年最新08Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）09轻量化AI渗透武器库｜ARTEX自主攻防系统、资产梳理、漏洞挖掘、链路分析全流程智能化落地10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新