AI Agent Identity / Delegated Authorization Playbook

本 playbook 面向 CBAP+、金融零售 AI Product Manager、AI Product Architect 与 Solutions Architect。重点不是复述 OAuth 术语，而是把 Agentic AI 在生产环境中的身份、授权、委托、同意、审计、撤销与高风险操作审批设计成可落地的业务与技术控制体系。你需要能向业务负责人解释为什么 AI Agent 不能共用管理员密钥，也需要能与 IAM、平台、安全、合规、模型团队一起定义 token claim、scope catalog、tool allowlist、step-up approval、audit evidence 与 incident runbook。

Source Anchors

以下官方资料作为概念与架构锚点，用于约束术语、协议边界与风险治理语言：

Core Mental Model

生产级 AI Agent 的核心心智模型是：Agent 需要 accountable identity 和 bounded delegated authority，而不是共享 admin keys。

传统系统常把自动化脚本、后台任务、RPA bot、集成账号放进一个大权限服务账号里。Agentic AI 不能沿用这种做法，因为 AI Agent 具有更强的不确定性：它会理解自然语言、选择工具、组合步骤、调用外部系统、根据中间结果调整路径，并可能在用户没有精确说明的情况下推断下一步。对于金融零售，这意味着它可能读取客户 PII、更新 CRM、发起 dispute、调整贷款还款安排、触发 AML case review、联系客户或生成监管证据。只要 Agent 可以行动，就必须能回答五个问题：

1. Who is acting: 是哪个 human user、agent instance、workflow run、tool client 或 vendor agent 在行动？
2. On whose behalf: 它代表哪个用户、客户、角色、团队或业务流程？
3. With what authority: 它获得了哪些 consented scopes、policy grants、purpose-bound permissions？
4. Under which context: 当前 tenant、channel、case、customer、risk tier、session、device、approval state 是什么？
5. How can we prove and stop it: 如何审计、追溯、撤销、冻结、降权、强制 step-up 或 break-glass？

因此，Agent 身份设计不是单点登录配置，而是一个 control plane。它把人、Agent、工作流、工具、服务账号、供应商、审批人与审计系统连接起来，用最小权限、上下文授权、短生命周期 token、可撤销 consent、不可抵赖日志和高风险动作审批来约束 Agent 的行动边界。

Identity Taxonomy

1. Human User

Human user 是资源所有者、业务责任人或操作发起人。包括客户、客服代表、贷款专员、AML analyst、branch manager、运营主管与系统管理员。对于 Agent 授权，human user 不只是登录主体，还承担授权意图来源。

关键属性：

• sub: 用户稳定标识，不使用 email 作为主键。
• tenant_id: 所属金融机构、业务线或子公司。
• role / group: RBAC 初始边界，例如 csr, loan_officer, aml_analyst。
• entitlements: 细粒度权限，例如可处理的产品、地区、客户风险等级、交易金额上限。
• auth_context: MFA、device trust、session age、assurance level。
• employment_status: active、suspended、terminated，对 SCIM deprovisioning 特别关键。

设计要点：Agent 代表员工时不能自动继承员工全部权限，必须按任务、目的、客户范围、工具范围下发子集权限。客户授权 Agent 时，consent UX 要明确数据范围、行动范围、持续时间与撤销入口。

2. Agent Instance

Agent instance 是可部署、可配置、可审计的软件主体，例如 crm-update-agent-prod-v3、payment-dispute-assistant-us-retail。它不是一次运行，而是一个可被治理的产品或能力单元。

关键属性：

• agent_id: 稳定唯一标识。
• agent_version: 模型、prompt、tool manifest、policy bundle 的版本。
• owner: 产品负责人、技术负责人、业务 sponsor、risk owner。
• risk_tier: low、moderate、high、critical，影响审批与监控。
• allowed_tools: 可调用工具集合。
• allowed_scopes: 可申请或交换的 scope 集合。
• deployment_env: dev、test、staging、prod。

设计要点：Agent instance 要像 application client 一样注册进 IAM / authorization server，但它还需要 AI-specific metadata，例如 eval status、model class、tool policy、human oversight mode、allowed autonomy level。

