让 Agent 借人的账号做事，迟早会出问题

很多企业做第一个 Agent 原型时，会走一条很顺手的路：让它用某个开发者的 token，或者给它挂一个通用服务账号。这样接 API 最快，演示也最容易跑通。

但一旦 Agent 开始进入真实流程，这条路会很快变危险。

Agent 和传统脚本不一样。脚本通常被写死在一条流程里，输入、输出、权限和运行时间比较明确。Agent 会根据上下文决定下一步，会调用多个工具，会把外部返回再喂回模型，还可能把任务交给另一个 Agent。它越像一个能干活的主体，就越不能被塞进「某个人的账号」或「一个大家共用的服务账号」里。

企业真正要回答的问题是「它是谁，代表谁，能访问什么，为什么能访问，谁对它负责，什么时候应该失效」。

这就是 Agent 身份层会变重要的原因。

NIST NCCoE 已经把这个问题单独拎出来。它在 2026 年的 concept paper 里讨论 software 和 AI agent 如何在企业架构中被识别、认证、授权、代表人执行动作，并把 least privilege、on-behalf-of、动态授权和人类身份绑定列为核心难点。这是身份体系正在面对的新对象。

Agent 身份是一条治理记录

Microsoft Entra Agent ID 的文档把方向说得很清楚：Agent ID 和 agent identity platform 是为了在企业里安全、合规地部署 AI agent。Microsoft 对 agent identity 的定义也很具体：它是 Entra ID 里的特殊 service principal，用来代表 AI agent。它的授权文档还强调，Agent 相关身份应使用低权限角色、资源级 Azure role 和 Graph delegated permission 等方式收窄范围，高权限角色不能随意给。

这个定义很关键。Agent 身份不是 UI 里显示的「销售助理」或「代码助手」。它应该是目录系统能管理的对象。它有 owner，有权限，有生命周期，有风险状态，有审计记录，也能被禁用、删除或纳入访问评审。

如果 Agent 没有这种身份，企业只能在日志里看到某个用户 token 或某个服务账号发起了请求。出了问题以后，很难回答：

  • 是哪个 Agent 发起的动作。
  • 它当时代表哪个用户或团队。
  • 它拿到的权限来自哪里。
  • 它是否仍然应该存在。
  • 它的 owner 是否还在公司。
  • 它是否继承了不该继承的高权限。

这些问题听起来像 IAM 细节，实际上会决定 Agent 能不能进入生产系统。

AWS 把身份写成 AgentCore 的基础件，也不是巧合

Amazon Bedrock AgentCore Identity 的文档也在处理同一个问题。AWS 把 workload identity 定义成跨部署环境和认证方案的稳定锚点，让 Agent 无论使用 IAM role、OAuth2 token 还是 API key 访问外部服务，都能维持一致身份。

这个「稳定锚点」很重要。企业 Agent 不会只活在一个运行环境里。它可能今天跑在 ECS，明天跑在 EKS 或 Lambda，也可能一部分跑在企业内网。它访问的也不只 AWS 资源，还包括 Slack、Salesforce、GitHub、Jira、内部 API 和数据库。

如果身份绑定在某台机器、某个临时 token 或某个部署方式上，治理会被运行环境撕碎。需要的是一层和部署位置解耦的身份：Agent 是谁，和它在哪里运行、当前用哪种认证方式，是两个问题。

AgentCore 的 agent identity directory 进一步把这个问题做成目录能力。文档说明，它与 IAM 集成，可以对 workload identity 的查看、创建、读取和删除做细粒度权限控制。换成工程话，就是不能只把 token 塞给模型，而要让身份、委托和授权成为平台能力。

关键问题是「谁代表谁」

Agent 身份里最容易被低估的，是委托关系。

一个普通后台服务通常代表系统本身执行任务。Agent 更复杂。它可能代表用户订会议、代表销售查 CRM、代表工程师改代码、代表财务生成报表，也可能代表组织执行定时巡检。不同场景下，权限边界完全不同。

所以企业 Agent 授权至少要拆成两层：

第一层是 Agent 自己的身份。它说明这个自动化主体是谁，属于哪个应用或团队，谁维护，是否可信。

第二层是用户或组织对它的委托。它说明 Agent 此刻代表谁做事，能访问哪些资源，scope 多大，期限多久，是否需要审批。

OpenID Foundation 的《Identity Management for Agentic AI》也把这个压力讲得很清楚。Agent 会作为客户端或非人身份参与认证与授权；多用户 on-behalf-of、递归委托和非确定性行动，会让传统 OAuth/OIDC 模型遇到新的扩展压力。

