AI Agent Identity / Delegated Authorization 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_AGENT_IDENTITY_DELEGATED_AUTHORIZATION_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

Agent 不能靠共享 admin key 在企业系统里行动。生产级 Agent 必须有自己的身份、任务级授权、可撤销 session、purpose-bound scope，以及能贯穿下游系统的 actor chain evidence。

Agent identity architecture 要回答六个问题：谁在行动、代表谁行动、基于什么授权、为了什么目的、权限持续多久、事后如何证明。OAuth/OIDC、token exchange、scope、consent、step-up approval 和 audit claims 在 Agent 场景中不是安全术语堆叠，而是防止“AI 变成不可追责系统用户”的架构基础。

---

1. 问题定义：共享账号会摧毁可追责性

传统应用通常是用户点击按钮，系统记录 user_id。Agentic AI 的调用链更长：

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

如果所有调用都落在一个 service account 或 admin key 上，事故复盘会失去关键事实：

Agent 身份架构的目标不是让 AI“登录系统”，而是让每一次行动都具备最小权限、目的约束、可撤销性和可审计性。

---

2. 架构模型：Human、Agent、Tool 三类身份必须分离

2.1 Identity taxonomy

Agent 系统至少涉及多类主体。它们要能在 trace 中关联，但不能混成一个账号。

核心分离原则：

human identity != agent identity != tool identity

Human identity 证明授权来源，agent identity 证明执行者和配置版本，tool identity 证明技术调用主体。三者共同形成 actor chain。

2.2 Delegated authorization reference flow

User authenticates
  -> entitlement / consent / purpose check
  -> workflow creates agent run
  -> token exchange issues delegated token
  -> tool gateway validates scope, tenant, purpose, risk tier
  -> downstream service records actor chain claims
  -> evidence log stores policy decision and action result

这个流程的关键是：Agent 不拿长期系统权限，而是在具体 workflow run 中获得短期、任务化、目的绑定的 delegated token。授权不是“这个 Agent 永远能调用 CRM”，而是“这个 run 在 complaint_triage purpose 下，可以读取指定 case 并创建内部 task”。

2.3 Scope 作为业务动作语言

低质量 scope 把系统权限暴露给 Agent：

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 设计要同时表达读写分离、可逆性、客户可见性和金融影响：

---

3. 关键机制与生命周期

3.1 Authorization lifecycle

Agent 授权应按一次业务执行的生命周期设计，而不是按静态系统账号设计。

3.2 Consent、purpose 与 step-up

Agent 授权不应是一次性同意所有能力。授权强度应随任务影响提升。

Consent UX 不应把权限藏在泛化提示里。有效的授权表达应说明 Agent 能读什么、能做什么、不能做什么，以及哪些动作仍需人类批准。

3.3 Tool gateway 作为授权执行点

Tool gateway 是 Agent 授权架构的实际执行层。它不能只做 API proxy，而要在每次调用时检查：

---

4. 证据与控制

4.1 Audit claims

每一次 tool call 至少应能复盘以下 claims：

这些 claims 要进入下游业务系统和 evidence log，而不是只留在 AI 平台内部。否则客户、审计、合规或事故调查看到的仍然只是一个技术账号。

4.2 Failure modes and controls

---

5. 金融零售与 AI 产品场景

5.1 CRM update agent

CRM 场景中，Agent 可以读取客户联系历史、生成 case summary、创建内部 task、写入 draft note。它不应修改客户核心身份信息、覆盖人工审核结论、关闭投诉或直接承诺补偿。

架构重点是把 crm.case.read、crm.case.note.create、crm.task.create 等动作拆成独立 scope，并让每次写入都带上 human actor、agent actor、run_id 和 policy decision。

5.2 Payment dispute assistant

Payment dispute assistant 可以读取交易和 dispute case、草拟证据请求、推荐下一步处理。自动拒绝 dispute、自动退款、发送最终客户决定属于高风险动作，需要 step-up approval 或人工工作流。

这里的授权难点是同一工具域内存在风险差异：读取 dispute 资料、草拟客户沟通、执行退款、关闭案件的影响完全不同，不能用一个 payments.write 覆盖。

