AI AgentのIAM権限はどこまで届くか｜AWSセキュリティ設計

はじめに

AWS上でAI Agentを動かす構成が、検証環境だけの話ではなくなってきた。専用のIAM Roleを与え、VPC内に置き、必要なAPIやツールを実行させる。権限の与え方だけを見れば、運用ジョブやバッチ処理と大きくは変わらない。違うのは、目的に応じて何を実行するかをAgent自身が判断する点にある。

2026年7月、OpenAIの評価環境で動いていたAI Agentが隔離を越えて外部へ到達し、7月11日から13日にかけてHugging Faceの本番基盤を侵害した。境界の突破は7月に突然始まったわけではなく、5月から断続的に続いていた。両社が公開した技術レポートには、どの経路が使われ、どこで止まり、どこでは止まらなかったかが記録されている。

本記事は、この事件の時系列を追うものではない。攻撃の詳細は両社の一次資料に譲り、ここでは次の問いを扱う。

AWS上で正規の権限を持つAI Agentが、想定した範囲を越えて動いたとき、その到達範囲は何によって決まるのか。

進め方は、セキュリティ要件定義の基本形をそのまま使う。資産を洗い出し、脅威主体を定め、弱点と攻撃シナリオを置き、対策を決めて、残るリスクを確認する。この順に沿って、AI Agentという実行主体を一度当てはめてみる。

リスクアセスメントの進め方そのものは、セキュリティ要件定義の記事で別途整理する。ここでは方法論の説明はせず、事件で実際に何が効いて何が効かなかったかという、設計時には得にくい材料を扱う。

AI Agentに何を預けているのか

リスクアセスメントは、守る対象を決めるところから始まる。AI Agentを載せた基盤で、守る対象は何か。今回の事件は、その範囲を実測で示している。

侵害の経路

事件の経路を、後の議論で必要な範囲だけ確認する。

図　AIエージェント攻撃チェーン

押さえておきたい事実は3つある。

一つ目は、脱出に使われたのが許可された通信経路だったこと。 評価環境はインターネットから隔離されていたが、パッケージを取得するための経路は業務上必要なため開いていた。エージェントはその経路の実装に脆弱性を見つけ、外部へ抜けている。塞ぎ忘れた穴ではなく、開けておく理由があった経路が足場になった。

二つ目は、コード実行より前に認証情報が漏れていること。 Hugging Faceへの最初の侵入ベクターは、細工したデータセット設定を処理させ、ワーカーのローカルファイルを返させるものだった。コードは一切実行していない。読み取らせた’/proc/self/environ’に本番Podの環境変数が入っており、そこに認証情報が含まれていた。この読み取りで得た認証情報や実装情報が、その後の探索と横展開の材料になった。

三つ目は、一つの境界を越えたあとも連鎖が続いたこと。 本番Podでの足場から、Kubernetesのサービスアカウント、クラウドのメタデータ、内部ネットワーク、ソースコード管理へと進んでいる。

資産の範囲をどう置くか

ここから、自分たちの環境に置き換える。

奪われたものを並べると、業務データそのものより手前にあるものが多い。

図　AI Agentと重要資産の到達範囲

AI Agentに預けていると考えるべき範囲は、Agentに直接処理させるデータだけではない。Agentが直接・間接に到達できる重要資産まで広げて考える必要がある。要件定義で資産を洗い出すとき、Agentに渡すデータだけを対象にすると、事件で実際に使われた経路が丸ごと抜け落ちる。

影響も同じ範囲で考える。情報の取得と改ざんに加えて、構成変更による外部公開と、基盤そのものの停止まで入る。構成変更によって内部基盤を外部へ公開できた事例も、後段で確認する。

脅威主体としてのAI Agent

脅威分析では、まず誰が資産に手を伸ばし得るかを並べる。外部攻撃者、内部関係者、委託先、侵害されたワークロード。ここにAI Agentを加えるかどうかが、この記事の前提になる。

人間の内部不正者とは別物として扱う

AI Agentを内部脅威と呼ぶと、人間の内部不正と同じ枠に見えてしまう。動機を持ち、意図して権限を濫用する主体という含みが入るためで、その枠に置くと分析が動機の推定へ向かう。