3. Workflow Run

Workflow run 是一次具体任务执行，例如某客服要求 Agent 为客户 A 更新地址，或 AML analyst 让 Agent 汇总 case evidence。它是审计和事故调查的最小业务线索。

关键属性：

• run_id: 全局唯一执行 ID。
• parent_run_id: 多 Agent 编排或重试时的关联 ID。
• case_id / customer_id / account_id: 业务对象范围。
• initiator_sub: 发起用户。
• agent_id 与 agent_version: 执行主体。
• purpose: 明确目的，例如 customer_address_update、dispute_intake。
• approval_state: not_required、pending、approved、denied、expired。
• risk_score: 由 policy engine、fraud model 或业务规则计算。

设计要点：生产 Agent 的每次工具调用都应该绑定 run_id，否则后续无法解释为什么某个客户记录被修改、哪个提示触发了修改、哪个 token 允许该操作。

4. Tool / Service Account

Tool 或 service account 是 Agent 调用 CRM、payment system、loan servicing、case management、document store、message gateway、core banking adapter 的技术身份。它不等于 Agent，也不等于用户。

关键属性：

• client_id: 工具客户端或 adapter 身份。
• service_principal_id: 服务主体。
• tool_name 与 tool_version: 工具契约版本。
• allowed_operations: read、search、create、update、submit、approve、notify。
• network_boundary: VPC、private link、API gateway、mTLS trust boundary。
• credential_rotation_policy: 密钥和证书轮换规则。

设计要点：Service account 应该是工具边界，不是万能账号。Agent 调用工具时，工具必须同时验证 service identity、delegated user / agent claims、scope、business object boundary 与 policy decision。

5. Vendor Agent

Vendor agent 是第三方 AI 平台、SaaS copilots、outsourced servicing bot 或嵌入式 agent。它可能运行在供应商环境中，也可能通过企业网关调用内部 API。

关键属性：

• vendor_id: 供应商标识。
• contract_scope: 合同授权范围。
• data_residency: 数据驻留与跨境限制。
• subprocessor_chain: 分包商链路。
• model_training_use: 是否允许使用客户数据训练。
• exit_controls: token revoke、data deletion、audit export、key destruction。

设计要点：Vendor agent 不能因为是“可信供应商”就拿到长期广域权限。它应通过 broker、gateway、token exchange 或 policy enforcement point 获得短期、purpose-bound、tenant-bound、audit-rich token。

6. Supervisor

Supervisor 是批准、驳回、覆盖或接管 Agent 行动的人或系统。可以是人工主管、双人复核机制、policy engine、risk scoring service 或 automated control plane。

关键属性：

• supervisor_sub: 审批主体。
• approval_level: peer review、manager approval、compliance approval、dual control。
• approval_reason: 风险解释与业务理由。
• approval_expiry: 审批有效期。
• override_policy: 是否允许 override，何种情况下允许。

设计要点：Supervisor 不是简单弹窗按钮，而是高风险行动的授权证据源。审批记录必须和 token、run、tool invocation、业务对象、最终结果关联。

Delegated Authorization Flow Patterns

Pattern A: On-Behalf-Of for Internal Employee Agent

适用场景：客服代表登录内部系统，让 CRM update agent 帮助整理客户对话、建议字段更新、提交地址变更。

基本流程：

1. Employee 通过 enterprise IdP 登录，获得 human session 与 OIDC claims。
2. Agent orchestration layer 创建 run_id，记录 purpose、case、customer、agent version。
3. Authorization server 根据用户权限、agent registration、tool policy 和业务上下文签发 delegated access token。
4. Agent 调用 CRM tool，携带 token、run_id、agent_id、sub、act 或等价 actor claim。
5. CRM tool 验证 token audience、scope、tenant、customer boundary、session assurance 与 risk policy。
6. 读操作可以自动执行；写操作根据风险进入 step-up approval。

设计重点：

• Delegation 不是 impersonation。日志要清楚显示“Agent X on behalf of User Y”，而不是把所有行为伪装成 User Y。
• Token audience 必须绑定 CRM API，不允许拿同一个 token 调 payment 或 loan system。
• purpose 要进入 token claim 或 policy context，防止同一授权被挪用到其他任务。

