AI Agent 身份与委托授权：Workload Identity 实战

AI Agent 身份是一组可验证的身份与关系，用于回答：哪个用户或服务发起任务、选择了哪个 Agent 定义、哪个 Runtime Instance 正在执行、委托了什么权限，以及哪个组件产生了每个副作用。单个标识符或 API Key 无法安全回答全部问题。

可落地的设计由独立 Principal、短期凭证、窄权限 Policy 和持久证据组成。模型可以选择下一步动作，但不能自行创造权限、转发用户 Bearer Token，或把认证成功解释成对象级操作已经授权。

核心结论

• 分离 Principal、Agent、Workload、Run、Tool、Resource 与 Operation Identity。
• Agent 名称、Manifest、模型身份或 Agent Card 在被可信系统认证前都只是元数据。
• 优先使用短期 Workload Credential，不共享 API Key 或继承用户 Session。
• 保留 Delegation，不要让 Agent 静默冒充用户。
• Token 必须绑定 Audience，并在每次向下游传递时缩小权限。
• OAuth Token Exchange 可以表达委托，但 Policy、Revocation 与资源鉴权仍由部署系统负责。
• 2026 年 Agent 相关 WIMSE 与 Transaction Token 提案仍在演进，不能当作已部署标准。

一次 Agent Run 中有哪些身份

Agent 请求通常同时包含多种独立身份：

这些 Identity 不能退化成用户可控字符串。LLM 输出 agent_id=finance-agent 并不能认证财务 Workload；Workload Certificate 能证明 Trust Domain 下的代码实例，却不能证明模型计划已获授权。

分开认证、授权与委托

三个问题必须独立：

1. Authentication：哪个 Principal 或 Workload 提交了请求？
2. Authorization：该 Actor 此刻能否对该 Resource 执行该 Operation？
3. Delegation：另一个 Principal 有意把哪些权限授予了该 Actor？

OAuth 2.0 Token Exchange（RFC 8693）定义了 Security Token Service 交互，可交换 Subject Token 和可选 Actor Token，并区分 Delegation 与 Impersonation，还定义了 JWT act Claim。RFC 有意把 Token Trust、Policy 与许多安全细节留给具体 Profile 和部署。

RFC 8707 允许 Client 指明目标 Resource，让 Authorization Server 签发受 Audience 约束的 Token。Resource 回答“在哪里使用”，Scope 回答一类“可以做什么”。二者都不能回答某张发票、某个 Repository、某个 Mailbox 或某笔支付当前是否允许。

Resource Server 仍需检查可信上下文：

allow =
  verified_issuer
  and expected_audience
  and active_token
  and recognized_workload
  and principal_delegated_this_operation
  and tenant_matches
  and object_policy_allows
  and current_state_allows
  and approval_is_bound_and_unexpired

Workload Identity 是基础层

SPIFFE 为动态、异构环境定义 Workload Identity 与短生命周期 SVID。Runtime 可以 Attest 工作负载并获得 X.509 或 JWT 身份，而不必把可复用 Secret 烘焙进 Image。

它解决了“哪个 Workload 正在连接”这一层，但不定义：

• Agent 的任务或 Mission；
• 哪位用户委托了权限；
• 精确业务对象或金额；
• Sub-agent 如何继续缩小权限；
• Approval 是否仍有效；
• 副作用是否已经发生。

应使用 Workload Identity 认证连接 Credential Broker 或 Resource Server 的代码，再使用应用 Policy 与 Delegated Grant 决定它可以做什么。

NIST 2026 年 Agent Identity 指导也强调：Agent 应成为具有独立标识和 Entitlement 的一等实体，同时把权限绑定到运营它的用户或系统；共享凭证、静态长期 Token、宽权限和审批疲劳都是应避免的模式。

保留 Actor Chain

委托至少应保留 Subject 与 Actor：

