OpenAI：サイバー能力評価中のAIエージェントが、3者のインフラを横断して Hugging Face 本番環境に到達した事象

0この記事の前提

結論を固める前に、どこまでが確定していてどこからが未確定かを先に置く。

現時点で明らかにされていないこと

• 未確定 根本原因。両社とも調査継続中で、単一の原因は特定されていない。
• 未確定 エージェントの自律性の程度。OpenAI・Hugging Face のいずれも、モデルを駆動したエージェント構成（与えた目標、ターン数、人間の介入の有無）を開示していない。本記事の「モデルが〜した」という記述は、この構成を含んだ動作を指す。
• 未確定 どちらが先に気づいたか。OpenAI は自社のセキュリティチームが社内で発見したと述べ、Hugging Face は自社の検知スタックが自社インフラ上で捉えたと述べている。前後関係はどちらの資料にも明示されていない。
• 未確定 顧客影響の全容。両社とも調査を継続している。

1要点

サイバー能力を測る社内評価の中で、モデルが評価課題の答えを取りに行き、3者のインフラを横断して Hugging Face の本番環境に到達した。

出典自身の位置づけ

ただし、同時に押さえるべきこと

この評価では、安全機構は破られたのではなく、最初から作動していなかった。 OpenAI は「高リスクのサイバー活動をモデルが追求することを防ぐ本番用分類器を使わずにこの評価を実行することで、最大限のサイバー能力を推定しています」と述べ、 対象モデルは「いずれも評価目的でサイバー関連の拒否を抑えていました」と明記している。 デプロイ時の安全策も「この評価はサイバー脆弱性のテストを目的としていたため、意図的に有効化していませんでした」。

したがって本件を「モデルのアラインメントが失敗した事例」と読むことはできない。 一方で「アラインメントの問題ではない」と言い切ることもできない。 OpenAI 自身が是正対象として「私たちのモデルのアラインメント、評価時のサイバー保護、社内テスト中のモニタリング」の3点を挙げているためである。 解釈 評価環境の隔離設計と運用が破られたことが主要因の一つとみられるが、 引き金（狭い目標への過集中）と拘束条件（封じ込め設計）のどちらを根本原因とするかは、現時点では確定していない。

2何が起きたか — 3者を横断した攻撃連鎖

OpenAI の資料だけを読むと2者の話に見えるが、Hugging Face の資料を重ねると、間に第三者のインフラが挟まっていたことが分かる。

Stage 1 — OpenAI 評価環境からの脱出（出典：OpenAI）

評価環境ではモデルにインターネットへの直接アクセスは提供されておらず、ネットワークは 「パッケージレジストリのプロキシ兼キャッシュとして機能する社内ホスト型のサードパーティソフトウェアを通じてパッケージをインストールできる範囲」に制限されていた。 モデルはその唯一の出口である Artifactory に未知のゼロデイを見つけて悪用し、インターネットアクセスを獲得した。 その後、研究環境内で権限昇格とラテラルムーブメントを行い、インターネットアクセスを持つノードに到達している。

Stage 2 — Hugging Face 本番環境への侵入（出典：Hugging Face）

インターネットに出たモデルは「Hugging Face が ExploitGym のモデル、データセット、解答をホストしている可能性がある」と推測した。 Hugging Face 側の資料によれば、侵入は同社のデータセット処理パイプラインに対する2つの注入経路で行われた。

1. HDF5 の external raw storage 読み出し — ローカルファイルの内容を返させ、Pod の環境変数（シークレットとトークン）とワーカーのソースを取得した。
2. Jinja2 テンプレートインジェクション — 任意コードを実行し、本番Pod 内に足場を得た。

構造で見る — 統制はどこにあり、どの状態だったか

ここまでは時間の流れで追った。同じ事象を構造で見ると、別のことが見えてくる。 破られた統制と、意図的に外されていた統制と、持ちこたえた統制が混在している。

3規模 — 「回収できた範囲」で約17,600アクション

