北京
你给AI Agent配了独立身份，权限也调好了，结果一次重新部署之后，它突然什么都读不到了。查日志，只看到一句"服务账号执行了操作"——哪个Agent干的？不知道。想单独掐掉一个Agent？其他Agent跟着一起挂。
这是很多团队用共享服务账号跑Agent时的日常。Google Cloud现在给出了一个解法，叫Agent Identity，属于Gemini Enterprise Agent Platform（也就是原来的Vertex AI）。每个Agent拿到一份可验证的独立身份，授权、拒绝、审计都能按Agent粒度来，跟对待真人账号一样。
它到底是一张什么"护照"
把Agent部署到Agent Runtime时打开这个功能，Google Cloud会基于开放的SPIFFE标准给它一个唯一身份，外加一张由Google创建和管理的X.509证书。在IAM里，这个身份就是一个可以绑定角色的principal。
几个值得记住的细节：
- 信任域在你启用Agent Platform API时自动创建。有组织时挂在组织层级，没有组织时挂在项目层级。
- 身份绑定的是Agent的资源ID，不是构建它的框架。ADK、LangGraph用起来都一样。
- 开箱自带两个默认角色，能访问自己的日志、指标、模型、会话和记忆。
- 令牌被Google管理的上下文感知访问策略锁在运行时里，靠mTLS证书绑定。令牌被偷走拿到运行时外面用，会直接401。偷来的凭证没法重放。
有一个坑要提前知道：IAM绑定里必须用principal://格式，不能写原始的spiffe://字符串，否则会返回INVALID_ARGUMENT错误。
三种打开方式，和一条部署顺序建议
第一种走Python SDK。定义一个普通的ADK Agent，包一层，部署时把identity_type传进去。注意API版本要用v1beta1，Agent Identity需要它。
第二种用adk deploy。部署前在Agent目录里放一个小配置文件，写上identity_type为AGENT_IDENTITY就行。
第三种用Agents CLI，适合快速测试和原型验证，加一个--agent-identity参数。
有个顺序上的建议：你可以先只带identity_type、不带代码，把Agent Runtime实例建出来。这样身份先到位，IAM可以先配好，代码之后再通过update补上。如果不加这个身份标志，Agent还是照旧用服务账号，现有流水线不会断。
权限分两层，别一次给满
比较稳的做法是把权限拆成一个共享地板和一个窄天花板。
第一层是项目里所有Agent的基线。用principalSet，一次绑定覆盖现在和将来的所有Agent，但只放低风险角色，比如服务用量消费、日志写入、指标写入这类。
第二层是单个Agent的窄授权。凡是敏感的，比如某个BigQuery数据集、某个装着客户数据的存储桶，只发给某一个具体Agent的principal。
多Agent场景还有个加分项。父Agent调用注册在Agent Registry里的子Agent时，父Agent的身份需要两个角色：一个用来查子Agent，一个用来调用子Agent的推理引擎。这两个角色要发给父Agent，不是发给你自己的用户账号——这个错误很常见，报出来的权限错误会让人一头雾水。
重新部署就换身份，权限不跟着走
这是会咬到SRE和平台团队的地方。流水线每次删除再重建Agent，Agent就会拿到一个新的reasoningEngines ID，也就是一个全新的principal。发给旧principal的权限不会自动跟过来。
想象一个普通的工作日：Agent带着对某个数据桶的读权限跑得好好的。一次重新部署、一个临时测试环境、或者一次带replace的terraform apply，把Agent重建了。新Agent启动，读不到东西——因为它的身份是新的，旧权限留在旧身份上。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
