跳到正文
博客园· 张善友·· 3 小时前AI 评分58

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

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

AI 导读

Keycloak 26.8.0 于 2026 年 10 月 1 日发布，把 Token Exchange 的委托功能从实验状态升到预览状态，并新增面向 AI Agent 的客户端委托类型。

正文

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

image

这篇博客在说什么

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 客户端为例，流程分两段：带同意的登录，和双令牌交换。

Keycloak 26.8 客户端委托流程

登录段：登录客户端带 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）。两次调用长这样：

# 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

# 再做委托交换，带上 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）。主要文档的成熟度分布画在下面这张图里。

Agent 身份标准成熟度地图

规范 状态（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 博客系列

标准与草案

技术分析与评论

学术论文

厂商资料

行业数据与安全研究

中国相关

来源：博客园 · cnblogs.com

Agent 智能体部署工程安全对齐MCP 与工具调用教程实践#教程/实践#Agent#安全/对齐#部署/工程#MCP/工具调用