Pattern B: OAuth 2.0 Token Exchange

适用场景：Agent 需要把 human user 的 token 转成面向具体工具的短期 token，或把 vendor agent 的外部 identity 映射成内部受控身份。

基本流程：

1. Subject token 表示原始主体，例如 human user session token。
2. Actor token 表示 Agent 或 calling service。
3. Token exchange endpoint 验证 subject、actor、requested audience、requested scope、tenant、risk context。
4. 返回新 token，范围更窄、期限更短、audience 更具体，并包含 delegation chain。
5. Downstream tool 只接受 exchange 后的 tool-specific token。

设计重点：

• Token exchange 是收窄权限的机制，不应该成为权限放大的后门。
• 每次 exchange 都应记录 requested scope、granted scope、denied scope、policy reason。
• 对高风险工具，exchange 本身可以要求 step-up 或 supervisor approval。

Pattern C: Consented Scopes for Customer-Facing Agent

适用场景：移动银行 App 中的 AI assistant 帮客户查询交易、解释费用、准备 dispute，但不能未经明确同意提交争议。

基本流程：

1. Customer 登录 App，Agent 请求特定目的的授权。
2. Consent UX 显示数据范围、行动范围、持续时间、撤销路径、是否影响账户。
3. Authorization server 下发 consented scope，例如 transactions.read:90d、dispute.draft:create。
4. Agent 可读取交易与准备草稿；提交 dispute 需要额外确认或 step-up。
5. Customer 可在隐私与授权中心撤销 consent，已签发 token 通过短 TTL、introspection、revocation 或 session binding 失效。

设计重点：

• Scope 命名要让产品、法务、安全与客户体验团队都能理解。
• Consent 不应一次性覆盖所有未来 Agent 能力。新增高敏能力要重新 consent。
• Consent record 是监管和客户争议处理证据。

Pattern D: Purpose-Bound Tokens

适用场景：Agent 为某个客户投诉 case 汇总证据，只能读取该 case 相关记录，不能横向搜索同名客户或批量导出。

基本流程：

1. Workflow run 绑定 case_id、customer_id、purpose 与 allowed operations。
2. Policy engine 根据 purpose 输出 token constraints。
3. Token 包含 purpose, case_id, customer_id_hash, max_records, data_classification, expiry。
4. Tool 在执行查询时同时验证 token claim 与请求参数。
5. 超出目的的请求被拒绝并记录 policy violation。

设计重点：

• Purpose-bound token 必须由工具强制执行，不能只靠 Agent prompt 自律。
• 对 PII、PCI、loan、AML 数据，purpose 与 data minimization 要进入架构决策记录。
• Token 中不必放明文敏感标识，可放 hash、reference 或 policy handle。

Pattern E: Step-Up Approval

适用场景：Agent 要执行高影响动作，例如提交 payment dispute、修改还款计划、冻结账户、发送负面信用报告相关通知。

基本流程：

1. Agent 生成 action proposal，包含业务对象、预期影响、证据、风险解释。
2. Policy engine 判断是否需要 MFA、客户确认、主管审批、双人复核或合规审批。
3. Human supervisor 在可审计界面批准或驳回。
4. Approval service 签发短期 approval token 或给 workflow run 写入 approved state。
5. Agent 使用 approval-bound token 调用工具完成动作。
6. 工具记录 approval reference、approver、expiry、action hash 与执行结果。

设计重点：

• Step-up 不只是“再登录一次”。它要证明批准者理解具体动作与影响。
• Approval 应绑定 action hash，防止 Agent 在获批后修改参数。
• 审批有效期要短，且仅适用于同一 run、同一 customer、同一 operation。

Pattern F: Break-Glass

适用场景：生产事故、客户资金风险、欺诈攻击、监管紧急请求，需要临时提升权限处理。

基本流程：