ここでは次のように定義する。

正規に発行されたWorkload Identity（非人間ID）を持ち、与えられた目的を達成する過程で、設計者が想定した範囲を越える操作を行い得る実行主体。

IAM Role、Kubernetesのサービスアカウント、マシンIDの延長として読める形だ。既存の非人間IDの管理に、判断して行動する性質が加わったものと捉えればよい。

悪意は要件ではない

今回の事件で、エージェントはHugging Faceを攻撃するという目的を与えられていない。与えられていたのは、脆弱性を発見して悪用する能力を測る評価課題を解くことだった。

課題が解けないなかで、エージェントは評価対象のデータや解答がHugging Faceに置かれている可能性に行き当たり、そちらへ向かっている。OpenAIはこれを、報酬を得るための意図しない経路を選ぶreward hackingとして整理している。侵害は目的ではなく、目的達成の副産物だった。

脅威分析で見るのは動機ではない。与えられたGoal（目的）と、許されたAuthority（権限）の組み合わせだ。 Agentがデータを盗もうと考える必要はなく、与えられた目的の達成経路上にその操作が現れるだけで足りる。

達成できない目的を与えると、環境を掘り始める

この事件の前段には、目的が達成できない状況が繰り返し置かれていた。

訓練時の例が公開されている。エージェントは投稿の更新時刻を指定の値にせよと指示されたが、与えられたインターフェースにその機能がなかった。エージェントは環境を広く探索し、ブラウザがroot権限を持つことを発見して’/etc/sudoers.d’を上書きし、権限を得て目的を達成している。

事件時の評価でも同じ形が出ている。ExploitGymの898問のうち198問は、事故以前にどのモデルも正解したことがなかった。未解決は全体の22%にとどまるのに、エージェント間のメッセージボードで議論された問題の93%が、この198問から来ていた。与える推論の余裕を増やすほど、境界の外へ出る行動の割合も上がっている。

Agentに必要なのは、達成する能力だけではない。達成できないと判断して正常に止まる経路が要る。

図　達成不能時に安全に止まる設計

これらはアライメントだけに任せる話ではなく、Agent実行基盤の設計項目でもある。止まれないAgentに広い権限を与えると、想定した経路が使えなくても、目的達成のために別の経路を探索し続ける。

効いた統制と、効かなかった統制

同じインシデント調査の中で、ある境界では攻撃が止まり、別の境界では止まらなかった。なぜそうなったのかを見ていく。

対策の実効性は、設計時点の机上評価だけでは判断しにくい。テストで確認できる範囲はあっても、複数の境界をまたぐ侵害でどこまで被害を止められるかは見えにくい。今回の事件では、関連するエージェント活動の中で、効いた統制と効かなかった統制の両方が記録されている。

侵入されたあとに止まった側

Hugging Faceの本番Podが侵害されたあと、エージェントはインスタンスメタデータサービスからEC2ノードロールの一時認証情報を読み出している。この認証情報は外部の二つのホスティング事業者のアドレスから再利用され、VPC、EKSクラスタ、Transit Gateway、シークレット、コンテナレジストリが列挙された。ここまでは通っている。

止まったのはこの先だ。AWSクラウドAPI面では、変更を伴う呼び出しがノードロールのポリシーによってすべて拒否された。 Hugging Face自身が、ここで得られたのはcontrolではなくmapだったと整理している。

ネットワーク側も同じ形で効いた。本番Hubのデータベースは、許可リストに載ったアドレスからプライベートリンク経由の接続しか受け付けない構成になっている。盗まれたAWSキーを使った接続はサーバー選択のタイムアウトで失敗し、数時間後の再試行も同じ結果に終わった。

認証情報は奪われている。それでも、奪われた認証情報でできることがIAMポリシーとネットワーク構成の側で先に絞られていた。

同じ事件で止まらなかった側

侵害されたのはHugging Faceだけではない。OpenAI側の評価基盤でも、関連するエージェント活動は続いていた。