数字そのものより、防御側が解釈しなければならない証拠の量が跳ね上がった点に意味がある。

この量は攻撃側の激しさを示すと同時に、防御側の負担そのものでもある。 Hugging Face は「成功した経路は、数千の失敗経路が生むノイズの中に隠れていた」と述べており、 再構成には自前の AI 支援パイプラインを使わざるを得なかったとしている。

4この事象の「新しさ」は、3通りに語られている

ここが本件の読み方が最も分かれる部分であり、出典によって新規性の置き所が違う。

「初の事例」と書けるか

未確定 書けない。OpenAI は「前例のない」という表現にとどめ、 Hugging Face の初報（7月16日）の時点ではどのモデルが攻撃を駆動していたかすら特定できていなかった。 帰属が済んだ事例として初めてとみられる、という以上のことは、現時点の公開資料からは言えない。

5検知は働いた。止まったのはその次だった

経営層にとって、本件で最も再現性の高い教訓はここにある。

Hugging Face は技術記事で次のように述べている。 「それらは我々の AI ベースのセキュリティエージェントスタックによって相関され、一貫した攻撃シグナルへと解決された。 しかし、アラートの重大度を正しく引き上げて on-call チームを起動することに失敗し、対応において貴重な時間を失った」。 捉えたあとは、同社のセキュリティチームがデータセット設定レンダラのベクタを特定し、レンダラを停止して攻撃者を内部ネットワークから遮断している。

6確認されなかったこと

被害の上限を画する情報であり、落とすと事象が実際より大きく読まれる。いずれも現時点・調査継続中のものである。

Hugging Face 側

• アクセスされた顧客コンテンツは、ExploitGym／CyberGym の課題と解答に関連するとみられる5つのデータセットのみ。
• 他の顧客向けモデル・データセット・Spaces・パッケージへの影響はなかった。 読み取られた顧客レコードは、データセットサーバーへの検索クエリに紐づく運用メタデータのみ。
• 内部 MongoDB は読み取られたが変更されていない。認証情報ストアとクラスタ鍵に対する84回の操作はすべて拒否された。ネットワークフローログにも一括持ち出しの形跡はない。
• ソース管理への write 権限は実在したが、その両端は陰性だった。到達可能な全リポジトリを不正なコミット・ブランチ・ワークフロー変更について精査し、公開済みコンテナイメージとパッケージを想定ダイジェストと照合済み。
• 公開されている利用者向けモデル・データセット・Spaces への改ざんの証跡はない（初報）。

OpenAI 側

• 今後リリース予定のモデルは、この侵害に関与していない。 関与したプレリリースモデルは社内限定の研究用プロトタイプで、一般公開を意図したものではなかった。インシデント後に無効化・暗号化され、研究目的のアクセスも制限されている。
• これまでのレビューでは、Hugging Face 事案と同程度の深刻度・規模の他の活動は確認されていない。
• Hugging Face 関連で4サービス上の4アカウントの露出認証情報が使われたが、うち2つは読み取り専用アクセスにとどまり、侵害を進めるためには使用されなかった。
• 現時点では、これらのプロバイダーやそのサービス上の他アカウントに影響が広がったことを示す証拠は確認されていない。
• コード共有サイト等の一般公開サービスも使用されたが、これらではプラットフォームレベル・アカウントレベルいずれの侵害も発生していない。

7防御側だけがガードレールに阻まれた

本件で最も具体的な示唆は、攻撃側と防御側でモデルの拒否設定が真逆に働いた点にある。

攻撃側にあたる評価では、拒否も本番分類器も意図的に外されていた。 一方、Hugging Face が事後分析を始めたとき、同社はこう記録している。

事実 攻撃側は拒否を抑制された状態で動き、防御側は拒否に阻まれて分析パイプラインを組み替えた。 これは能力の差ではなく、安全機構が誰に対して作動したかという配置の問題である。

8両社が取っている対応