1. Authorized incident commander 发起 break-glass request。
2. 系统要求强 MFA、理由、ticket、时间窗口、审批人。
3. 签发极短期、高审计等级 token，并启用实时监控。
4. 所有 tool invocation 进入 enhanced logging，必要时触发 security watch。
5. 到期自动撤销，并生成 post-incident review evidence。

设计重点：

• Break-glass 是受控例外，不是备用管理员账号。
• AI Agent 默认不应自主触发 break-glass；它最多建议人工触发。
• Break-glass 后必须复盘权限是否被滥用、数据是否外泄、控制是否需要收紧。

Product / Architecture Decisions

Scope Granularity

Scope 要表达能力边界，而不是复制内部数据库权限。太粗会造成 privilege creep，太细会让产品无法维护。推荐三层：

• Domain scope: crm.customer.read, loan.account.read, payment.dispute.write
• Operation scope: read, search, draft, submit, approve, notify, export
• Constraint scope: own_case, assigned_branch, amount_lte_500, last_90_days, case_bound

示例：

Session Duration

Agent session 不应照搬 human session。建议区分：

• Human login session: 根据渠道与风险设置，例如内部系统 8 小时、移动银行较短或连续认证。
• Agent workflow token: 分钟级，绑定 run_id 和 purpose。
• Tool access token: 更短，绑定 audience 和 operation。
• Approval token: 极短，通常只允许一次提交或有限重试。
• Refresh token: 对 Agent 默认禁用或强约束，除非是低风险后台流程并有强 rotation 与 revocation。

架构原则：越靠近写操作、资金影响、监管影响、PII 导出，token 越短、上下文越强、审批越明确。

Revocation

撤销要覆盖四类对象：

• User consent revocation: 客户撤销 Agent 可访问某类数据。
• Employee access revocation: 员工离职、岗位变更、账号冻结。
• Agent capability revocation: 某 Agent 版本存在风险，暂停其工具权限。
• Workflow run revocation: 某次执行被发现异常，立即停止后续调用。

技术策略：

• 短 TTL 降低撤销延迟。
• Token introspection 或 policy check 支持接近实时撤销。
• SCIM deprovisioning 触发用户和群组权限变更。
• API gateway / policy enforcement point 支持 deny list、agent quarantine、tenant freeze。
• Revocation event 写入 SIEM、case management 与 audit evidence store。

Tenant Boundary

金融零售常有多品牌、多地区、多法人、多业务线。Agent 必须把 tenant 作为硬边界：

• Token 必须包含 tenant_id 或等价组织边界。
• Tool 查询必须以 tenant boundary 自动过滤，不能由 Agent 拼接条件。
• Vector store、memory、prompt cache、tool response cache 要 tenant-isolated。
• Vendor agent 调用内部 API 时必须通过 tenant-aware gateway。
• Cross-tenant analytics 需要脱敏、聚合和单独授权。

检验问题：如果 Agent 收到“帮我比较两个客户”的提示，它是否可能跨分行、跨法人、跨客户权限读取数据？如果可能，说明 tenant boundary 没有被底层工具强制执行。

Tool Allowlist

Agent 不能自由发现所有 API。工具授权应从 product risk tier 出发：

• Approved tools: 已通过安全、合规、数据、可观测性评审。
• Allowed operation set: 每个 Agent 只能调用明确操作。
• Parameter policy: 对金额、客户范围、记录数量、日期范围设限。
• Tool contract: 输入输出 schema、error codes、data classification、idempotency。
• Runtime enforcement: gateway、policy engine、mTLS、signed tool manifest。

一个成熟 Agent 平台应有 tool registry，但 registry 不是目录页，而是授权控制面。新增工具应触发 threat modeling、data classification、scope mapping、logging requirement 与 rollback plan。

Write / Read Separation

读与写必须分离，草稿与提交也要分离：

• Read: 允许在明确 case / customer / purpose 下自动执行。
• Draft: Agent 可生成建议、表单、case note、dispute packet，但不改变核心系统状态。
• Submit: 改变业务状态，需要 human confirmation、approval token 或 policy allow。
• Approve: 释放资金、调整贷款、关闭 AML case 等动作应保留给授权人员或 dual control。
• Notify: 对客户发送通知要考虑合规话术、可解释性与记录保存。