5.3 Loan servicing agent

Loan servicing agent 可以解释政策、检查缺失材料、生成内部 checklist、提交人工复核请求。它不应自动改变 repayment plan、批准 hardship relief、触发 adverse action 或改变 risk grade。

贷款场景要求 delegated authorization 与 fair lending、adverse action、客户通知和审批证据联动。Agent 身份不仅是安全控制，也是证明业务责任链的基础。

5.4 Wealth and advice workflow

财富或投顾辅助场景中，Agent 可以整理 meeting notes、准备资料、生成 advisor review items。涉及个人化建议、客户适当性、交易执行、组合调整的动作必须进入更高授权层级。

这个场景的身份边界要能区分：客户授权、顾问授权、机构政策、Agent 推荐和最终执行之间的责任关系。

---

6. 反模式

---

7. 最终心智模型

Agent identity 的核心不是“给 AI 一个账号”，而是把每次行动的授权链变成可执行、可撤销、可证明的系统事实。Human user 提供授权来源，Agent instance 提供执行上下文，workflow run 提供业务目的，tool gateway 执行 scope 与 policy，下游系统保存 actor chain，evidence plane 支撑审计和事故复盘。

可以用一个检查链来判断架构是否成熟：

Who acted?
On whose behalf?
For what purpose?
With which scope?
Approved by whom?
Recorded where?
Revocable how?

---

SOTA 检查 (2026-07-01)

• MCP 授权已把本篇模式写进协议标准：MCP 规范 2025-11-25 版对 remote server 强制 OAuth 2.1 + PKCE，并新增 Client ID Metadata Documents (CIMD) 客户端注册、增量 scope 同意的 step-up authorization、以及企业管理授权扩展 Cross App Access (XAA)（让 IT 通过 IdP 管控 agent 接入）（2025-11）。下一个稳定版 RC 已于 2026-05-21 锁定、定档 2026-07-28 发布（stateless core / Tasks 降为扩展）——逐项 diff 见库内笔记 docs/aipa/day44-mcp-final-spec.md（2026）。
• IETF 正在把本篇 §2.2 的 delegated token 流程标准化：draft-oauth-ai-agents-on-behalf-of-user（-01 发布 2025-05，-02 发布 2025-08）在授权请求中引入 requested_actor、token 请求中引入 actor_token，签发的 token 用 sub 标识委托用户、act 标识执行 agent——与本篇 "human identity != agent identity"、actor chain claims 的主张完全一致；另有 draft-klrc-aiagent-auth（已至 -02）等并行草案。注意这些都是在研 Internet-Draft，尚未成为 RFC，落地时以 RFC 8693 token exchange 为基座自建仍是现实路径。
• 本篇基础锚点全部仍现役：RFC 8693 Token Exchange（2020-01）仍是委托授权的主流实现基座；RFC 9700（2025-01）是当前 OAuth 安全 BCP。OAuth 2.1 本身仍是 IETF 工作组草案（未定稿），但已被 MCP 2025-11-25 等下游规范事实性采用（强制 PKCE、废弃 implicit flow）。
• 商业 IdP 已产品化 agent 身份：Auth0 for AI Agents 等厂商在 2025-2026 推出 agent 专用授权产品线，「agent 作为一等非人类身份（OAuth client）+ 用户级委托主体（OIDC）」的双层身份模型成为行业共识；WIMSE（Workload Identity in Multi-System Environments）架构被引用为 agent workload 身份的扩展基础。
• 不随版本过时的框架性结论：本篇的六问检查链（谁行动/代表谁/什么授权/什么目的/持续多久/如何证明）、human ≠ agent ≠ tool 三身份分离、purpose-bound 短期 token、tool gateway 作为策略执行点、actor chain evidence 贯穿下游——恰好是 2025-11 MCP 授权更新（step-up、XAA）与上述 IETF 草案（act claim 委托链）在标准层面逐条补齐的能力。本篇结论被后续标准强化而非替代，仅需在实现层跟进具体 spec 版本。