智能体身份管控落地指南

2026年，智能体身份开始从架构讨论变成云厂商的正式产品能力。Google Cloud 在7月更新了 Agent Identity 文档，Microsoft Entra 已把智能体身份、条件访问、风险检测和生命周期治理放进同一套体系；AWS、阿里云和火山引擎也提供了面向智能体的身份、凭证及用户委托能力。华为云、腾讯云则更多从智能体运行时或安全网关切入身份认证和访问控制。

这轮变化解决的是一个很具体的问题：员工登录企业系统后，让智能体读取日历、查询客户资料、创建工单，甚至发起交易，目标系统究竟应该记录为“员工做的”“某个服务账号做的”，还是“智能体代表员工做的”？

如果只记录员工，智能体的行为被藏在人的账号后面；如果只记录智能体，又会丢掉授权来源和责任人。真正可用的方案，需要把人、智能体、运行实例、任务和权限关系同时保留下来。

智能体身份到底管什么

智能体身份的四层对象

智能体身份不是给 Agent 起一个名字，也不是把现有服务账号换个标签。企业至少要区分四个对象。

模型版本、系统提示词、工具清单会影响智能体行为，应当进入智能体资产档案，但它们本身不能代替运行身份。相同模型可以部署成多个 Agent，同一个 Agent 又可以同时运行上千个实例。只记录“使用了哪个模型”，无法回答是哪次运行访问了数据。

委托关系也不等于人的登录态。人的账号证明用户是谁，委托凭证还要说明：用户允许哪个 Agent，在什么时间内，对哪个资源，执行哪些动作。两者缺一不可。

可以用一个公式理解最终权限：

只要其中一层不允许，动作就不应执行。这样既不会把员工的全部权限复制给智能体，也不会让智能体凭自己的高权限绕过用户边界。

行业方案已经分成几条路线

主流厂商的智能体身份路线

各家产品名称不同，但公开方案正在收敛到三条路线：为智能体建立独立身份，用短期工作负载凭证证明运行实例，把用户委托令牌放进受控凭证库。核查厂商文档后也能看到，各家覆盖范围并不相同，不能只凭产品名称判断成熟度。

独立Agent身份平台已经开始把Agent作为企业身份主体管理。

另一类方案主要从运行时、网关或跨应用授权切入，能完成身份接入，但不等同于完整的Agent身份治理平台。

这些方案并不意味着行业已经形成统一标准。2026年的一篇学术预印本综述梳理约80份标准、论文和厂商材料后，将现有能力分为认证、授权与委托、凭证、来源证明、治理监控、审计证明六部分。其判断是：工作负载认证最成熟，单跳委托已有OAuth等可用方案，多智能体跨域、跨层委托仍缺少广泛部署的统一协议。

因此，企业现阶段更适合采用兼容现有身份基础设施的组合方案，而不是等待一个包办所有问题的新协议。

人和智能体如何完成一次授权

人机双重身份授权链

智能体访问业务系统通常有三种方式。先分清场景，再选择身份模式，比统一发一个高权限服务账号更容易控制。

以“员工让采购Agent创建一笔采购订单”为例，下面是一套可以由现有OIDC、OAuth、云IAM、策略网关和凭证库组合实现的企业参考设计，不代表某一家厂商提供了开箱即用的完整流程。

1. 员工先通过企业单点登录完成认证，身份提供方签发用户令牌。

2. Agent网关验证用户令牌，同时确认员工是否有权使用该采购Agent。

3. 若平台支持工作负载身份，Agent运行时使用自己的实例身份获取短期凭证；否则至少使用独立云角色和短期STS，不能复用员工密码或长期Token。

4. 当Agent准备调用采购系统时，授权服务同时计算员工权限、Agent权限、订单金额、供应商范围和任务有效期。

5. 企业可以把“超过金额阈值”“新增供应商或收款账户”等条件设为二次认证或人工确认点，并把确认结果写入本次任务授权。

