从万能 Key 到零信任委托：重构 AI Agent 身份安全的四层模型

TL;DR 速读

1. Agent ≠ 普通微服务，传统 IAM 无法覆盖“自主决策 + 多跳委托”场景。
2. 企业级 Agent 身份需拆解为四层：人 → 逻辑Agent → 运行时 → 委托令牌。
3. 落地第一步：找出系统中所有共享 API Key 的 Agent，换上独立短时委托凭证。

一个 SRE Agent 拿着包含 admin:* 权限的 API Key 在后台静默运行。更令人后背发凉的是，这个 Key 是不知哪位同事半年前创建的，至今没人清楚它到底能撬动多少资源。

这正是当下不少企业 AI Agent 的身份现状：重要的不是“谁在执行”，而是“哪把钥匙在开门”。

Agent Identity（Agent 身份）绝不等于简单的 API Key。它真正需要回答的是：谁发起、谁决策、谁执行、代表谁、能做什么、做到何时。本文结合最新业界实践与架构调研，带你从架构层面重构 Agent 的身份安全体系。

---

一、传统身份模型，为什么 hold 不住 Agent？

先看开发者最熟悉的微服务调用链：

用户 ───> API Gateway ───> Service A ───> Service B
身份：   User JWT          ServiceAccount   ServiceAccount

每一跳都有明确凭证，审计链路清晰可查。

再看 Agent 的多跳调用链：

用户一句话 ───> Agent 决策 ───> 调用工具 A ───> 调用工具 B ───> 访问数据库
身份：          ???            共享 API Key     共享 API Key     直连 (ServiceAccount)

仅仅三跳，下游就彻底丢失上下文：它们完全不知道这是“谁”的请求。

这暴露了三大核心矛盾：

• 👤 原始身份丢失：用户 JWT 在第一跳就断了，数据库只看到高权限 ServiceAccount。
• 🔑 权限无界膨胀：为满足多样化需求，开发者直接赋予 admin:* 泛授权。
• 📋 审计链路断裂：日志仅显示“Agent 调用了接口”，无法追溯授权人、决策分支与权限边界。

⚠️ 架构本质 Agent 是 “具备自主决策权力的代理中间人”。传统 IAM 没有为“自主决策 + 多跳委托”建模，必须引入新的身份架构。

---

二、Agent Identity 四层模型

在企业级架构中，建议将 Agent 身份拆解为四层，逐层回答安全问题：

层级	核心问题	技术载体	类比
L1: Human	原始授权人是谁？业务意图？	User JWT / OIDC / MFA Step-up	带签名的授权委托书
L2: Agent	什么Agent？准入策略？	Agent Registry / 版本号 / 工具白名单	K8s Deployment 定义
L3: Workload	运行在哪个底层环境？	Pod / SPIFFE ID / Attestation	K8s ServiceAccount + 节点证明
L4: Delegated	代表谁？权限约束？	RFC 8693 Delegation Token	标注有效期与用途的临时凭证

L1: Human Identity（人）

不只是“已登录”，而是 认证强度 + 业务意图绑定 + 明确同意（Consent）。高风险操作必须触发 MFA Step-up 动态二次确认。

L2: Agent Identity（逻辑 Agent）

定义静态属性与治理元数据：

{
  "agent_id": "sales-assistant",
  "version": "2.1.0",
  "publisher": "ai-platform-team",
  "owner": "zhangsan@company.com",       // ← 关键：解决僵尸Agent归属
  "sponsor": "lisi@company.com",         // ← 关键：离职自动Suspend
  "allowed_tools": ["crm-query", "mail-read"],
  "risk_level": "medium",
  "expiry_date": "2026-12-31"
}

L3: Workload Identity（运行时）

结合 Attestation（工作负载证明） 验真，防止恶意容器伪装：

# Workload Attestation 声明示例
workload:
  pod_name: "sales-assistant-7d9f4b8c5-x2v4p"
  image_digest: "sha256:a1b2c3d4e5f6..."  # ← 防止镜像篡改
  namespace: "agent-prod"
  attested_by: "spire-agent"              # ← SPIRE 验真来源

L4: Delegated Identity（委托关系）—— 核心层

保留 subject（用户）+ actor（Agent）+ delegation chain（委托链）。下游既知道“谁在替人干活”，也知道“最终受益人是谁”。

💡 零信任下的有效权限公式

📝 文字兜底：有效权限 = 用户权限 ∩ Agent允许权限 ∩ Workload信任策略 ∩ 工具策略 ∩ 资源策略 ∩ 实时风险/目的限制。任意一层不匹配，PEP 立刻拒绝。

---

三、端到端流程：从“一句话”到“受控调用”

当用户说 “帮我总结今天的客户邮件并草拟回复” 时，标准安全架构下的调用链：

用户: "帮我总结今天的客户邮件并草拟回复"
  │
[ IdP / Gateway ] ─── 验证 OIDC + 记录授权意图
  │
[ Agent Control Plane ]
  ├─ 查 Agent Registry ─── 校验状态与 Allowed Tools
  ├─ 查 PDP ──────────── 校验 User 是否有权授权该 Agent 读邮件
  └─ 签发初始 Delegation Token (sub=user, actor=agent)
  │
