企业Agent接入GitHub、Jira或客户数据库时，最危险的捷径是让多个Agent共用服务账号，再把API密钥塞进环境变量。任务能跑起来，权限归属却变得模糊：谁调用了什么、代表哪位用户、令牌泄露后能否被复用，都很难回答。Google Cloud在8月22日将Agent Identity认证管理器和新版API推进正式可用，试图把身份、凭证与审计拆成独立控制层。

服务账号适合工作负载，却很难描述Agent的双重身份

传统服务账号通常代表一项应用，多个进程可以共用；Agent却可能在同一运行时里自主调用不同工具，有时以自身权限执行，有时又代表某位员工访问外部系统。如果只记录服务账号，审计人员看到的是“应用完成了操作”，却无法确认哪个Agent依据谁的授权做出决定。

Agent Identity为部署后的Agent分配独立SPIFFE身份和X.509证书。证书有效期为24小时并自动轮换，访问Google Cloud服务时使用与证书绑定的短期令牌，降低令牌被拷走后异地重放的风险。与普通服务账号相比，这类身份默认不共享、不能被直接冒充，也不允许开发者生成长期服务账号密钥。

保险库接管密钥，但不会把所有工具变成同一种认证

认证管理器更像Agent与外部工具之间的凭证经纪人。团队为GitHub、地图、工单系统或MCP服务配置认证提供方，把API Key、OAuth客户端密钥和用户令牌放进托管保险库。Agent调用工具时，ADK先依据Agent身份向保险库申请对应凭证，再把认证头注入请求，Agent本身不需要读取明文密钥。

三种常见场景因此能被分开治理：机器到机器使用两方OAuth，简单外部服务使用API Key，需要员工授权的数据则走三方OAuth。最后一种尤其重要，因为系统能同时记录Agent和授权用户，让“谁的权限被谁使用”进入同一审计链，而不是把所有动作都归到一个共享机器人账号。

FDE要交付的不是接入成功，而是凭证生命周期

对FDE而言，这项能力会改变工具接入清单。过去验收常停在“Agent能否调用CRM”，现在还要明确调用主体、授权方式、令牌作用域、用户撤销、过期刷新、地域和故障回退。每个工具都应绑定最小权限认证提供方，并用Agent的SPIFFE身份限制谁能取用，不能因为凭证集中托管就把保险库变成新的万能钥匙。

上线测试也应覆盖凭证之外的失败路径：用户撤销授权后是否立即失效，OAuth刷新失败时是否转人工，工具返回401会不会触发无限重试，Agent被复制到另一运行环境后能否继续使用旧令牌。只有把这些轨迹接入日志与告警，独立身份才会转化为可运营的安全边界。团队还应给认证提供方设置负责人、轮换周期和停用流程，定期清理已下线Agent与遗留授权；否则集中保险库只会把分散的秘密债务搬到一个更醒目的地方。

编辑判断：Agent身份正在成为企业工具调用的地基

Google这次GA的意义，不是又增加一种登录方式，而是把Agent从“应用里的功能”提升为需要独立治理的主体。新版Agent Identity API取代不会进入正式版的旧IAM Connectors API，多个亚太、欧洲和美洲区域已经提供正式能力，部分区域仍处预览，迁移和部署仍要核对区域可用性。

边界同样清楚：身份只能证明调用者是谁，不能判断模型的决定是否正确，也不能替代工具级授权、人工审批、数据防泄漏和行为评测。企业若继续给每个Agent宽泛权限，短期证书只是让错误动作留下更清晰的名字。ATYUN认为，生产Agent的标准工具箱应把独立身份、短期凭证、最小权限和双主体审计放在模型选择之前；没有这层地基，工具越多，责任越难追。