文章摘要前十六篇已经把生产级 Agent 从任务规划、Tool Calling、Memory、Checkpoint、Human-in-the-Loop、多 Agent 协作、安全沙箱、质量门禁、Control Plane 一直推进到 Agent Registry 与 Capability Marketplace。到这一阶段平台已经能回答“有哪些 Agent”“有哪些能力”“一个 Run 现在做到哪”“某个 Tool 谁在用”但还有一个更基础的问题没有真正解决Agent 到底以谁的身份执行很多系统只有两种身份用户和服务账号。用户连接一次 Google Drive、GitHub、CRM 或邮件后Agent 就长期复用这个 OAuth Token内部 MCP Server 则常常使用所有 Agent 共享的一把 API Key多 Agent 场景里Supervisor 把任务交给 Sub-Agent 时权限也跟着模糊传播。于是审计时只能看到“sales-agent 调用了 crm.update”却回答不了这是哪个用户委托的为了哪个业务目标权限从哪一次授权而来为什么可以修改这一个客户而不是整个 CRM这次权限什么时候失效Sub-Agent 是否有权继续把它转交给另一个 Agent本篇把身份和权限正式纳入 Agent Control Plane建立 Human Identity、Agent Workload Identity、Connection Grant、Purpose Binding、Execution Grant、Capability Token、Approval、Resource Scope、Credential Broker、Delegation Chain 和 Revocation 等核心对象。目标不是重新发明 OAuth而是在传统身份系统和 Agent Runtime 之间增加一层Delegated Authority用户可以长期连接系统但 Agent 每次执行只能获得与当前 Run、Purpose、Capability、Resource 和 Deadline 绑定的短期最小权限。完成这一层以后每一次 Tool Call 都必须能回答四个问题谁发起、代表谁、为什么做、基于什么授权。一、为什么 Agent 身份不能只用 Service Account最简单的企业 Agent 通常这样部署sales-agent ↓ service-account-sales-agent ↓ CRM看起来已经有独立身份。但当 80 个销售都使用同一个 Agent 时CRM 日志只看到service-account-sales-agent你不知道哪位销售触发 服务哪个客户 为了什么任务 有没有用户授权Service Account 能表达哪个工作负载不能完整表达这个工作负载正在代表谁所以 Agent 调用至少需要两种主体Workload Identity Human Subject二、Human Identity 和 Agent Identity 是两回事定义publicrecordHumanIdentity(StringsubjectId,StringtenantId,SetStringroles,SetStringgroups,EmploymentStatusstatus){}AgentpublicrecordAgentIdentity(StringagentId,Stringversion,StringownerTeam,StringworkloadPrincipal,AgentStatusstatus){}工具调用时同时携带subjectuser-82 agentsales-renewal-agent而不是二选一。三、“代表用户执行”不是 Impersonation 的同义词很多系统直接做Agent 使用用户完整 Token这接近ImpersonationAgent 得到了用户本人的整个权限面。更安全的目标应该是Delegation也就是用户授权这个 Agent 在这个任务里 为了这个目的 访问这些资源 做这些动作授权范围应该小于用户本人的总权限。四、整个授权链应该长这样Human Identity ↓ Connected Account ↓ Connection Grant ↓ Agent Run ↓ Purpose Binding ↓ Capability Request ↓ Policy Decision ↓ Approval必要时 ↓ Execution Grant ↓ Ephemeral Credential ↓ Tool Invocation这里每一层解决不同问题。五、Connection Grant用户长期连接不等于 Agent 长期执行权用户在设置里连接Google Drive GitHub CRM Email得到 ConnectionpublicrecordConnectionGrant(StringconnectionId,StringsubjectId,StringtenantId,Stringprovider,SetStringproviderScopes,StringcredentialRef,ConnectionStatusstatus,InstantconnectedAt,InstantreauthAt){}它可以存在 30 天、90 天甚至更久。但它只表示用户允许平台连接这个 Provider不是所有 Agent 永久获得 Provider Scope六、Purpose BindingAgent 为什么需要这次权限这是 Agent 场景里非常重要、传统 OAuth 又往往没有直接表达的一层。例如crm.customer.read用于renewal-risk-review和用于bulk-marketing-export风险完全不同。所以 Run 创建时应该固定publicrecordRunPurpose(StringpurposeId,StringrunId,StringtaskType,Stringdescription,SetStringallowedCapabilityPatterns,InstantexpiresAt){}Purpose 不能由 Agent 执行一半以后随意扩大。七、Capability 是权限决策的业务语言上一期已经建立Capability Registry所以 Agent 不应该请求OAuth Scope: https://www.googleapis.com/auth/...它应该请求drive.document.read crm.customer.read email.send cloudrun.deployProvider Scope 由 Registry 映射。这样业务 Policy 不会被某一家 SaaS 的授权格式绑死。八、Capability RequestpublicrecordCapabilityRequest(StringrunId,StringstepId,StringagentId,StringsubjectId,StringtenantId,Stringpurpose,StringcapabilityId,SetStringresourceIds,JsonNodeproposedAction,RiskLevelrisk){}例如{runId:run-1842,agentId:renewal-agent,subjectId:user-82,purpose:renewal-review,capabilityId:crm.customer.read,resourceIds:[customer/12345]}九、Resource Scope 比 OAuth Scope 更接近 Agent 真正需要的权限OAuth Scopecrm.read可能意味着读取整个 CRM。这对于当前任务太宽。Execution Grant 更应该变成crm.customer.read customer/12345甚至fields: name stage recent_activity这就是Scope → Resource → Field三层收缩。十、为什么“用户本来就有权限”还不够用户可能有查看 10 万客户权限。Agent 当前只需要分析一个客户。如果直接继承用户完整权限Prompt Injection 一旦成功Agent 就可能枚举全库最小权限的目标是Agent 权限 User 权限而不是等于。十一、Execution GrantPolicy 通过后生成publicrecordExecutionGrant(StringgrantId,StringparentConnectionId,StringrunId,StringstepId,StringagentId,StringsubjectId,StringtenantId,Stringpurpose,StringcapabilityId,SetStringresourceIds,intmaximumCalls,InstantnotBefore,InstantexpiresAt,GrantStatusstatus){}一个典型 Grant有效 10 分钟 最大调用 3 次 Capability crm.customer.read Resource customer/12345十二、Grant 的生命周期应该比 Run 更短Run 可能持续4 小时 2 天 甚至一周不能因此给一个 7 天 Access Token。每个阶段按需申请短期 Grant。例如Research 阶段 只读 Approval 后 短期写权限 发布完成 立即撤销权限随着任务阶段变化。十三、Progressive Authority这是一种很适合 Agent 的模式先给低风险权限 证明需要以后 再升级权限例如Step 1 crm.read Step 2 生成更新 Proposal Step 3 用户批准 Step 4 crm.update不要一开始就给crm.admin十四、Approval 是 Authority UpgradeHuman-in-the-Loop 不只是“点确认”。它应该被理解为权限升级事件批准前Agent 只能准备批准后获得一次或短期写能力这样 Approval 和 IAM 才真正连接起来。十五、Approval 必须绑定 Proposed Action用户批准给客户 A 发一封续约邮件Agent 不能把这个批准拿去给 300 个客户群发所以 Approval 保存publicrecordApproval(StringapprovalId,StringrunId,StringcapabilityId,StringactionHash,StringapprovedBy,InstantapprovedAt,InstantexpiresAt){}Tool 执行前重新算 Action Hash。任何关键参数变化重新审批十六、短期 Credential 才真正接 ProviderCredential BrokerpublicinterfaceCredentialBroker{EphemeralCredentialissue(ConnectionGrantconnection,ExecutionGrantgrant,ProviderBindingprovider);}返回publicrecordEphemeralCredential(Stringtoken,InstantexpiresAt,SetStringproviderScopes,Stringfingerprint){}Agent 不保存长期 Refresh Token。十七、为什么 Refresh Token 必须和 Runtime 分离Access Token 泄漏几分钟到几小时Refresh Token 泄漏可能持续很久如果代码 Agent、Browser Agent、Sandbox 都能读取 Refresh Token攻击面非常大。更合理Refresh Token 只存在 Credential Vault Agent Runtime 只获得短期 Access Token十八、Capability Token 可以进一步降低中心依赖每次 Tool 调用都访问中央 Authority Service容易形成全局瓶颈。可以签发Capability Token例如 JWT{iss:agent-authority,sub:user-82,agent:renewal-agent,run:run-1842,purpose:renewal-review,cap:crm.customer.read,resource:[customer/12345],calls:3,exp:1780000000}Tool Gateway 本地验证签名。低风险读取可以减少回中心请求。十九、高风险能力不要完全离线验证例如payment.refund cloud.delete permission.change即使 Token 已签名也可以要求Online Revocation Check Approval Check因为这类动作需要更强撤权能力。二十、Agent-to-Agent Delegation 更麻烦Supervisor拥有 customer.read把任务交给 Sub-Agentresearch-agent问题是Sub-Agent 自动继承全部权限吗我的答案是不应该每次转交重新生成子 Grant。二十一、Delegation ChainpublicrecordDelegationLink(StringdelegationId,StringparentGrantId,StringfromAgentId,StringtoAgentId,SetStringdelegatedCapabilities,SetStringdelegatedResources,InstantexpiresAt){}原则Child Authority ⊆ Parent Authority子 Agent 不能获得父 Agent 没有的权限。二十二、禁止 Authority Expansion如果父 Agent 有customer/12345 read子 Agent 请求customer/*必须失败。如果父 Agent 只有read子 Agent 请求update也失败。这叫Monotonic Restriction权限只能收缩不能在委托链中扩大。二十三、限制委托深度否则Supervisor → Agent A → Agent B → Agent C → Agent D最终很难审计。可以delegation:max-depth:2高风险 Capabilitydelegation_allowedfalse只能原 Agent 使用。二十四、Scheduled Agent 怎么授权定时任务没有用户在线。例如每天 8:00 生成销售风险报告这时不能依赖用户临时确认需要Standing Delegation但必须更严格。二十五、Standing DelegationpublicrecordStandingDelegation(StringdelegationId,StringownerSubjectId,StringagentId,StringscheduleId,Stringpurpose,SetStringcapabilities,SetStringresources,RiskLevelmaximumRisk,InstantexpiresAt,ReviewPolicyreviewPolicy){}例如每天读取 CRM 只读 只处理 owner 的区域客户 有效 30 天二十六、Standing Delegation 必须定期重新确认不能2026 年授权 2031 年还在跑可以低风险 90 天 Review 中风险 30 天 高风险 不允许 Standing Delegation二十七、Condition Watch 也属于委托未来 Agent 可能持续监控价格 邮件 安全事件 市场变化它不是一次 Run。Authority 应绑定Watch Definition而不是给 Agent 永久账户权限。二十八、Browser Session 是 CredentialBrowser Agent 登录成功后Cookie Storage State Session都代表真实权限。所以 Browser Session 必须进入 Identity 系统。publicrecordBrowserSessionAuthority(StringsessionId,StringsubjectId,StringagentId,Stringpurpose,SetStringallowedSites,SetStringallowedActions,InstantexpiresAt){}二十九、用户人工通过 MFA 后不等于后续动作全放行Human Takeover 可能只为了Authentication用户完成验证码后Agent 不应该理解成之后所有操作都批准Authentication Approval 和 Action Approval 必须分开。三十、MCP Server 也需要主体身份本地 MCP Demo 常见一把 API Key 所有 Agent 共用生产应该至少传Agent Identity Human Subject Tenant Purpose Capability Token否则 MCP Audit 只能看到某个 Server 被调用看不到授权链。三十一、Tool 端不能完全相信 Agent 自报字段Agent 请求里写{subject:admin}不能就相信。身份必须来自签名 Token Gateway Service Mesh Identity而不是 Prompt 或 JSON 自报。三十二、Signed Context调用 Tool 时可以传X-Agent-Authority: signed-token内部包含run agent subject tenant purpose capability resource expiryTool 验证签名后再执行。三十三、不要让 LLM 决定自己有没有权限模型可以说“为了完成任务我需要 crm.update。”它只能提出 Request。真正决策由Policy Engine完成。LLM 不是 Authorization Engine。三十四、Policy 要使用确定性数据输入用户角色 Agent ID Purpose Capability Risk Resource Tenant Connection Scope Approval 时间不是让另一个模型判断“你觉得这次调用合理吗”LLM 可以辅助风险解释但不能单独做最终授权。三十五、Data Classification 进入 Authority资源不仅有 ID。还有敏感等级publicenumDataClass{PUBLIC,INTERNAL,CONFIDENTIAL,RESTRICTED}Agent Runtime Profile 可以限制Code Sandbox 最高 INTERNAL HR Agent 允许 CONFIDENTIAL 高安全审批 才允许 RESTRICTED三十六、Output Authority 同样重要读取数据以后Agent 要把结果发到哪里Read 权限 ≠ Export 权限所以 Capability 还要区分data.read data.summarize data.export很多数据泄漏并不是非法读取而是合法读取后非法外传。三十七、Egress Policy例如CRM CONFIDENTIAL可以内部总结但不能发送到公开 WebhookTool Policy 需要组合Input Data Class Destination三十八、Agent Memory 不能突破原权限Agent 在一次有权限 Run 里读到敏感信息。然后写进长期 Memory。以后另一个用户 Run 又读出来。这会形成权限穿透所以 Memory Item 要携带source_authority data_class tenant subject_scope检索时重新授权。三十九、Memory AuthorizationpublicrecordMemoryRecord(StringmemoryId,StringtenantId,StringsubjectScope,DataClassdataClass,StringsourceGrantId,InstantexpiresAt){}Memory 不是“模型已经知道了所以可以继续用”。它仍然是受控数据。四十、Artifact 也必须继承授权Agent 生成分析报告 CSV 截图 代码 Patch这些 Artifact 可能包含原始受限数据。Artifact Registry 保存derived_from classification access_scope不要一生成文件就变成“谁拿链接都能下载”。四十一、审计必须保存完整 Delegation Chain例如User Zhang ↓ Standing Delegation ↓ Sales Supervisor Agent ↓ Research Sub-Agent ↓ crm.customer.read出问题时必须能回放权限怎么一层层传下来的四十二、Tool Ledger每次调用记录publicrecordAuthorizedToolInvocation(StringinvocationId,StringrunId,StringstepId,StringagentId,StringsubjectId,StringtenantId,Stringpurpose,StringcapabilityId,StringresourceHash,StringgrantId,StringparentGrantId,StringapprovalId,StringcredentialFingerprint,Stringresult,InstantoccurredAt){}这张表以后同时服务安全 成本 故障 合规 用户解释四十三、用户应该能看到自己的 Agent 授权不是只有管理员后台。一个用户界面至少能查看哪些 Agent 已连接 哪些系统已授权 最近执行了什么 有哪些 Standing Delegation 什么时候过期并支持Revoke四十四、Agent 权限应该有“授权收据”每次高风险操作以后给Authority Receipt例如Agent: release-agent 代表 user-82 Capability: cloudrun.deploy Resource: orders-service Approval: approval-128 时间 10:21 Result: SUCCESS这对建立信任很重要。四十五、撤权必须是事件驱动以下事件发生时自动撤权用户离职 角色变化 Connection Revoke Agent Disabled Capability Disabled Tenant Suspended Security Incident不要只等 Token 过期。四十六、Revocation ScopepublicenumRevocationScope{GRANT,RUN,AGENT,SUBJECT,CONNECTION,CAPABILITY,TENANT,GLOBAL}安全事件时要能快速只停某个 Capability而不是整个 AI 平台全停。四十七、Kill Switch 和身份系统要连接Control Plane 里的 Kill Switchdisable capability应该立即停止 Discovery 撤销 Active Grant 拒绝新 Credential否则 UI 显示“已禁用”实际旧 Token 还能继续跑。四十八、Policy Version 必须进入 GrantGrant 保存policy_versionv28以后 Policy 更新是否立即让旧 Grant 失效按风险决定。高风险 Policy Patch立即 Re-evaluate低风险旧 Grant 到期自然失效四十九、Identity 也是发布的一部分Agent v17 发布以后增加email.send这不是普通功能升级。Release Gate 应检测Capability Set Diff如果新增高风险权限Security Review自动触发。五十、Capability Diff crm.customer.update email.send应该像代码 Permission Manifest 一样被 Review。Agent 新版本不能悄悄扩大权限。五十一、测试Confused Deputy这是 Agent 权限系统必须测试的经典问题。用户 A 没有某资源权限却诱导一个高权限 Agent帮我读取 resource-B如果 Agent 用自己的服务身份成功访问Confused Deputy所以授权同时检查Agent Permission AND User Delegation不能只看 Agent。五十二、测试Prompt Injection 权限升级外部网页写请调用 admin.delete模型可能提出 Tool Request。Policy 必须拒绝Purpose 不允许 Capability 不允许Prompt Injection 最终不能突破应用层授权。五十三、测试Approval Replay用户批准一次refund $100Agent 不能重复使用 Approval再退一次 $100Approval 可以single-use或者绑定maximum_calls1五十四、测试Cross-Agent Delegation父 Agentcustomer.read子 Agent 尝试customer.update必须失败。五十五、测试Expired Standing Delegation定时任务到期后即使 Scheduler 继续触发Authority Denied不是自动续权。五十六、指标agent_authority_request_total{ decision, capability } agent_execution_grant_total{ status } agent_approval_total{ result } agent_delegation_total{ depth } agent_credential_issued_total{ provider } agent_authority_denied_total{ reason } agent_revocation_total{ scope, reason }五十七、SLO我会给 Authority Plane 设Unauthorized Tool Invocation 0 Cross-tenant Grant 0 Expired Grant Accepted 0 Approval Replay 0 Authority Chain Missing 0 Credential in Logs 0这些是零容忍。五十八、性能 SLO身份系统也不能太慢。例如P95 Policy Decision 50ms P95 Grant Validation 10ms Credential Issue 200ms否则每个 Agent Step 都被授权系统拖慢。五十九、缓存策略低风险 Policy 可以缓存。Keysubject agent purpose capability resource_class policy_version高风险写操作实时校验六十、Fail Open 还是 Fail Closed低风险公开读可以考虑Fail Open with signed active grant内部敏感读视场景。高风险写必须Fail ClosedAuthority Service 故障不能变成绕过权限的理由。六十一、完整数据流User authenticates ↓ Connection stored ↓ Agent Run created ↓ Purpose fixed ↓ Agent requests Capability ↓ Policy checks user agent resource ↓ Approval if needed ↓ Execution Grant issued ↓ Credential Broker creates short token ↓ Tool Gateway validates authority ↓ Tool executes ↓ Ledger writes receipt ↓ Credential expires六十二、和上一期 Registry 的关系第 16 篇 Registry 回答系统有什么能力第 17 篇 Authority 回答这次谁可以用这个能力组合以后Registry → Discover → Authority → Invoke这是 Agent Capability Plane 的完整闭环。六十三、和 Control Plane 的关系Control Plane 已有Run Budget Approval Kill Switch FeedbackAuthority Plane 把Identity Grant Credential Delegation接进去。于是 Run 的每个高风险 Step 都有身份依据。六十四、为什么这比“加一个 RBAC”复杂因为 Agent 的权限是动态的 短期的 任务驱动的 可以转委托的 带副作用的传统User → Role → Permission还不够。更接近User → Connection → Purpose → Agent → Capability → Resource → Approval → Execution Grant六十五、但不要因此造一套完全独立 IAM仍然复用企业现有SSO OAuth OIDC IAM RBAC Group Service AccountAgent Authority 是上层编排。不是替换底层身份系统。六十六、本篇上线检查清单□ Human Identity 与 Agent Workload Identity 分离 □ 每个 Tool Call 同时保留 Subject 与 Agent □ 长期 Connection 不直接作为执行权限 □ Run 有明确 Purpose □ Agent 请求业务 Capability而不是直接请求 Provider Token □ Execution Grant 绑定 Run、Purpose、Capability 和 Resource □ Grant 短生命周期 □ 高风险能力需要 Approval □ Approval 绑定 Action Hash □ Refresh Token 不进入 Agent Runtime □ Tool 使用短期 Credential □ Agent-to-Agent 委托权限只能收缩 □ 委托深度有限制 □ Scheduled Agent 使用 Standing Delegation □ Standing Delegation 定期复核 □ Browser Session 被视为 Credential □ Memory 与 Artifact 保留原授权范围 □ Capability Disable 会撤销 Active Grant □ Agent Release 检查 Permission Diff □ Tool Ledger 能还原完整 Delegation Chain □ 用户能查看并撤销自己的 Agent 授权总结Agent Identity 的核心不是给每个 Agent 建一个 Service Account。真正的问题是一个自主系统 正在代表真实的人 访问真实的数据 执行真实副作用所以每一次工具调用都应该可以回答Who initiated? Which Agent executed? On behalf of whom? For what purpose? Using which capability? Against which resource? Under which approval? Until when?当这些问题都有结构化答案以后Agent 才真正从“拿着用户 Token 的自动脚本”变成有明确委托边界的企业执行主体这也是 Agent Control Plane 从“能管理运行”走向“能管理权力”的一步。下一篇继续推进手搓生产级 AI Agent 系统18Agent Audit Ledger 与 Explainable Execution——让一次自动操作可以被完整回放、解释和举证。