这种分离让产品体验更顺滑：Agent 可以提高准备和分析效率，但关键状态变更仍有可验证的人类责任链。

Audit Claims

审计 claim 不是越多越好，而是要能重建责任链和授权链。推荐最低集合：

日志中不要存完整 access token，不要把敏感 claim 明文扩散到低保护日志。需要在 audit evidence store 里保存可验证摘要、签名、hash 或受控引用。

Financial Retail Cases

Case 1: CRM Update Agent

业务目标：客服通话后，Agent 自动总结客户意图、更新联系方式草稿、补全 case note，降低客服后处理时间。

身份与授权设计：

• Human user: 已登录客服，具备该客户 case 权限。
• Agent instance: crm-update-agent-prod，只允许 CRM read、case note draft、contact update proposal。
• Workflow run: 绑定 case_id、customer_id、call transcript reference。
• Tool account: CRM adapter，不允许直接使用管理员账号。
• Scope: crm.customer.read.assigned_case, crm.case_note.draft.create, crm.contact.update.pending_approval。
• Step-up: 如果要写入电话号码、地址、email，需要客服确认；如果涉及敏感客户或高风险标记，需要主管审批。
• Audit: 保存原始输入引用、Agent 建议、客服修改、最终提交差异。

关键控制：

• Agent 不能搜索未分配客户。
• Agent 不能自动覆盖 KYC 地址，除非符合业务规则并通过确认。
• CRM tool 必须验证 case assignment，而不是相信 Agent 提示。

Case 2: Payment Dispute Assistant

业务目标：客户在移动银行中让 AI assistant 解释交易、识别可争议交易、准备 dispute claim。

身份与授权设计：

• Human user: 客户本人，强认证登录。
• Agent instance: payment-dispute-assistant-mobile。
• Workflow run: 绑定交易 ID、账户 ID、dispute reason。
• Scope: transactions.read.last_90_days, payments.dispute.draft.create, payments.dispute.submit.customer_confirmed。
• Consent: UX 明确“读取最近 90 天交易并准备争议材料”；提交前单独确认。
• Step-up: 提交 dispute 前要求 biometric / MFA 或 transaction confirmation。
• Audit: 记录客户同意、Agent 推荐理由、客户确认、提交 payload hash。

关键控制：

• Agent 可以解释费用，但不能承诺退款。
• Agent 可以生成 dispute 草稿，但不能替客户确认事实陈述。
• 对超过金额阈值、重复 dispute、高欺诈风险客户触发人工 review。

Case 3: Loan Servicing Agent

业务目标：帮助贷款专员分析客户还款困难，生成可选还款安排建议，并准备客户沟通材料。

身份与授权设计：

• Human user: 贷款专员或 servicing specialist。
• Agent instance: loan-servicing-agent-prod。
• Workflow run: 绑定 loan account、hardship case、policy rule version。
• Scope: loan.account.read.assigned_case, loan.payment_plan.simulate, loan.customer_message.draft。
• Restricted write: 不允许 Agent 自动修改还款计划；需要审批后由 loan servicing system 执行。
• Step-up: 任何还款计划变更、费用减免、延期安排需要主管或 policy engine approval。
• Audit: 保存使用的 policy version、计算输入、方案选项、人工选择与客户通知。

关键控制：

• Agent 建议必须引用当前政策，避免幻觉式承诺。
• 不同州、不同产品、不同监管要求进入 policy context。
• 对公平借贷和 UDAAP 风险，保留 explainability evidence。

Case 4: AML Workflow Assistant

业务目标：AML analyst 使用 Agent 汇总交易模式、整理 SAR supporting evidence、生成调查摘要。

身份与授权设计：

• Human user: AML analyst，具备 case assignment。
• Agent instance: aml-workflow-assistant-prod，高风险 tier。
• Workflow run: 绑定 AML case ID、subject customer、alert IDs。
• Scope: aml.case.read.assigned, transactions.read.case_bound, aml.evidence.summarize, aml.case_note.draft。
• Write separation: Agent 只能草拟 case note，不能关闭 alert，不能提交 SAR。
• Step-up: case disposition、SAR filing、law enforcement response 必须人工审批。
• Audit: 记录 evidence source、query parameters、summary generation、analyst edits。