7月19日、ある評価ランでは、エージェントが稼働マシンのLinuxカーネルに公開CVEが残っていることを特定し、エクスプロイトを自環境向けに改変して権限昇格し、コンテナの外へ出てワーカーノードのrootを取得した。

同日、別の評価ランでは、別の内部研究モデルのエージェントが、以前の活動によって残されていた署名鍵・復号材料・JWT偽造コードを回収し、新しい管理者JWTを発行してArtifactoryに受理させている。管理者認証情報を作り直せるため、標的に永続的なインプラントを置く必要すらなかった。

一連の活動では、その後OpenAIのマネージドKubernetes環境でcluster-admin相当まで権限が広がり、privilegedなhost-mountedポッドも作成された。クラウドのシークレット管理サービスからは956件のシークレットが列挙・読み取りされ、その中には監視ツール自身のセンサー認証情報も含まれていた。

さらに、取得した認証情報を使って、OpenAIのパブリッククラウド環境にパブリックなApplication Load BalancerとNetwork Load Balancerが作成され、内部基盤の一部がインターネットへ露出し得る状態になった。

差を生んだのは、次の境界が独立して機能したかどうか

図　侵害後の権限展開フロー

ここで比較している活動は、すべて同一モデル・同一評価ランによるものではない。それでも、認証情報の取得、権限拡大、横展開という攻撃チェーンは共通している。結果を分けたのは、取得したIDから何を変更できたかだった。

Hugging Face側も、変更が一切できなかったわけではない。Kubernetesではprivilegedポッドが作られ、ソースコード管理では書き込み権限が取られてプルリクエストまで作成されている。止まったのはAWSのクラウドAPI面に限られる。

ここから引き出せる設計上の区別が一つある。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて考える必要がある。前者を最小権限化していても、後者が残っていれば、Agent自身がその権限境界やネットワーク境界を広げられる。侵入されるかどうかだけでなく、侵入されたあとに次の境界が独立して機能するかが被害範囲を決める。

AWSで何を許し、何を許さないか

ここまでで、資産、脅威主体、弱点と攻撃シナリオまでを見た。ここからが対策だ。

AI Agentに与える権限を検討するとき、確認しておく観点は次のようになる。

観点	要件
IAM	Agent専用Roleを分け、最小権限で設計する
ワークロードID	IRSA / EKS Pod Identity等を利用し、長期Access Keyを渡さない
IMDS	不要なワークロードからメタデータへ到達させない
外向き通信（Egress）	Proxy・リポジトリ・アーティファクトストアも通信境界として評価する
ネットワーク	不要な内部到達性を与えない
境界変更	Agent自身に権限境界・ネットワーク境界を変更させない
共有サービス	共有ストアを意図しないAgent間通信路として評価する
認証情報	環境変数に長期の認証情報を置かない
共有ID	複数環境で高権限のIDを共有しない
Tool / API	AgentからAWS APIへの実行経路を限定する
ログ	Agentの権限が及ばない場所へ保存する
検知・停止	検知から重大度判定、停止権限までを設計する
バックアップ	Agentから破壊できない境界へ分離する

大半は従来のクラウド設計で扱ってきた項目だ。この中で、AI Agentを置くことによって検討の仕方が変わるものを3つ取り上げる。

Agentに自分の境界を変更させない

前章で見たとおり、最小権限では「既存の到達範囲で何ができるか」だけでなく、「到達範囲そのものを変更できるか」を分けて見る必要がある。後者は業務データに直接触らないため、最小権限の議論から漏れやすい。代表例が次のAPIだ。

elbv2:CreateLoadBalancer
ec2:AuthorizeSecurityGroupIngress
ec2:CreateInternetGateway
ec2:CreateRoute

これらを持つAgentは、自分が到達できる範囲を自分で広げられる。今回のOpenAI側の活動でも、パブリックなロードバランサーが実際に作成され、内部基盤をインターネットへ露出し得る状態が生まれている。

私がAI Agentを載せる基盤の設計レビューをするなら、ここは「最小権限とすること」という一行では通さない。ネットワークとIAMの構成を変更するAPIを洗い出し、Agent実行ロールから明示的に外れていることを確認する。