OAuth 2.0 Token Exchange 提供了一种把一个 token 交换成另一个 token 的标准机制，适合表达「代表某个主体访问另一个资源」的委托场景。它还区分 delegation 和 impersonation，并用 act actor claim 表达谁在代表谁行动。RFC 9396 的 Rich Authorization Requests 则允许通过 authorization_details 表达比传统 scope 更细的授权需求，例如动作、资源位置、数据类型。对 Agent 来说，这比一个粗粒度 crm.write scope 更接近真实任务。

这些标准不是为 Agent 专门发明的，但 Agent 会把它们推到前台。因为 Agent 最常做的事，就是在多系统之间代表人行动。

最小权限要按动作，而不是按 Agent 名字

很多团队会说「这个 Agent 是给销售用的，所以给它 CRM 权限」。这仍然太粗。

一个销售 Agent 可能需要读客户资料、写跟进记录、生成报价、发邮件、创建合同、查询发票。这里每个动作的风险都不一样。读客户资料和发送合同不能用同一个默认权限；查自己的客户和查全公司客户也不能混在一起。

Agent 的最小权限应该按动作设计，而不是按名字设计。

更稳的做法是：

  • 默认只给只读 scope。
  • 写入动作单独授权。
  • 外发动作单独确认。
  • 高价值资源按任务临时授权。
  • 授权请求里写清动作、资源和数据类型。
  • token 有明确过期时间和 audience。
  • 任务结束后撤销临时委托。

这看起来会增加产品摩擦，但它是在用可控摩擦换生产资格。Agent 一旦能执行真实动作，权限过宽带来的「可能真的改错系统、发错邮件、删错数据、提交错代码」。

借用个人 token 会制造四类债

让 Agent 借人的 token，短期最省事，长期最难收拾。

第一类债是权限债。人的账号往往有大量历史权限，Agent 借用之后会继承这些权限。它可能拿到任务本来不需要的系统、数据和写权限。

第二类债是责任债。日志里显示是某个人调用了 API，但实际动作可能是 Agent 根据模型判断完成的。人、Agent、平台、工具之间的责任边界会混在一起。

第三类债是生命周期债。员工调岗、离职、项目结束以后，Agent 是否还应该继续使用这个 token？如果 token 被复制到多个运行环境里，撤销会很麻烦。

第四类债是审计债。安全团队想追问「哪些 Agent 访问了客户数据」，却只能查到个人账号或服务账号访问了客户数据。Agent 这一层从审计视角消失了。

这些债平时不明显，出事故时会集中爆发。

身份层会改变 Agent 平台的产品形态

一旦把 Agent 当成身份主体，平台设计会发生变化。

Agent 创建不应该只是「保存一个 prompt」。它应该同时创建或绑定身份对象。Agent 发布不应该只是「把流程上线」。它应该进入目录、owner、权限、风险和审计系统。Agent 调工具不应该只是「模型选择函数」。它应该经过身份、委托、scope、资源和策略判断。

这会让 Agent 平台更像企业软件，而不是聊天产品。

Google Agentspace 的访问控制文档也说明同一条路：Agent 平台会进入云 IAM 体系，通过预定义角色和自定义角色控制 API 与资源访问；文档还提醒基础 Owner、Editor、Viewer 这类角色过宽，不如使用产品专属角色。这类细节说明，Agent 产品最终会落到组织已有的身份和权限系统里，而不是停留在应用内开关。

一个生产级 Agent 平台至少要能回答这些问题：

  • 组织里有哪些 Agent 身份。
  • 每个 Agent 的 owner 是谁。
  • 哪些 Agent 有高权限。
  • 哪些 Agent 最近没有使用但仍然启用。
  • 哪些 Agent 可以代表用户访问外部 SaaS。
  • 哪些权限是永久授予，哪些是临时委托。
  • 哪些 Agent 的 token 或 credential 已过期、被撤销或被轮换。

这些问题没有模型榜单那么吸引人，但企业部署时非常实际。没有身份层，Agent 很容易变成新一代影子账号。

分水岭是可撤销的委托

Agent 未来会越来越能干。它能读文档、查系统、写代码、发消息、下订单、提交审批。能力越强，身份越不能模糊。

好的身份设计不只是为了「登录成功」。它要让组织能清楚地授予、限制、观察和撤销。谁代表谁，能做什么，做到什么时候，出了问题怎么停下来，这些才是企业 Agent 的底线。

所以 Agent 进企业以后，第一件事给它一个身份。没有身份，就没有可靠委托；没有可靠委托，就没有真正可控的自动化。