[ Agent Runtime ]
  ├─ Workload Attestation ─ 证明容器合法性
  └─ 调用 STS ─────────── 换取邮件工具专用短时 Token
                            (aud=mail-api, scope=read:inbox, TTL=15m)
  │
[ Tool Gateway / PEP ]
  ├─ 校验 Token 签名、Audience、Actor、Delegation Depth
  └─ 参数级策略检查 (只允许 Read，严禁 Delete/Forward)
  │
[ 邮件 API ] ──> 返回数据 ──> Agent 生成摘要 ──> 返回用户

🔐 Token Exchange 实战（RFC 8693）

Agent 代表用户调用下游时，严禁透传原始 JWT，必须进行凭证降级与受众锁定：

POST /token HTTP/1.1
Host: sts.company.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<user_jwt>               # ← 原始用户凭证
&actor_token=<agent_identity_assertion> # ← Agent 身份证明，非透传！
&scope=read:mail:inbox                  # ← 范围缩小：仅限读收件箱
&audience=https://mail-api.internal     # ← 受众锁定：防重放攻击
&requested_token_type=urn:ietf:params:oauth:token-type:jwt

❌ 错误示范：直接把用户 JWT 塞进 Agent 请求头，或给 Agent 配一个长期有效的个人 Refresh Token。

✅ 正确姿势：每次调用都走 Token Exchange，换取 TTL ≤ 15min、aud 锁定的专用令牌。

换取的新 Token 三大安全特性：

1. 范围缩小：仅限 read:mail:inbox，无法发信/删除。
2. 受众锁定：aud 仅对 mail-api.internal 生效。
3. 极短 TTL：15分钟自动失效，缩短凭证暴露窗口。

---

四、主流方案横评与选型建议

方案	分类	一句话评价	适用场景
Entra Agent ID	A类-IAM	支持 Sponsor 治理与条件访问，蓝图完整	微软/Azure 生态
Bedrock AgentCore	A类-IAM	兼容 SigV4 + OAuth，集成 Token Vault	AWS 云原生
Google Agent Identity	A类-IAM	原生集成 SPIFFE，K8s 极其友好	GCP / K8s
SPIFFE / SPIRE	B类-基础设施	Workload 身份事实标准，不处理用户委托	跨云/私有化零信任底座
MCP	C类-协议	工具调用标准接口，依赖外部 IdP	工具与数据源解耦
A2A Protocol	C类-协议	Agent 互联发现，信任依赖外部基础设施	跨组织 Agent 协同
LangChain/Graph	C类-框架	编排框架，本身不提供 IAM 能力	应用层逻辑开发

🛠️ 选型避坑与组合推荐

边界认知：

• 支持 OAuth ≠ 具备 Agent IAM（缺少注册、生命周期、Kill Switch）。
• MCP / A2A 不是 IdP，身份治理必须由外置 IAM 控制面接管。

组合推荐：

• 企业级/私有云：SPIFFE/SPIRE + Keycloak/Vault (STS) + API Gateway (PEP) ← 开源可落地组合
• 公有云原生：直接收敛至 Bedrock AgentCore 或 Entra Agent ID。

---

五、Agent 身份安全十大反模式（避坑清单）

#	❌ 反模式	⚠️ 风险	✅ 正确做法
1	万能 Key 跑天下	不敢轮换，泄露即全量失陷	每个 Agent 环境独立 Workload Identity
2	长效用户 Token 后台跑	员工离职后 Agent 仍持有效凭证	自主任务用 Agent 身份，委托用短时 Token
3	上帝 Agent 过度授权	单 Agent 拥有读写发全权限	按业务拆分 Agent，落实 PoLP
4	靠 Prompt 做安全防御	“请不要删库” 可被越狱绕过	安全推给 PEP，网关层硬性拦截
5	Token 缺 Audience	凭证被偷梁换柱攻击其他系统	签发时绑定明确 aud
6	盲信 MCP 工具描述	恶意 Server 注入危险操作	工具描述/入参/返回值准入校验+沙箱
7	垃圾审计日志	出事无法追责到人/决策/权限	日志含 User+Actor+Workload+策略版本
8	迷信短 TTL	15分钟内仍可完成攻击	短TTL + 实时撤销(CRL) + 密钥快轮换
9	僵尸 Agent 游离	离职员工 Agent 静默运行	联动 HR/IAM，离职自动 Suspend+交接
10	A2A 当内网 RPC	内部 Agent 互信导致横向移动	跨 Agent 零信任：验身份+签名+委托深度

---

六、总结

回到开头场景：如果那个 SRE Agent 有独立 Identity、明确 Owner、受限短时 Token 和全链路审计 —— 超权调用会在微秒级被拒，SIEM 立即告警，安全人员可一键 Kill Switch 封禁。

Agent 时代的安全逻辑变了：不是“信任但验证”，而是“实时验证、层层穿透、随时断电”。

🎯 如果你今天只想做一件事： 找出系统中正在使用共享 API Key 的某一个 Agent，给它换上独立身份凭证，并明确记录 Owner 是谁。这就是迈向 Agent Identity 治理的第一步。

---

参考资料

• OWASP Top 10 for Agentic Applications 2026 (预发布版)
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8707: Resource Indicators for OAuth 2.0
• RFC 9396: Rich Authorization Requests (RAR)
• RFC 9449: OAuth 2.0 DPoP
• SPIFFE Standards & Architecture
• Model Context Protocol Specification