关键控制：

• 严格禁止跨 case 批量检索，除非有明确定义的 network analysis scope。
• Vendor LLM 不得接收未脱敏 SAR 敏感内容，除非合同、数据边界和监管要求允许。
• 所有输出都要标记为 analyst draft，不能替代合规判断。

Artifacts / Templates

Agent Identity Card

Delegated Authorization Matrix

使用方法：每个 Agent 上线前，把所有工具调用填入矩阵。任何找不到 actor、behalf-of、scope、context constraints、approval 的调用都不能进入生产。

Scope Catalog

Scope catalog 应由 IAM、API owner、product、risk 与 compliance 共管。推荐字段：

Scope 命名示例：

• crm.case_note.draft.create
• crm.contact.update.pending_approval
• payments.dispute.submit.customer_confirmed
• loan.payment_plan.change.supervisor_approved
• aml.case.close.dual_control
• customer.document.export.regulated_approval

Consent UX Checklist

面向客户或员工的 consent / approval 体验必须能让人理解实际影响：

• 是否说明 Agent 将访问哪些数据类别？
• 是否说明 Agent 能做什么和不能做什么？
• 是否说明授权持续时间？
• 是否显示具体对象，例如账户、交易、case、客户记录？
• 是否区分 read、draft、submit、approve？
• 是否说明撤销入口和撤销后的影响？
• 是否在高风险动作前再次展示 action summary？
• 是否避免把多个不相关授权捆绑成一个“同意全部”？
• 是否保留 consent version、text version、locale、timestamp、channel？
• 是否支持无障碍、移动端可读性和非英语客户场景？

产品原则：Consent UX 不是法律免责文本，而是授权意图采集界面。用户或员工必须能看懂 Agent 下一步会怎样影响数据、账户、客户沟通或业务状态。

Token / Claim Logging Spec

日志目标是证明“谁在什么授权下对什么对象做了什么”，同时避免泄露 token 和敏感数据。

必记字段：

禁止或限制：

• 不记录完整 access token、refresh token、API key。
• 不把完整 PII 写入通用应用日志。
• 不把 prompt、tool response 和客户数据混放在低保护 observability 平台。
• 不让 vendor telemetry 默认接收 regulated data。

Revocation Runbook

触发场景：

• 客户撤销 consent。
• 员工离职或权限变更。
• Agent 版本被评估为不安全。
• Vendor contract scope 变化或供应商事件。
• 发现越权访问、跨租户泄露、异常工具调用。

执行步骤：

1. Classify: 判断撤销对象是 user、agent、tool、scope、tenant、workflow run 还是 vendor。
2. Freeze: 通过 policy engine 或 gateway 暂停相关 token exchange 和 tool invocation。
3. Invalidate: 撤销 refresh token、加入 jti deny list、缩短 active session、禁用 service principal。
4. Propagate: 向 API gateway、tool adapters、vector stores、workflow engine、vendor gateway 发布 revocation event。
5. Verify: 用测试调用验证 token introspection、scope check、tenant filter 已拒绝。
6. Preserve evidence: 保存触发原因、影响范围、时间线、审批记录、日志 hash。
7. Notify: 按 incident severity 通知 security、compliance、business owner、vendor manager、customer operations。
8. Restore: 风险解除后重新启用最小 scope，而不是恢复旧的广域权限。

运行指标：

• Mean time to revoke agent capability。
• Revocation propagation latency。
• Number of active tokens invalidated。
• Unauthorized call attempts after revocation。
• Evidence completeness for audit review。

Failure Modes and Controls

Architecture Reference Pattern

一个可落地的生产架构通常包含以下控制点：