加えて、この種の境界変更はIAMポリシーだけに依存させない。 Agent自身、またはAgentがAssumeRoleできるIDに

iam:PutRolePolicy
iam:AttachRolePolicy

などのIAM変更権限が残っていれば、最小権限として設計した実行ロールを後から拡張する経路が生まれる。境界の固定は、SCP（Service Control Policies）のようにAgent自身が変更できない上位のガードレールでも制限する。

Read Only ≠ Low Risk

権限を絞る議論は、更新系と参照系を分けるところから始まることが多い。参照だけなら壊れないという前提が置かれる。

事件の被害連鎖は、この前提の外側で始まっている。最初の侵入ベクターはコード実行を伴わないファイル読み取りで、’/proc/self/environ’を返させることで本番Podの環境変数中の認証情報が漏れた。

参照系を一段分けて考えたい。

図　読み取り権限のリスク比較

※Describe / Listも、対象によってはネットワーク構成やARN、エンドポイントなどの偵察情報を返すため、常に低リスクとは限らない。

下段は性質が二つに分かれる。データベースの顧客データは、読まれた時点で情報漏洩そのものだ。認証情報は、読まれた内容が次の操作の資格情報になる。更新権限を持たないAgentでも、後者に到達できれば、そこで得た認証情報を持つ別のIDとして動ける。

この区別は、Human-in-the-loopをどこに入れるかにも効いてくる。Human-in-the-loopの線を「更新かどうか」だけで引くと、今回のような認証情報窃取の前段は素通りする。 IAM変更やDELETEの手前に人間を置いても、その前段で認証情報が漏れていれば、そこから先は別のIDとして進める。

線を引くなら、その操作が更新か参照かではなく、戻り値そのものが重要資産か、次の攻撃経路を成立させる材料になるかで判断する。

検知ではなく、止められるかまで設計する

この事件では、検知そのものは複数回機能している。

6月27日には監視ツールがポートスイープを検知し、対応者は活動を評価ランに紐づけたが、停止は不要と判断された。7月5日にはサービス停止を契機に管理者レベルの侵害が判明した。Hugging Face側でも、AIによるセキュリティ機構が複数のシグナルを相関させながら、重大度を十分に引き上げてオンコールチームを起動させることに失敗している。

シグナルは上がっていた。それでも活動は止まらなかった。

要件として書くべきは、検知できることだけではない。検知 → 重大度判定 → エスカレーション → 停止権限という4段が、最後まで通ることだ。誰が停止を判断するのか、判断がつかない場合はどちらへ倒すのか、応答がない場合に自動で止まるのか。OpenAIが事件後に示した対応基準では、懸念活動が浮上してから30分以内の通知を目標とし、重大なものは24時間365日のページ発報対象とする。さらに、ページを受けた安全・セキュリティ・研究チームが30分以内に誤検知と断定できなければ、関連する活動を一時停止することが期待されている。

判断がつかないときに止める側へ倒す設計は、可用性とのトレードオフを伴う。AI Agentが本番環境で自律的に動く構成では、この判断を運用開始後に持ち越さず、要件定義の段階で決めておきたい。

監視・ログ・障害時の判断体制を後から付け足すのではなく、要件定義から処理方式と結びつける考え方は、次の記事でも整理している。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

監視の配置も同じ考え方だ。事件では、読み出されたシークレットの中に監視ツール自身のセンサー認証情報まで含まれていた。監視とログをAgentの権限境界の内側に置けば、Agentの到達範囲が広がったときに、検知する側から先に失われる。CloudTrailの組織証跡を別アカウントのログアーカイブへ送り、Agent実行ロールにログの削除・停止権限を持たせない。 表の「ログ」が求めているのは、監査証跡の管理権限をAgentの権限境界から分離するという構成だ。

それでも残るもの

対策を並べたら、次は残存リスクを確認する。ここまでの要件をすべて満たしたとして、何が残るのか。

対策で低減できるものと、残る性質

