2026年智能体身份开始从架构讨论变成云厂商的正式产品能力。Google Cloud 在7月更新了 Agent Identity 文档Microsoft Entra 已把智能体身份、条件访问、风险检测和生命周期治理放进同一套体系AWS、阿里云和火山引擎也提供了面向智能体的身份、凭证及用户委托能力。华为云、腾讯云则更多从智能体运行时或安全网关切入身份认证和访问控制。这轮变化解决的是一个很具体的问题员工登录企业系统后让智能体读取日历、查询客户资料、创建工单甚至发起交易目标系统究竟应该记录为“员工做的”“某个服务账号做的”还是“智能体代表员工做的”如果只记录员工智能体的行为被藏在人的账号后面如果只记录智能体又会丢掉授权来源和责任人。真正可用的方案需要把人、智能体、运行实例、任务和权限关系同时保留下来。智能体身份到底管什么智能体身份的四层对象智能体身份不是给 Agent 起一个名字也不是把现有服务账号换个标签。企业至少要区分四个对象。管理对象回答的问题常见载体生命周期人的身份谁发起或批准了任务企业账号、单点登录、通行密钥、多因素认证随员工和组织关系变化智能体身份哪个 Agent 在执行Agent ID、应用主体、身份蓝图、资产登记随智能体创建、变更和下线运行实例身份当前是哪一个进程或容器在调用工作负载身份、短期证书、短期访问令牌分钟、小时或单次运行委托关系Agent 代表谁、为哪个任务、能做什么OAuth令牌、授权声明、任务授权凭证限定任务、范围和有效期模型版本、系统提示词、工具清单会影响智能体行为应当进入智能体资产档案但它们本身不能代替运行身份。相同模型可以部署成多个 Agent同一个 Agent 又可以同时运行上千个实例。只记录“使用了哪个模型”无法回答是哪次运行访问了数据。委托关系也不等于人的登录态。人的账号证明用户是谁委托凭证还要说明用户允许哪个 Agent在什么时间内对哪个资源执行哪些动作。两者缺一不可。可以用一个公式理解最终权限只要其中一层不允许动作就不应执行。这样既不会把员工的全部权限复制给智能体也不会让智能体凭自己的高权限绕过用户边界。行业方案已经分成几条路线主流厂商的智能体身份路线各家产品名称不同但公开方案正在收敛到三条路线为智能体建立独立身份用短期工作负载凭证证明运行实例把用户委托令牌放进受控凭证库。核查厂商文档后也能看到各家覆盖范围并不相同不能只凭产品名称判断成熟度。独立Agent身份平台已经开始把Agent作为企业身份主体管理。厂商公开方案经核实的身份与委托机制官方文档示例及边界MicrosoftEntra Agent ID独立Agent身份、身份蓝图及父子关系支持自主权限和用户委托可一对一绑定专用Agent用户账号Copilot Studio创建Agent时生成身份创建者记为发起人可连接SharePoint或Dataverse具体安全能力受许可证约束Google CloudAgent Identity每个Agent分配SPIFFE身份和X.509证书证书默认24小时有效日志可同时显示Agent和用户官方示例包括代表用户访问Jira任务或GitHub仓库Auth Manager、三方OAuth等部分能力仍为预览支持的托管服务范围也有限AWSBedrock AgentCore IdentityAgent和工作负载使用独立身份支持入站JWT验证、双方OAuth、三方OAuth、凭证提供商和令牌保险箱官方示例是开发者Agent代表用户访问GitHub仓库Agent Registry另有预览状态不应与Identity能力混为一谈阿里云Agent Identity工作负载身份具有唯一ARN工作负载访问令牌可同时封装Agent和最终用户信息凭证由TokenVault托管官方教程包括Agent访问钉钉、百炼高代码执行敏感操作前获取用户即时授权审计接入ActionTrail火山引擎AgentKit智能体身份和权限管理平台支持用户池、企业OIDC单点登录、入站授权、出站OAuth凭证托管及Agent代表用户访问资源官方教程以读取飞书文档、操作GitHub仓库等为例属于AgentKit新近公开能力部署前应核对区域、开通状态和产品限制另一类方案主要从运行时、网关或跨应用授权切入能完成身份接入但不等同于完整的Agent身份治理平台。厂商公开方案已核实能力当前边界华为云AgentArts智能体运行时入站支持IAM、OAuth 2.0、API Key支持IAM委托、版本管理、运行时日志和安全沙箱公开文档重点是运行时认证和委托尚未看到与Entra或Google同形态的独立Agent身份目录腾讯云AI Agent安全网关提供身份鉴权与凭据管理并对模型与API访问做控制同时覆盖Token限流、数据脱敏和行为审计更接近网关侧安全准入公开页面未展示完整的用户-Agent双重身份、委托链和Agent生命周期目录Okta/Auth0Cross App Access企业身份提供方按中央策略签发跨应用身份断言使Agent可代表用户访问目标SaaS当前文档仍标注测试阶段限制解决的是跨应用委托不负责Agent运行实例身份NIST NCCoE软件与AI智能体身份和授权项目研究基于标准的Agent识别、认证、授权和可追责性目前是项目与概念框架不是可直接采购的产品或已完成标准这些方案并不意味着行业已经形成统一标准。2026年的一篇学术预印本综述梳理约80份标准、论文和厂商材料后将现有能力分为认证、授权与委托、凭证、来源证明、治理监控、审计证明六部分。其判断是工作负载认证最成熟单跳委托已有OAuth等可用方案多智能体跨域、跨层委托仍缺少广泛部署的统一协议。因此企业现阶段更适合采用兼容现有身份基础设施的组合方案而不是等待一个包办所有问题的新协议。人和智能体如何完成一次授权人机双重身份授权链智能体访问业务系统通常有三种方式。先分清场景再选择身份模式比统一发一个高权限服务账号更容易控制。业务场景应使用的身份权限来源典型例子智能体执行公共后台任务Agent自己的身份直接授予Agent的最小权限汇总公开运营数据、检查系统健康状态智能体代表员工访问个人资源用户身份 Agent身份用户委托权限不得超过该用户读取本人的邮件、日历、工单和代码仓库智能体执行高风险业务动作双重身份 单次或短期任务授权用户权限、Agent权限、业务策略共同决定支付、转账、修改权限、对外发送、删除数据Agent调用子Agent上游Agent 下游Agent 原始委托链每一跳继续收窄主Agent把合同检索交给法律检索Agent以“员工让采购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创建谁创建、谁负责、用途和风险是什么Agent目录、发布平台负责人、版本、工具、数据范围、有效期用户调用用户能否使用这个AgentSSO、Agent网关、条件访问用户、设备、时间、Agent ID、会话ID数据读取当前Agent能否为当前任务读取该数据数据网关、检索层、策略执行点资源、动作、策略版本、允许或拒绝原因工具执行动作是否超出任务和用户授权MCP网关、API网关、工具代理工具名、参数摘要、权限范围、结果状态子Agent委托下游权限是否继续收窄编排器、授权服务上下游Agent、委托范围、链路ID、有效期结果合成单独可读的数据组合后是否仍可交付结果出口、数据防泄漏、业务规则数据来源、组合关系、脱敏和审批记录权限撤销人员离职、角色变化或风险告警后如何立即停止身份平台、令牌服务、运行控制面撤销事件、受影响任务、停止和回滚结果这张表解决的是一个经常被忽略的问题每次数据访问都合法不代表最终组合结果一定合法。例如一个Agent分别读取员工通讯录和匿名投诉记录两次查询可能都通过权限检查但组合后可能推断出投诉人的身份。授权必须覆盖检索、委托、合成和返回而不能只覆盖单次API调用。身份认证也不能证明智能体的意图正确。SPIFFE证书可以证明某个受信运行实例正在调用OAuth令牌可以证明它具备某项授权但如果Agent受到提示注入仍可能在有效身份和有效权限下执行错误动作。因此身份控制必须与工具白名单、参数校验、数据边界、行为监测和高风险人工确认配合使用。企业如何把体系落到现有系统智能体身份落地架构多数企业不需要推倒现有身份系统。更现实的做法是保留员工统一身份在其旁边增加Agent目录、工作负载身份、委托授权和凭证代理再把控制接到API或MCP网关。建设模块可复用的现有能力需要新增的Agent能力可选技术或产品人员身份企业IdP、SSO、多因素认证、组织目录记录谁发起、批准和撤销任务Entra ID、Okta、Keycloak、企业IDaaSAgent目录应用台账、CMDB、服务目录Agent ID、负责人、版本、工具、风险级别、状态Entra Agent ID、云Agent Identity或自建目录运行身份Kubernetes服务账号、云角色、证书体系每实例短期身份、自动轮换、禁止长期密钥SPIFFE/SPIRE、云工作负载身份、短期STS委托授权OAuth/OIDC、IAM、RBAC/ABACAgent用户任务三方绑定、子Agent权限衰减OAuth Token Exchange、OBO、XAA或自建授权服务策略执行API网关、零信任访问、数据权限每次工具调用前按动作、资源、金额和环境判断OPA、Cedar、OpenFGA、SpiceDB、云IAM凭证管理KMS、密钥管理、特权访问管理Agent不见长期密钥按需注入短期凭证Vault、云Token Vault、Secrets Manager审计处置SIEM、操作审计、工单和应急平台关联人、Agent、实例、任务、委托链和策略结果云审计日志、OpenTelemetry、企业SIEM落地顺序建议按三步推进。第一步先完成可见性。建立Agent清单至少登记唯一ID、业务负责人、创建平台、模型版本、工具、数据范围、运行环境、用户群体、风险等级和下线日期。禁止一个共享服务账号承载多个Agent否则后续无法做差异化授权和审计。第二步改造凭证和授权链。人员继续使用企业SSOAgent使用独立工作负载身份访问个人资源使用用户委托访问公共后台资源使用Agent自有权限。长期密钥放入凭证库由代理在工具调用时换取并注入短期令牌。高风险动作增加金额、对象、时间、设备和人工确认等条件。第三步补齐运行期治理。每次数据读取、工具调用和Agent间委托都经过策略执行点。员工离职、Agent下线、风险告警或任务取消时令牌和委托关系可以立即撤销审计平台能从一次业务结果反查完整执行链也能从一次异常访问找出所有受影响结果。企业可以先选择一两个边界清晰的场景试点例如工单查询、知识检索或代码仓库只读分析。等身份链和审计链稳定后再扩大到写操作和交易类场景。上线前用这张表验收智能体身份上线验收面板一套智能体身份方案是否真正可用不看产品名称而看下面这些问题能否得到明确答案。验收问题底线标准能否区分员工、Agent和运行实例三者有独立标识不使用同一账号或同一长期密钥代替每个Agent是否有明确负责人创建时必须登记业务负责人和技术负责人人员变化时可移交Agent代表谁操作能否识别令牌或审计记录同时包含用户与Agent不允许匿名“代办”权限是否限定到任务至少约束资源、动作、有效期高风险场景还要约束金额、对象或次数子Agent能否扩大权限每次委托只能保持或收窄权限不能继承上游全部环境权限Agent能否读取长期凭证长期凭证不进入提示词、上下文和Agent代码只由代理按需使用授权是否在执行前生效API或工具真正执行前由确定性策略判断不能依赖模型自觉拒绝人员离职或任务取消能否立即停可撤销令牌、终止运行、阻断后续调用并定位受影响任务审计能否还原一次完整业务动作能关联用户、Agent、实例、任务、工具、策略、审批和结果Agent下线后权限是否同步清理身份禁用、令牌撤销、凭证解绑、策略删除和日志留存同时完成现阶段智能体身份的基础组件已经具备企业身份可以继续用OIDC和单点登录运行身份可以使用工作负载身份和短期凭证用户委托可以基于OAuth细粒度授权可以放在策略引擎和工具网关长期密钥可以交给凭证库。真正困难的部分是把这些组件连成一条不丢失上下文的执行链。企业最终要做到的并不是“系统知道有一个Agent”而是每个关键动作都能回答谁让它做、哪个Agent在做、哪次运行在做、被允许做什么、为什么此刻仍然允许以及出了问题如何立即停止。