1. Enterprise IdP: 负责 human authentication、MFA、OIDC claims。
2. Agent registry: 注册 agent identity、owner、risk tier、tool manifest、allowed scopes。
3. Consent and approval service: 管理客户 consent、员工 confirmation、supervisor approval。
4. Authorization server: 签发、交换、撤销 token，执行 scope 与 audience 控制。
5. Policy engine: 根据 tenant、role、case、risk、purpose、data class 做 allow / deny / step-up 决策。
6. Agent orchestrator: 管理 workflow run、state、tool planning、human handoff。
7. Tool gateway: 统一校验 token、mTLS、schema、rate limit、parameter policy。
8. Domain tools: CRM、payment、loan、AML、document、notification 等受控 API。
9. Audit evidence store: 保存不可篡改或强完整性日志、approval、consent、hash、policy decision。
10. Revocation and incident control: 支持 agent quarantine、scope disable、tenant freeze、vendor cutoff。

核心设计原则：Agent orchestrator 可以计划和协调，但最终授权必须在 authorization server、policy engine 和 tool gateway 中被强制执行。不要让 LLM prompt 成为唯一安全边界。

BA / PM Requirements Questions

CBAP+ 或 AI PM 在需求阶段应推动以下问题进入 backlog、NFR、acceptance criteria 与 architecture decision record：

• 这个 Agent 是代表客户、员工、团队、系统，还是自己作为服务主体行动？
• 哪些动作只是 draft，哪些动作会改变系统记录、资金、合规状态或客户沟通？
• 每个 tool invocation 的 business purpose 是什么？
• 是否存在不同 tenant、region、product、customer segment 的权限差异？
• Scope 是否能被业务方理解和审批？
• Consent 是否按数据、动作、时间、对象粒度表达？
• 哪些动作需要 MFA、客户确认、主管审批、dual control？
• Agent 被暂停时，哪些流程会降级为人工处理？
• 审计团队能否从日志重建 delegation chain？
• Vendor agent 是否受到相同的 token、scope、tenant、audit 和 revocation 控制？

Acceptance Criteria for Production Readiness

一个 Agent identity / delegated authorization 方案进入生产前，至少满足：

• 每个 Agent 有唯一 agent_id、owner、risk tier、allowed tools、allowed scopes。
• 每次 workflow run 有 run_id，并绑定 human initiator、purpose、business object。
• Tool 不接受共享 admin key 执行业务动作。
• Access token 为 audience-specific、short-lived、scope-limited。
• Delegation chain 能表达 Agent on behalf of human user 或 vendor on behalf of enterprise。
• Consent 与 approval 记录可查询、可撤销、可审计。
• Read、draft、submit、approve 权限被分离。
• 高风险动作有 step-up approval 和 action hash。
• Tenant boundary 在工具层强制执行。
• Token、claim、tool invocation、policy decision、approval outcome 进入审计链。
• Revocation runbook 经过演练，验证传播延迟和失败处理。
• Vendor agent 的合同边界、数据边界、token 边界一致。
• 红队或 abuse test 覆盖 confused deputy、prompt injection、cross-tenant access、approval replay。

Interview Section

30-Second Answer

我会把 AI Agent 当成一个有独立身份的软件主体来治理，而不是让它共用管理员账号。设计上要同时记录 human user、agent instance、workflow run 和 tool service account，并通过 delegated authorization 让 Agent 只在特定 purpose、tenant、case、scope 和时间窗口内行动。读、草稿、提交、审批要分离，高风险动作需要 step-up approval。所有 token 都要短生命周期、audience-specific、可撤销，并在工具层强制校验。最后用 audit claims 把“谁代表谁、在什么授权下、对什么对象、调用了什么工具、结果是什么”完整记录下来。

2-Minute Answer

我会从 identity taxonomy 开始，而不是先讨论 OAuth 配置。生产 Agent 至少有六类身份：human user、agent instance、workflow run、tool/service account、vendor agent 和 supervisor。核心原则是 accountable identity plus bounded delegated authority。也就是说，Agent 可以代表人行动，但不能伪装成人，也不能继承人的全部权限。

架构上，我会让企业 IdP 负责 human authentication，让 agent registry 管理 Agent 的 owner、risk tier、allowed tools 和 allowed scopes。每次任务创建 run_id，authorization server 通过 token exchange 或 on-behalf-of flow 签发短期、audience-specific、purpose-bound token。Token 里包含 sub、actor、agent_id、run_id、tenant_id、purpose、scope、approval reference 等关键 claim。工具层必须验证这些 claim，而不是只相信 Agent 的 prompt 或服务账号。

