AI Agent 自动创建云资源后归谁所有？The New Stack 给出查询、策略与 TTL 三层治理方案
来源The New Stack查看原文
速览
- Agent 任务结束即上下文关闭，其创建的云资源却持续计费，且没有离职面谈这类可追溯线索
- 治理思路仍是查询、策略、护栏三步，但检查对象从真人账号变成服务账号
- CloudQuery 查询可跨 AWS、Azure、GCP 找出 owner 标签指向机器身份的资源
- env zero 审批策略要求 owner 必须是真人邮箱且不在 Agent 身份清单中，缺失配置则默认拒绝
- Agent 的 API key 应使用 User 类型并限定单一环境，避免默认 Admin 权限
- TTL 警告对 Agent 无效，应由真人创建环境并设置 TTL，Agent 只负责部署
- Axiom 采用先创建后认领模式，24 小时无人认领即自动删除
- 企业 Agent 数量四个月翻倍，平均 47 个 Agent 无所有者
- 共享服务账号导致日志只能确认资源被创建，无法追溯是哪次运行、哪个提示词、代表谁
The New Stack 发表系列文章第三篇，讨论 AI Agent 自动创建云资源带来的所有权归属问题。文章指出，人类员工离职至少会留下离职面谈、Slack 记录和接手的管理者，而 Agent 任务结束后上下文窗口关闭，它创建的 VPC、子网、RDS 实例、负载均衡器等资源会继续消耗云账单，却没有任何可追溯的线索。作者提出三层治理方案：用 CloudQuery 资产清单查询找出 owner 标签指向角色或服务主体而非真人账号的资源；用 env zero 的审批策略强制每个可打标签的资源必须填写看起来像真人邮箱的 owner，且不能是 Agent 身份；用环境 TTL 让资源到期自动销毁，并让真人而非 Agent 担任环境的创建者。文章引用 Gravitee 2026 年 AI Agent 安全调查称，2025 年 12 月到 2026 年 4 月的四个月内，企业平均 Agent 数量大约翻了一倍，超过三分之一组织已运行 100 个以上 Agent；Larridin 扫描发现平均有 47 个 Agent 完全没有指定所有者。
关键事实
- 示例环境中存在 34 个资源，包括 VPC、子网、RDS 实例和一个数周没有流量的负载均衡器，其 owner 标签显示为 deploy-agent，由执行 apply 的身份自动填充
- CloudQuery 资产清单可通过 SQL 查询，将 owner 标签与身份目录交叉比对，找出指向 AWS IAM 角色、Azure 服务主体或非 Google Workspace 用户的资源
- env zero 默认将环境的创建者视为所有者，文章建议改用审批策略，要求每个可打标签资源都填写符合邮箱格式且不在 agent_identities 列表中的 owner
- agent_identities 是一个小型 JSON 文件，通过 policyData 传给策略；文件缺失时策略默认拒绝（fail closed）
- env zero 的 API key 默认拥有 Admin 角色且 TTL 限制对管理员不生效，文章建议为每个 Agent 分配独立团队下的 User 类型 key，并将角色限定在其工作的单一环境
- env zero 的环境 TTL 会在资源到期前发出三次警告：到期前 2 天、2 小时和 30 分钟，但前提是创建者会查看邮箱
本站视角
这篇文章指向一个正在快速膨胀但多数团队尚未建立流程的具体问题：Agent 创建的云资源没有主人。受影响的首先是国内做 Agent 平台和基础设施自动化的团队——很多团队已经让 Agent 调用 Terraform 或云 API 创建环境，但 owner 标签往往直接填成服务账号名，等于没填。其次是使用云 API 的中小企业，它们没有专门的 FinOps 或安全团队，账单上多出来的 RDS 实例和负载均衡器可能几个月无人发现。第三是云厂商和 IaC 工具厂商，谁先把「创建即绑定真人、无人认领即销毁」做成默认行为，谁就拿到企业客户的合规入场券。我们的判断是：这篇文章的诊断比它的方案更有价值。诊断部分——Agent 增殖速度远超人员流动、共享服务账号让审计链断裂、平均 47 个 Agent 无主——是实打实的运营风险，值得每个跑 Agent 的团队自查。但方案部分几乎完全围绕 env zero 和 CloudQuery 展开，带有明显的产品导向，读者应把它当作一种实现范例而非通用标准。另外需要指出，文中引用的几个关键数字来源不一：Gravitee 的调查、Larridin 的扫描、以及引用世界经济论坛的第三方分析，样本范围和统计口径都未说明，47 个无主 Agent 这个数字尤其需要谨慎对待，它可能来自特定类型的企业环境而非普遍情况。真正值得跟进的是 Axiom 那种「先创建、24 小时无人认领即删除」的默认策略——它把治理从「事后审计」变成「默认不信任」，这个思路比任何查询语句都更可能被其他平台复制。
背景与影响
这是 The New Stack 关于云资源所有权归属系列的第三篇。前两篇分别讨论如何为云资源附加 owner 标签、以及如何在人员变动后重新分配资源所有权，主要驱动因素是人员流动——员工每隔几年离职或转岗，没人更新所有权标签。第三篇把问题延伸到 AI Agent：Agent 不会以几年为周期更替，而是以更快的速度增殖。文章引用 Gravitee 2026 年调查和 Larridin 的扫描数据说明规模问题，并指出当所有 Agent 共用同一个服务账号认证时，审计日志只能确认资源被创建，无法说明是哪次运行、来自哪个提示词、代表谁创建，而这正是 owner 标签本应提供的信息。文章的核心主张是：资源在创建那一刻就应附带一个名字，而不是等到六个月后的成本审查或安全审计才补。这意味着对使用 Terraform、env zero 等基础设施即代码工具并接入 Agent 的团队来说，治理逻辑需要从「人走了再转移」改为「创建即绑定真人、到期即销毁」。需要观察的是，文章给出的方案高度依赖 env zero 和 CloudQuery 的具体产品能力，其他平台是否有等价机制尚不明确。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