• sub：权限所代表的 Principal；
• act：代表 Principal 执行的 Workload 或 Agent；
• aud 或 Resource Indicator：目标 Resource Server；
• Scope 或 Authorization Details：允许的操作类别；
• Object 与 Constraint：应用层 Resource、Amount、Destination、Purpose 和限制；
• Run 与 Operation ID：关联与 Replay Control；
• Expiry、Issuer、Token ID 与 Proof Key：生命周期和 Token 使用限制。

每经过一次 Delegation Hop，权限应保持或收窄。Child Agent 不能因为 Parent 把上下文复制到 Prompt，就获得新的 Tenant、Resource、Tool、Amount、Destination 或 Lifetime。

RFC 8693 可以携带嵌套 Actor 信息，但不会自动强制严格的权限衰减。新兴 WIMSE Credential Delegation 与 Agent Transaction Token 草案尝试组合更具体的 Agent 委托和调用链上下文。截至本文撰写时它们仍是 Internet-Draft，可能更新或失效。应把它们当设计输入，在实验中固定 Revision，不能直接声称跨系统互操作。

用 Broker 中介凭证

常见的安全路径会把可复用 Credential 留在 Agent 外：

1. Runtime 使用 Workload Identity 向 Credential Broker 认证；
2. 提交已批准 Operation、目标 Resource、Principal Context 与 Run Identity；
3. Broker 评估当前 Policy 与 Delegation；
4. 签发短期 Audience-bound Token，或由 Broker 自行请求；
5. Resource Server 校验 Token，并执行对象级授权；
6. 系统记录明确结果或 outcome_unknown 状态。

这样可以减少凭证从 Prompt、Shell History、文件、日志、Browser Storage 与 Tool Output 泄漏。Agent 沙箱指南解释其客户端执行边界；远程 MCP OAuth 指南说明 MCP 专属授权契约。

DPoP 等 Sender-constrained Token 可以降低 Token 被盗后的 Replay 风险，但不会让请求的 Operation 自动合法。Proof Key 被盗、Token 过宽或 Resource Server 混淆，仍会造成风险。

校验 Delegated Grant

JWT 签名、Issuer 与 Algorithm 校验应交给维护良好的身份库。密码学验证完成后，应用代码还必须让 Claim 与实际请求匹配。下面的 Go 示例校验一份已通过签名验证的简化 Grant。

package main

import (
	"errors"
	"fmt"
	"slices"
	"time"
)

type Grant struct {
	Subject   string
	Actor     string
	Audience  string
	Tenant    string
	Scopes    []string
	ExpiresAt time.Time
	RunID     string
}

type Request struct {
	Actor    string
	Audience string
	Tenant   string
	Scope    string
	RunID    string
}

func authorize(grant Grant, request Request, now time.Time) error {
	if grant.Subject == "" || grant.Actor == "" || request.Actor != grant.Actor {
		return errors.New("actor mismatch")
	}
	if request.Audience != grant.Audience {
		return errors.New("audience mismatch")
	}
	if request.Tenant != grant.Tenant || request.RunID != grant.RunID {
		return errors.New("context mismatch")
	}
	if !now.Before(grant.ExpiresAt) {
		return errors.New("grant expired")
	}
	if !slices.Contains(grant.Scopes, request.Scope) {
		return errors.New("scope denied")
	}
	return nil
}

func main() {
	now := time.Unix(1_800_000_000, 0)
	grant := Grant{
		Subject: "user-42", Actor: "agent-runner-7",
		Audience: "https://orders.example", Tenant: "tenant-a",
		Scopes: []string{"orders.read"}, ExpiresAt: now.Add(time.Minute),
		RunID: "run-123",
	}
	request := Request{
		Actor: "agent-runner-7", Audience: "https://orders.example",
		Tenant: "tenant-a", Scope: "orders.read", RunID: "run-123",
	}
	fmt.Println(authorize(grant, request, now))
}

预期输出：

<nil>