产品上，我会把权限拆成 read、draft、submit、approve。比如 payment dispute assistant 可以读取客户最近 90 天交易并创建 dispute 草稿，但提交 dispute 要客户确认和 step-up。Loan servicing agent 可以模拟还款方案，但不能自动修改还款计划。AML assistant 可以汇总证据，但不能关闭 case 或提交 SAR。

控制上，我会设计 consent UX、scope catalog、delegated authorization matrix、token logging spec 和 revocation runbook。主要风险包括 confused deputy、privilege creep、stale consent、shared secrets、vendor overreach、missing audit 和 cross-tenant leakage。对应控制是工具层强授权、最小 scope、短 TTL、可撤销 consent、tenant isolation、approval token、action hash 和完整审计链。这样既能让 Agent 提升效率，又能满足金融零售对责任、合规、客户信任和可追溯性的要求。

Portfolio Exercise

目标：为“金融零售支付争议 AI Assistant”设计一套 production-ready identity / delegated authorization 方案，形成可展示作品集。

交付物：

1. Agent identity card: 定义 agent_id、owner、risk tier、allowed tools、prohibited actions。
2. Delegated authorization matrix: 覆盖 transaction read、dispute draft、dispute submit、customer notification。
3. Scope catalog: 至少 12 个 scope，区分 read、draft、submit、approve、export。
4. Consent UX copy: 写出客户授权读取交易、创建草稿、提交 dispute 的三段界面文案。
5. Token claim design: 给出 access token 的 claim 示例与日志字段。
6. Step-up flow: 画出或描述从 Agent proposal 到客户确认再到 submit 的流程。
7. Failure-mode analysis: 至少列出 8 个风险和对应控制。
8. Revocation drill: 描述客户撤销授权、Agent 版本被暂停、供应商事件三种场景。

评估标准：

• 是否能清楚区分 human user、Agent、workflow run、tool account。
• 是否避免共享 admin key 和 overbroad service account。
• 是否把 purpose、scope、tenant、case、customer、approval 绑定到 token 或 policy context。
• 是否体现金融零售场景下的客户信任、监管证据和操作责任。
• 是否能被 IAM engineer、安全架构师、产品负责人和合规负责人共同评审。

Production Checklist

• Agent 已注册唯一身份、owner、risk tier、allowed tools、allowed scopes。
• 每个 workflow run 都有 run_id、purpose、initiator、business object boundary。
• 没有共享 admin key、共享高权限 service account 或无法归属的 API key。
• Token 是短生命周期、audience-specific、scope-limited、tenant-bound。
• Delegation chain 能表达 Agent on behalf of user，而不是只显示用户或只显示服务账号。
• Read、draft、submit、approve 权限已拆分。
• 高风险动作有 step-up approval、action hash、single-use approval token。
• Consent UX 覆盖数据范围、行动范围、持续时间、撤销入口。
• Tool gateway 强制验证 sub、actor、agent_id、run_id、scope、purpose、tenant。
• Vendor agent 通过受控 gateway 和 purpose-bound token 访问内部系统。
• Tenant isolation 覆盖 API、memory、cache、vector store、logs。
• Audit logs 能重建 who / on behalf of whom / what authority / what object / what outcome。
• Revocation runbook 已演练并记录传播延迟。
• Abuse tests 覆盖 prompt injection、confused deputy、approval replay、cross-tenant access。
• 生产监控包含 denied scope、step-up rate、revocation latency、unusual tool invocation、vendor egress。

Closing View

AI Agent identity / delegated authorization 的成熟度，决定了 Agentic AI 能否从演示走向金融零售生产系统。真正的目标不是“让 Agent 调通 API”，而是让每一次 Agent 行动都具备清晰身份、有限授权、明确目的、可解释审批、可撤销能力和可审计证据。做到这一点，AI PM 和架构师才能把 Agent 从智能助手升级为受治理的业务执行能力。