AI Agent Identity / Delegated Authorization 解读

面向对象: AI Product Architect / Platform PM / Security Architect / Senior BA / Solutions Architect。 核心问题: Agent 不能靠共享 admin key 在系统里行动。生产级 Agent 必须有可追责 identity、可限制 delegated authorization、可撤销 session、可审计 claims。 学习目标: 把 OAuth/OIDC、token exchange、scope、consent、service account、tool invocation、step-up approval 和 audit claims 转成 AI agent identity architecture。

---

Source Anchors

一句话:

Agent identity architecture answers: who is acting, on whose behalf, with what authority, for what purpose, for how long, and with what evidence.

---

1. 为什么 Agent 需要身份架构

传统应用里, 用户点击按钮, 系统记录 user_id。Agentic AI 里, 事情变复杂:

human user
  -> agent instance
  -> workflow run
  -> tool gateway
  -> downstream system

如果所有调用都用一个 service account, 事故复盘会问不清:

• 是哪个用户触发的。
• 是哪个 agent 版本执行的。
• 是哪个 workflow run 做的。
• 它代表用户还是代表组织。
• 它是否有权调用这个工具。
• 它是否越过了 consent、tenant、purpose、risk tier。

所以 identity 不是安全团队的边角问题, 而是 AI 产品边界。

---

2. Identity Taxonomy

关键点:

human identity != agent identity != tool identity

三者必须能在 trace 中关联, 但不能混成一个共享账号。

---

3. Delegated Authorization Flow

典型 agent 授权链:

User authenticates
  -> user grants task consent / has enterprise entitlement
  -> workflow creates agent run
  -> agent receives purpose-bound delegated token
  -> tool gateway validates scope, policy, tenant, risk tier
  -> downstream service records user + agent + run claims
  -> evidence log stores decision and action

设计重点:

• token 不应长期有效。
• scope 应该任务化, 不是系统级。
• 写入型工具和只读工具分离。
• 高风险动作触发 step-up approval。
• 撤销应能停止 agent run 和 tool token。
• downstream system 要能记录 on-behalf-of claims。

---

4. Scope 设计

低质量 scope:

crm.full_access
payments.admin
loan.write

高质量 scope:

crm.case.read
crm.case.note.create
crm.task.create
payments.dispute.read
payments.dispute.draft_response
loan.policy.read
loan.exception.submit_for_review

Scope 要回答:

---

5. Consent / Purpose / Step-up

Agent 授权不是一次性同意所有。

Consent UX 要避免让用户看不懂:

This agent can read customer complaint history and draft a response.
It cannot send the response, waive fees, or close the complaint without your approval.

---

6. 金融零售案例

6.1 CRM update agent

允许:

• 读客户联系历史。
• 生成 case summary。
• 创建内部 task。
• 写入 draft note。

禁止:

• 修改客户个人核心信息。
• 关闭投诉。
• 覆盖人工审核结论。

6.2 Payment dispute assistant

允许:

• 读取交易和 dispute case。
• 草拟证据请求。
• 推荐下一步。

高风险:

• 自动拒绝 dispute。
• 自动退款。
• 通知客户最终决定。

6.3 Loan servicing agent

允许:

• 解释政策。
• 检查缺失材料。
• 生成内部 checklist。

禁止:

• 自动改变 repayment plan。
• 自动批准 hardship relief。
• 自动触发 adverse action。

---

7. Failure Modes

---

8. Agent Identity Card

# Agent Identity Card

Agent name:
Agent id:
Owner:
Business purpose:
Risk tier:
Allowed users/roles:
Allowed tenants:
Allowed tools:
Read scopes:
Write scopes:
Prohibited scopes:
Token TTL:
Step-up triggers:
Revocation mechanism:
Audit claims:
Downstream systems:
Review cadence:

---

9. Audit Claims

每一次 tool call 至少应能回答:

---

10. 面试表达

30 秒版本:

我不会让 AI agent 用共享 admin key 调系统。Agent 必须有自己的身份, 并且通过 delegated authorization 代表用户或组织在明确 purpose、scope、tenant、TTL 和风险等级内行动。每次 tool call 都要记录 human actor、agent actor、workflow run、scope、policy decision 和 evidence id。

2 分钟版本:

我会把 identity 设计成三层: human user、agent instance、tool/service client。用户或组织授权一个具体任务, workflow 创建 agent run, agent 通过 token exchange 获得 purpose-bound delegated token, tool gateway 检查 scope、tenant、risk tier 和 policy。 Scope 设计会细到业务动作, 例如 crm.case.note.create, 而不是 crm.full_access。读写分离, 客户可见和金融影响动作触发 step-up approval。Token 要短期有效, 可撤销, 并且 downstream system 必须记录 on-behalf-of claims。 这样做的价值是: 出现事故时能回答谁触发、哪个 agent、代表谁、用什么权限、为什么被允许、谁审批、产生了什么影响。

---

11. Portfolio Exercise

为一个 payment dispute assistant 设计:

1. agent identity card。
2. delegated authorization matrix。
3. scope catalog。
4. step-up triggers。
5. audit claims spec。
6. revocation runbook。

最终输出一张图:

human -> agent run -> token exchange -> tool gateway -> downstream service -> evidence log