切换深色模式
火山引擎 Agent Identity：工作负载池、信任锚与身份传递
核对日期：2026-10-05。沿用 Google 篇 的场景，认证由本系统负责，业务授权由项目负责。部分官方页面直接读取为动态空壳，本次通过官方域名的搜索索引正文核对能力；没有执行 API 或登录控制台。字段、服务端点与版本仍需部署前核对。
1. 结论：重点在工作负载的信任建立
火山引擎的相关方案包含用户身份接入与工作负载身份体系。产品说明 本文重点分析 Workload Pool：以池划分管理边界，以工作负载身份标识 Agent，并根据凭证来源建立信任。工作负载池指南
它适合服务器 Agent 以及跨环境工作负载接入。对普通本地 Agent，用户登录、实例登记与软件来源验证仍需分别处理。
2. 官方概念
| 概念 | 在方案中的位置 | 本系统映射 |
|---|---|---|
| Workload Pool | 身份及信任关系管理边界 | 环境/团队隔离维度 |
| Workload Identity | 实际工作负载主体 | Agent 调用者标识 |
| Trust Anchor | 验证外部凭证的信任配置 | 固定且受管理的验证入口 |
| 元数据/选择规则 | 限定映射到哪个工作负载 | 身份映射条件，不替代项目授权 |
| 用户上下文 | 伴随 Agent 的用户身份 | 与工作负载分开保留 |
官方指南区分 AK/SK 与信任锚路径；信任锚有 token、volc_ecs 等类型。TIP 是工作负载访问令牌在身份传播中的用途，不能仅根据名字认定它是独立的跨厂商标准格式。S2
3. 架构
以下为本系统集成设计：
图：使用 imagegen 生成。蓝色表示厂商能力，青色表示本系统集成设计；凭证交换与检查顺序以下文为准。
Broker 不依赖客户端口头声明“已经通过信任锚”。它必须自己取得可验证的证据，或通过受认证的可信后端通道取得验证结果。
4. 本地 Agent：登录和软件来源分开
本系统设计：采用 OIDC 公共客户端、系统浏览器、授权码与 PKCE。若选用的用户池只提供某种服务端应用流程，增加服务端 Broker；不能把机密客户端密钥打包进桌面软件。
登录后以 issuer + subject 映射用户，为实例另行登记公钥。持钥证明验证成功可表示“当前请求持有已登记密钥”，不能表示“这份第三方程序是公司客户端”。来源字段保留 unverified，项目可根据证据自行决策。
跨任务调用时，从受保护会话读取用户绑定，不从提示词或工具参数提取身份。后台计划任务没有有效用户关联时，以工作负载主体执行。
5. 服务器沙箱：配置顺序与防串用
官方管理 API 包含 CreateWorkloadPool、CreateWorkloadIdentity、CreateTrustAnchor、BindWorkloadPoolTrustAnchor。完整字段以 API 参考为准。S2
本系统落地顺序：
- 按生产/测试及租户隔离要求建池，登记工作负载。
- 确定输入凭证来源。选择外部 JWT 时固定可信签发方与验证密钥；选择 ECS 时限定预期账号和实例范围。
- 配置信任锚并绑定到正确池，检查身份选择及元数据匹配条件。
- 用一组合法证据跑通；随后分别更换签发者、受众、实例、池和目标身份，确认不能串用。
- 最后添加用户上下文和下游身份传递，避免把基础工作负载映射故障与用户会话故障混在一起。
本系统设计要求：不要给不受信任客户端直接指定任意目标身份的能力。由已验证属性决定映射，或检查请求的身份是否与服务端登记一致。
6. 用户绑定 API 与配置契约
官方 GetWorkloadAccessTokenForJWT 参考列出 WorkloadPoolName、Name、UserToken，响应包含 WorkloadAccessToken 与 ExpiresAt。API 参考 使用官方 SDK/签名机制和控制台确认的端点；不要复制示例中的测试 Host 作为生产地址。
以下为本系统配置，不是火山 API 请求：
json
{
"provider": "volcengine-agent-identity",
"workload_pool": "prod-agent-pool",
"workload_identity": "report-agent",
"trust_anchor_type": "token",
"trusted_workload_issuer": "https://workload-id.example.com/",
"expected_workload_subject": "report-agent-prod",
"user_context_source": "verified-session",
"project_audience": "urn:company:project:demo"
}工作负载 JWT 与用户 JWT 是不同用途，不能复用一个全局 issuer 配置混着验证。对项目输出工作负载、用户（可空）、池映射、认证方法及证据时间；不直接暴露上游全部 claims。
目前核对的 API 字段不足以证明任意自建项目都能离线验证所有 TIP/WAT。接收端需要明确的验证协议、受众、签发者与轮换规则；缺少这些契约时，经 Broker 转换为本系统凭证。不得“Base64 能解码”就当可信身份。
7. 多 Agent 传递、撤销与授权
本系统设计：下游区分原始用户、当前调用 Agent 和本次目标。记录上游链路用于审计，但不能把可编辑的 origin_user 字符串当原始登录证据。
每跳按接收方支持的协议验证或换取目标凭证，不能把同一 Token 无限制转发。身份选择器只帮助确定主体，资源权限仍由项目决策。
撤销信任锚后，禁止通过旧路径继续签发；同时检查存量令牌可用多久。公钥轮换采用受控重叠窗口，删除过期公钥；不能遇到未知 key 就接受请求携带的新公钥。
8. 实施顺序与真实环境验收
先工作负载，再用户绑定，再多跳与撤销。以下均为未实测：
| 编号 | 验收动作 | 必须看到的结果 |
|---|---|---|
| V1 | 合法外部 JWT / ECS 证据 | 映射到预期工作负载 |
| V2 | 同密钥但错误 issuer/audience/subject | 不得命中合法身份 |
| V3 | 修改目标池或身份名称 | 不能逃逸原身份边界 |
| V4 | 将工作负载 Token 当用户 Token | 不生成虚构的人类身份 |
| V5 | 向非目标项目转发凭证 | 根据受众契约拒绝 |
| V6 | 解绑信任锚并轮换公钥 | 测得停止签发与存量失效窗口 |
9. 详细设计：如何建立可审计的工作负载信任
场景：同一企业既有火山 ECS 上的报表 Agent，也有外部集群的检索 Agent；两者可代表用户调用内部项目。以下映射规则、接口和生命周期是本系统设计，不新增对厂商 API 行为的假设。
9.1 管理边界应在登记时确定
建议生产和测试使用独立池或等价的明确隔离范围。登记时保存“谁能维护这个池、哪些签发方可进入、哪些工作负载可以映射”，而不只是保存一个池名称。
池内工作负载身份是逻辑主体。进程重启通常不应自动变成另一个逻辑 Agent；若需要追踪执行实例，另记录实例/任务 ID，并注明其证据来源。业务资源访问仍由项目决定，不能从“在生产池”推导“允许访问所有生产数据”。
9.2 外部 JWT 接入的逐步校验
- 凭证签发。 外部环境必须存在被管理员认可的签发机制。Agent 自签任意 JWT 不构成可信外部凭证。
- 确定信任配置。 接收方按预登记关系定位信任锚；不允许请求方同时提交任意公钥并要求立即信任。
- 验证凭证。 校验签名和配置要求的声明；完整 audience、时间和身份约束必须在所用版本中验证，未确认的能力纳入联调。
- 映射主体。 将已验证属性映射到准确工作负载。映射输入不可使用未验证的同名请求字段。
- 创建会话。 记录信任配置版本、验证时间、工作负载与可选实例证据。后续项目凭证寿命不超过适用的证据有效边界。
- 关联用户。 单独验证用户登录或可信任务绑定。工作负载 subject 不作为用户 subject。
官方信任锚和工作负载管理入口见 S2。上述逐步校验是本系统希望实现并验收的契约；若厂商一条路径不覆盖某项，需在适配层补齐，不能只在文档中宣称已校验。
9.3 ECS 路径如何与外部路径区分
ECS 平台证据适用时，应限定真实部署的账号和实例关联，不能接收 Agent 自报的实例 ID 就创建会话。外部集群没有相同平台证据时，使用其受信任签发方路径，不能为了统一配置假冒 ECS。
两条路径最后可以映射为同一类内部认证上下文，但必须保留不同 authentication_methods。项目需要限制运行环境时读取可信证据字段，而非字符串形式的厂商名称。
9.4 多 Agent 链路的身份传递
例如用户调用报表 Agent A，A 调用检索 Agent B，B 访问项目 C。本系统审计分别记录原始用户、当前调用者 A、当前执行者 B，以及 C 的受众。B 不能只透传 A 写入的 original_user 字段就声称用户已认证。
在每一跳，接收者明确接受哪种凭证、其受众是什么、如何验证、是否允许继续委托。若接收者没有 TIP/WAT 验证契约，改由 Broker 产生它能验证的内部项目凭证。凭证转换必须有可信输入依据，不能把“上一跳说已认证”作为依据。
官方 GetWorkloadAccessTokenForJWT 的字段见 S3；接口名称和返回字段本身并不回答所有接收端验证问题。
9.5 本系统最小接口
| 操作 | 输入 | 校验与输出 |
|---|---|---|
| 工作负载认证 | 平台证据 + 登记引用 | 固定信任验证，返回认证上下文 |
| 用户绑定 | 用户会话 + 指定任务/工作负载 | 产生短期单次绑定票据 |
| 项目凭证签发 | 有效认证上下文 + 项目引用 | 输出限定受众的内部凭证 |
| 会话撤销 | 所有者或管理员请求 | 状态版本更新，停止续签 |
这些操作的入参中，工作负载名字可用于查找登记，但不能独立证明身份。项目引用仅决定凭证用途，业务权限检查仍留在项目内。
9.6 生命周期与回滚
上线前先在测试池建立新信任配置，跑正反例，再将生产流量切到明确版本。回滚只能回到仍可信的配置版本；不能在故障时放宽 issuer 或元数据条件来恢复流量。
工作负载删除、信任锚解绑和签名密钥退休分别记录时间。对已发令牌采用短期过期或在线状态检查，并实测效果。若多个验证副本缓存配置，发布与回收要有版本号和刷新机制，避免一部分副本仍接受撤销来源。
9.7 反例如何设计才有意义
V1—V6 不应只测试随机乱码。使用同一可信密钥签出的“错误 subject”“错误 audience”凭证，才能验证系统没有把“签名正确”误当“身份正确”；使用另一个合法池和合法用户，才能验证真实隔离边界。
多跳测试中，A→B 正常的凭证直接拿给 C 必须按受众契约拒绝。并发使用同一用户绑定票据应只成功一次。审计中应能还原每跳的认证事实，不能只有最后一个 Agent 名称。