生产鉴权还要检查 Signature、Issuer、Token Type、Token ID、Proof-of-Possession Key、Clock Skew、Revocation、Object Ownership、Action Arguments、Policy Version、Approval 与 Operation State。只检查 Scope 远远不够。

处理多 Agent 委托

多 Agent 系统增加的是 Delegation Graph，不只是更多模型调用。每次 Handoff 都应：

• 认证接收方 Workload；
• 计算 Parent 权限的显式子集；
• 把 Grant 绑定到单个 Audience、Purpose、Run 与 Expiry；
• 限制 Chain Depth 并阻止 Cycle；
• 记录 Parent Grant 与 Decision ID；
• 禁止转发原始 Token；
• Root Authority 撤销时同步撤销 Descendant；
• Plan 发生实质变化时重新决策。

不要把 Access Token 粘贴进 Agent Message，不要让 Planner 发明 Scope，也不要从“让研究 Agent 使用我全部权限”这种自然语言中推断完整委托。

Approval 与 Consent 必须绑定动作

只有 Reviewer 看到了准确 Operation、Object、Destination、Amount 与后果，人工审批才有意义。应把 Decision 绑定 Canonical Arguments、Policy Version、Actor、Expiry 和一次性 Operation ID。

每隔几秒弹一次审批会造成 Consent Fatigue。低风险、可逆读操作可以按 Policy 自动通过，高影响操作才要求聚焦审查，不支持的动作应直接拒绝。Approval Gate词条解释了单次消费与 TOCTOU 防护。

审计证据与撤销

Audit Event 应能重建调用链，同时不保存可复用 Credential：

• Principal、Agent Definition、Workload、Run、Tool、Resource 与 Operation ID；
• Issuer、Audience、Effective Scope、Policy Version 与 Grant Lineage；
• Approval 或 Autonomous Policy Decision；
• 规范化 Argument Digest；
• Token/Decision Expiry 与 Revocation 状态；
• Dispatch、Downstream Result 与 Reconciliation Outcome。

Token 和敏感参数需要脱敏。保留 Token ID 或 Digest，不保存 Bearer Credential。

Revocation 必须影响未来使用、排队任务、派生委托、Broker Cache 和长运行 Session。因为系统未必每次调用都 Introspect Token，所以 Credential 应保持短生命周期，并提供显式取消与对账路径。

常见失败模式

常见问题

Agent Identity 就是 Service Account 吗？

不一定。Service Account 可以认证 Runtime，但治理通常还需要 Agent Definition、Owner、Policy Version、Run Identity、Delegated Principal 与 Operation。一个宽权限 Service Account 会丢失这些区别。

Agent 可以使用 OAuth Client Credentials 吗？

可以，但只适合不代表人类权限的 Service-owned Operation，不能声称“代表用户”。Audience、Scope、Lifetime 与 Resource Policy 仍需最小化。

什么时候使用 OAuth Token Exchange？

当可信 Authorization Server 能针对下游 Resource 签发新 Token，并保留所需 Delegation 语义时使用。不能把它当成任意 Token 的通用包装器，也不能假设下游一定理解所得 Claim。

Proof of Possession 能解决鉴权吗？

不能。它可以把 Token 使用绑定到 Key 并降低 Replay，但不判断 Key Holder 能否访问特定 Tenant、Object、Amount、Destination 或 Business Operation。

采用 Agent 专属草案前，哪些内容必须稳定？

固定确切 Draft Revision，把每个字段映射到稳定基础标准，提供降级路径，并运行互操作与安全测试。没有 Migration Plan 时，不要把 Draft Claim 名称持久化成不可逆业务数据。

参考资料

• NIST：为什么 Agentic AI 需要强身份基础
• SPIFFE 概览
• RFC 8693：OAuth 2.0 Token Exchange
• RFC 8707：OAuth 2.0 Resource Indicators
• WIMSE Agent Credential Delegation 草案
• Agent Transaction Token 草案