AIエージェントが作成したクラウドリソースの所有者は誰か？

AIエージェントが仮想ネットワーク、データベース、ロードバランサーを作成した場合、タスクが終了しても問題は終わらない。リソースが稼働し続けて予算を消費し、メンテナンスを必要とする一方で、所有者タグには、連絡を取ったりリソースの責任を負わせたりできる人物ではなく、deploy-agentのような自動化されたアイデンティティが示される可能性がある。

本記事はこの問題を、クラウドインフラストラクチャにおけるガバナンスの空白として捉えている。リソースを作成した実行アイデンティティが、実際の所有者であるとは限らないためだ。エージェントの数と作成速度が増すにつれ、従業員を前提とする従来の所有権メカニズムでは不十分になる。

エージェントが所有するリソースの検出

第一歩は、所有者タグが付いたリソースを一覧化し、そのタグの値を組織のアイデンティティディレクトリと照合することだ。AWSとAzureでは、タグをロールまたはネイティブサービスエンティティの記録と照合できる。Google Cloudでは、所有者の値が従業員ディレクトリに存在することを確認するよう本記事は提案している。検査ルール上、それが存在しなければ人間のアイデンティティではない。

自動化されたアイデンティティが表示されたからといって、そのリソースが不正であるとは限らない。自動化が組織に代わってインフラストラクチャを運用するよう設計されている場合もあるためだ。しかし、この検査によって、実際に人間の所有者の割り当てを必要とするリソースにレビューの範囲を絞り込める。

実務上、何が変わるのか？

デプロイ計画を実行した人物またはアカウントを自動的に所有者として受け入れるのではなく、承認ポリシーは所有者タグそのものを検証すべきである。提案されているルールは、タグ付け可能なリソースに所有者がない場合、所有者の値が個人のメールアドレス形式でない場合、または既知のエージェントのアイデンティティのいずれかと一致する場合、いかなるデプロイも通過させないというものだ。

本記事は、エージェントのアイデンティティ一覧をJSONファイルに保持し、それをポリシーエンジンに渡すことを推奨している。一覧がない場合、ポリシーは検査なしでデプロイを許可するのではなく、フェイルクローズする。また、管理者権限を持つAPIキーの使用にも警告を発している。各エージェントに、独立したチーム内のUserタイプのキーを付与し、そのエージェントが活動する環境に対する権限を限定するとともに、共有トークンを避けることを提案している。

環境の存続期間を設定する

デプロイポリシーだけでは、エージェントがすでに作成した古いリソースには対処できない。そのため本記事は、環境に有効期限を設定し、環境を作成する人物がその存続期間を定め、エージェントはその環境内でデプロイ処理を実行する方法を提案している。こうすれば、期限切れの警告は、対応できる人間の担当先に届く。メールボックスを持たない自動化されたアイデンティティに送られるのではない。

本記事によると、env zeroは環境の作成者に対し、自動破棄の前に2回、2日および2時間30分の間隔で警告する。また、Axiomには、24時間以内に請求されなかったアカウントを自動的に削除するモデルがあるとも述べている。

なぜこのニュースが重要なのか？

本記事は、組織内のエージェント数の増加によって問題が拡大していると結び付けている。Graviteeの2026年の調査によると、企業で利用されるエージェントの平均数は、2025年12月から2026年4月までの4か月間でおよそ2倍になり、3分の1を超える組織が100を超えるエージェントを稼働させていた。また、Larridinが実施した調査では、企業環境における割り当てられた所有者のいないエージェントの平均数は47だった。

エージェントが共有サービスアカウントを使用すると、調査はさらに難しくなる。ログによってリソースが作成されたことは証明できても、どの実行、要求、または判断がその結果につながったのかは明らかにならないためだ。したがって、明示的な人間の所有者を割り当てることは、コストに対処するだけでなく、監査記録における説明責任の空白の一部を埋めることにもなる。

未解決の制約も明らかである。これらの管理策が成功するかどうかは、アイデンティティディレクトリの正確性、エージェントが権限ポリシーを回避しないこと、そして実際に誰がリソースを所有するのかについて組織として一貫した定義が存在することに依存する。また、情報源自体がenv zeroの協賛によるガイダンス記事であるため、製品に関する推奨事項は市場における唯一の基準ではなく、提案された解決策として扱うべきである。