6. 凭证代理在受控调用路径中提供短期OAuth或STS令牌。长期Client Secret和Refresh Token留在凭证库中，不进入模型提示词或上下文；短期令牌是否暴露给Agent进程，取决于具体产品实现。

7. 业务系统和Agent平台共同记录员工、Agent、运行实例、任务、授权策略和执行结果，才能形成可查询的同一条审计链。

这里最关键的是“双重可归因”。目标系统既知道背后的员工是谁，也知道实际执行者是哪一个Agent。Google Cloud明确提出，当Agent代表用户操作时，审计日志同时显示Agent和用户；阿里云公开文档把用户上下文、工作负载身份和凭证获取记录接入审计；火山引擎则已经给出企业SSO和Agent代表用户访问第三方资源的配置流程。

权限要在每个执行边界重新判断

智能体执行链上的授权关口

传统应用常在用户登录时完成一次授权，之后靠会话持续访问。智能体任务可能运行数小时，期间会拆分任务、调用多个工具、组合不同数据，原来的权限也可能已经变化。只在任务开始时检查一次，不足以覆盖整个执行过程。

关于多智能体“授权传播”的研究提出了七项结构要求。转换成企业控制点，可以落到下面这张表。

这张表解决的是一个经常被忽略的问题：每次数据访问都合法，不代表最终组合结果一定合法。例如，一个Agent分别读取员工通讯录和匿名投诉记录，两次查询可能都通过权限检查，但组合后可能推断出投诉人的身份。授权必须覆盖检索、委托、合成和返回，而不能只覆盖单次API调用。

身份认证也不能证明智能体的意图正确。SPIFFE证书可以证明某个受信运行实例正在调用，OAuth令牌可以证明它具备某项授权，但如果Agent受到提示注入，仍可能在有效身份和有效权限下执行错误动作。因此，身份控制必须与工具白名单、参数校验、数据边界、行为监测和高风险人工确认配合使用。

企业如何把体系落到现有系统

智能体身份落地架构

多数企业不需要推倒现有身份系统。更现实的做法是保留员工统一身份，在其旁边增加Agent目录、工作负载身份、委托授权和凭证代理，再把控制接到API或MCP网关。

落地顺序建议按三步推进。

第一步先完成可见性。 建立Agent清单，至少登记唯一ID、业务负责人、创建平台、模型版本、工具、数据范围、运行环境、用户群体、风险等级和下线日期。禁止一个共享服务账号承载多个Agent，否则后续无法做差异化授权和审计。

第二步改造凭证和授权链。 人员继续使用企业SSO；Agent使用独立工作负载身份；访问个人资源使用用户委托；访问公共后台资源使用Agent自有权限。长期密钥放入凭证库，由代理在工具调用时换取并注入短期令牌。高风险动作增加金额、对象、时间、设备和人工确认等条件。

第三步补齐运行期治理。 每次数据读取、工具调用和Agent间委托都经过策略执行点。员工离职、Agent下线、风险告警或任务取消时，令牌和委托关系可以立即撤销；审计平台能从一次业务结果反查完整执行链，也能从一次异常访问找出所有受影响结果。

企业可以先选择一两个边界清晰的场景试点，例如工单查询、知识检索或代码仓库只读分析。等身份链和审计链稳定后，再扩大到写操作和交易类场景。

上线前用这张表验收

智能体身份上线验收面板

一套智能体身份方案是否真正可用，不看产品名称，而看下面这些问题能否得到明确答案。

现阶段，智能体身份的基础组件已经具备：企业身份可以继续用OIDC和单点登录，运行身份可以使用工作负载身份和短期凭证，用户委托可以基于OAuth，细粒度授权可以放在策略引擎和工具网关，长期密钥可以交给凭证库。

真正困难的部分，是把这些组件连成一条不丢失上下文的执行链。企业最终要做到的并不是“系统知道有一个Agent”，而是每个关键动作都能回答：谁让它做、哪个Agent在做、哪次运行在做、被允许做什么、为什么此刻仍然允许，以及出了问题如何立即停止。