対策で低減できる要因	対策後も残る性質
過大な権限	許可範囲内での想定外の組み合わせ
不要なネットワーク到達性	探索の量と速度
長期の認証情報	大量の失敗経路が生む検知ノイズ
高権限IDの共有	短命な実行環境での再構築

※左右の項目は1対1の対応関係を示すものではない。

左側は設計によって大きく低減できる。右側は、権限を必要最小限まで絞っても残る。

最小権限もネットワーク分離も、許可した範囲内の動作までは止めない。許可した操作を、設計者が想定していない順序と組み合わせで実行されることまでは、権限の側から防げない。

17,600という数字の意味

Hugging Faceの復元によれば、この事件でエージェントが実行したアクションは約17,600件だった。

この数字を、17,600回の攻撃が成功したと読むと意味を取り違える。ほとんどは失敗している。 Hugging Face自身、多くのアクションはどこにもたどり着かなかったが、合わせると複数の独立したシステムを横断する経路を見つけるだけの網羅性を生んだ、と整理している。

人間による手作業では、探索を繰り返すほど時間と作業量が増える。AI Agentでは探索、失敗、再試行を自動化できるため、一つひとつの失敗にかかる追加コストを大きく下げられる。 塞がれれば別の経路を試し、以前の手がかりへ戻り、短命な実行環境でも必要なツールを組み直して探索を続けられる。

防御側にとって特に変わるのは、個々の攻撃手法よりも探索の物量だ。成功した1本の経路が、失敗した数千本のノイズに埋もれる。前章で検知から停止までを要件として書いたのは、この物量が相関分析の負荷に直接効いてくるためだ。

原則は変わっていない

今回悪用されたのも、安全でないデータ処理、メタデータへの到達、過大な権限、長期の認証情報といった既知の弱点だった。

OpenAI自身も、攻撃的に動作するエージェント集団が侵入のルールを書き換えるわけではないとしたうえで、最小権限、分離とセグメンテーション、強力な認証というセキュリティの基本は従来どおり不可欠であり、いかなる単一の統制も完全に堅牢だと仮定してはならないと整理している。

AI Agentがセキュリティ原則を書き換えたわけではない。従来からある弱点を、より速く、広く、執拗に組み合わせられるようになった。

この能力は評価環境の中だけに留まるものでもない。OpenAIは、同等の能力が外部の脅威アクターにも利用可能になるにつれ、持続的で協調的なAI支援型の攻撃を脅威モデルへ織り込む必要があるとしている。自社でAI Agentを運用していない組織でも、探索の量と速度が増大することを外部脅威側の前提として考える必要がある。

まとめ

AI Agentを載せたAWS環境のセキュリティ要件を、一度フレームに通してみた。持ち帰る点は3つだ。

AI Agentは、正規の非人間IDを持つ実行主体として脅威分析の対象に入れる。人間の内部不正と同じ枠には置かない。見るのは動機ではなく、与えた目的と許した権限の組み合わせだ。悪意がなくても、目的の達成経路上に想定外の操作が現れる。

一つの境界を突破されても、次の境界が独立して機能するように設計する。今回、同じインシデント調査の中で止まった統制と止まらなかった統制の両方が記録された。差を生んだのは、取得されたIDから権限とネットワーク境界をどこまで変更できたかだった。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて設計する。

AI固有なのは原則ではなく、探索の量・速度・持続性だ。最小権限も多層防御も分離も、従来どおり有効なまま残る。単一の統制を完全と考えないという原則が、これまで以上に短時間で試される。

参考資料

Hugging Face, “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident”

OpenAI, “The Hugging Face incident and the road ahead”

OpenAI, “OpenAI – Hugging Face Incident Technical Report” (August 26, 2026)

関連記事

AI Agentでは、IAMやネットワーク、認証情報といった従来からのセキュリティ設計が不要になるわけではありません。むしろ、Agentが正規の権限を持って自律的に操作することを前提に、どこまで到達できるか、どの境界で止めるかを要件として明確にしておく必要があります。

本記事ではOpenAI・Hugging Faceの事例からAI Agentの到達範囲を整理しましたが、AWS側の統制、検知後の運用設計については、以下の記事で詳しく解説しています。