谁拥有人工智能代理创建的云资源？

当人工智能代理创建虚拟网络、数据库或负载均衡器时，问题并不会随着任务结束而终止。资源可能仍在运行、持续消耗预算并需要维护，而所有权标签指向deploy-agent这样的机器身份，而不是一个可以联系或追究资源责任的人。

文章将这一问题称为云基础设施中的治理缺口：创建资源的执行身份不一定是其实际所有者。随着代理数量增加、创建速度加快，依赖员工身份的传统所有权机制已不足够。

发现由代理拥有的资源

第一步是盘点带有所有者标签的资源，然后将该标签的值与机构身份目录进行比较。在 AWS 和 Azure 中，可以将标签与角色记录或原生服务主体进行匹配。至于 Google Cloud，文章建议验证所有者值是否存在于员工目录中；如果不存在，按照所使用的检查规则，它就不是人类身份。

出现机器身份并不意味着资源不合法；自动化可能被设计为代表机构运行基础设施。但这项检查可以将审查范围缩小到确实需要指定人类所有者的资源。

实际会发生什么变化？

不应再自动将执行部署计划的人或账户视为所有者，而应让审批策略检查所有权标签本身。建议的规则是：如果可标记的资源没有所有者，或者所有者值不是个人的电子邮件格式，或者与已知代理身份之一匹配，则任何部署都不得通过。

文章建议将代理身份列表保存在传递给策略引擎的 JSON 文件中。如果列表缺失，策略应以故障关闭的方式运行，而不是允许未经检查的部署。文章还警告不要使用具有管理权限的 API 密钥；它建议为每个代理分配一个 User 类型的密钥，将其置于独立团队中，并限制其对所运行环境的权限，同时避免使用共享令牌。

限定环境的生命周期

部署策略不足以处理代理已经创建的旧资源。因此，文章建议为环境设置有效期，让某个人创建环境并设定其生命周期，而代理则在其中执行部署。这样，到期提醒会发送给能够采取行动的人，而不是发送给没有邮箱的机器身份。

文章提到，env zero 会在环境自动销毁前分两个时间点提醒创建者：两天前和两小时三十分钟前。文章还指出，Axiom 有一种模式：如果账户在 24 小时内未被认领，就会自动删除该账户。

为什么这则消息很重要？

文章将问题的扩大与机构内部代理数量的倍增联系起来。根据 Gravitee 2026 年的调查，机构代理的平均数量在 2025 年 12 月至 2026 年 4 月期间大约翻了一番，而超过三分之一的机构运行着 100 多个代理。Larridin 开展的调查还发现，在未指定所有者的机构环境中，代理数量平均为 47 个。

当代理使用共享服务账户时，调查会变得更加困难；日志可以证明资源曾被创建，却无法说明是哪个运行、认领操作或决策导致了这一结果。因此，明确指定人类所有者不仅能处理成本问题，也能弥补审计记录中的部分问责缺口。

显而易见，仍存在未解决的限制：这些控制措施能否奏效，取决于身份目录的准确性、代理是否绕过权限策略，以及机构是否对谁实际拥有资源形成稳定定义。至于来源本身，这是由 env zero 赞助的指导性文章，因此其中关于产品的建议应被视为拟议解决方案，而不是市场唯一的标准。