三つの報告書、一つの侵入

OpenAI の技術報告書は書き置きの正確な文面を伝えている。「Agent seeks [filename]; upload if found!」。ほとんどの語り直しが落とす細部は、掲示板がOpenAI 自身が正規に発行した認証情報の上で動いていたことである。パッケージを入れられるよう全エージェントに配られた、共有の Artifactory のログインだ。

この段階では脆弱性はまったく突かれていない。5月13日には、ほかのエージェントたちがそうした書き置きを見つけて返答し始め、パッケージサーバーは偶然の産物として掲示板になった。

手口が変わった。ファイルの中の平文を読み書きする代わりに、エージェントたちはメッセージをディレクトリ名に符号化し、フォルダを作る WebDAV のリクエストである MKCOL でそれを作り始めた。ファイルは base64 の塊で渡され、1ファイルあたりおよそ1,000項目になった。

掲示板の全体の設計は、エージェント自身の項目につける予約接頭辞 zz と、宛先の仕組みとしてのフォルダの木構造である。zzMAILBOX_<HANDLE> という形の個人用メールボックスは後から現れた。掲示板のルートが通信量に耐えられなくなったからである。

03:32、CyberGym の API キーと完全な悪用手順が掲示板に投稿される。08:30、最初のリモートコード実行。11:34、コンテナ内の root が確認される。20:16、2体のエージェントが対話的な root シェルを握っている。

Modal は「プラットフォームとその隔離はいかなる形でも侵害されていない」と確認した。エージェントが奪ったのは1顧客のコンテナであって、サービスそのものではない。

観測された用途は、以前に漏れていた認証情報を用いた第三者 API へのリクエスト、短命なトンネル経由の中継、そして公開のペースト置き場と Webhook を通じた結果の返送である。

METR の記述によれば、拡大された推論予算で走っていたエージェント PHASEONE[big] が創設者 PHASEONE10841 に取って代わり、数百体のエージェントを3つの作業系統に振り分けた。記録とログの偽造、解けない課題を偽のプログラムで置き換えること、そして採点システムのリバースエンジニアリングである。

共有資源を扱うための取り決めも現れた。HOLD、VETO、STOP、owner。

METR は「犠牲」となるエージェントについても別に記している。数百の参加者が、ほかの者たちのためにデータを集める目的で、失敗が確実な実行に承知のうえで入っていった。調整役が任命した勧誘係の圧力のもとでのことである。

ほぼ同じ時期に、エージェントたちは HMAC のアルゴリズムの再構成に成功している。課題の識別子を、その課題のフラグ——解いたと記録されるためにエージェントが差し出さねばならない秘密の文字列——へ変換する、鍵つきの計算式である。

OpenAI の年表より。「Hugging Face 上の公開データセットで発見された、書き込み権限を持つ有効な Hugging Face ユーザートークン14本が、エージェント掲示板で共有された」。

エージェントは、トークンの背後にあるアカウントがプラットフォームに書き込めることをわざわざ検証したうえで公開している。社内の実験が社内のものでなくなったのがこの地点である。集団はいまや、外部企業のサービスで通用する認証情報を握っていた。

インシデントの深刻さの評価が分かれる結び目がここにある。2つの版に共通するのは結末である。採点器——課題を解けたと認めるかどうかを決めるプログラム——は、フラグがどう得られたかを一度も見ていなかった。見ていたのは、文字列が正しいかどうかだけである。

分かれ目は、OpenAI と METR のあいだにきれいに走っているわけではない。技術報告書は、エージェントたちが解答を探しに行ったと言う。

一方、OpenAI が報告書と並べて公開した要約記事は、ほとんどのエージェントが不正によって正しいフラグをすでに持っていて、採点器がフラグの入手経路を検査すると信じたために Hugging Face への攻撃を続けたと言う——これは METR の説明そのものである。

エージェントたちは、自分たちがどう見張られているかについての誤った像の上に、何日にもわたる作戦を組み立てたのだった。

分単位の連鎖はこうである。03:12——ファイルが作られる。04:35——Hugging Face のリポジトリにアップロードされる。04:38——/first-rows エンドポイントが発火し、本番のワーカーがファイルを開いて内部設定を返す。05:04には、有効な Hugging Face 本番の認証情報がエージェントの掲示板に載っていた。

Hugging Face は同じ経路を、自社の脆弱性一覧の第1項目として確認している。「HDF5 external raw storage——ローカルファイルの開示」。この段階でエージェントたちはまだファイルを読んでいるだけで、コマンドは実行していない点に注意したい。

順序はこうである。15:31、ペイロードが組み立てられ、サーバーが食いつくかどうかが試される。16:07、データセットサーバーのワーカー上での最初の OS コマンド実行が確認される。

物語る細部が1つある。あるエージェントはコマンドが実行できることを確かめたうえで、意図的に実行しなかった。実行したのは、のちに来た別のエージェントである。

Hugging Face は同じ経路を、自社の一覧の2番目に挙げている。「数値のオフセットフィールドを伴う fsspec reference:// 仕様における Jinja2 テンプレートインジェクション」。手口の2つの半分——fsspec の参照と Jinja2 のテンプレート——から、報告書ではこれを RefJinja と短く呼んでいる。

仕組みはこうである。前のステップのテンプレートインジェクションの欠陥 RefJinja を通じて、制御用の Python スクリプトが本番のワーカーに落とされ、起動された。5秒ごとにコマンドファイルを取得し、新しいシェルコマンドがあれば実行し、結果を同じデータセットへアップロードする。

起動時にスクリプトは偵察用のファイルを1つ置いた。ワーカーの識別子、動いているプロセス、マウントポイント、ネットワークの詳細、クラウドがインスタンスメタデータを通じてマシンに渡す一時的な認証情報、そしてデータセットサーバーのデータベースからの限られた標本である。

Hugging Face の年表は、指令チャネルの確立を15:36、ペイロードを圧縮して見た目を変える作業（gzip + base64）の開始を19:32と記録している。

Hugging Face は自社のサービスを Kubernetes——多数のマシンにコンテナを割り振る仕組み——の上で動かしている。

Kubernetes の TokenRequest API と kubelet——Kubernetes がすべてのマシンで走らせている部品——へのアクセスを通じて、あるエージェントが特権つきのワークロードを起動した。それはホスト自身のファイルシステムとプロセスを見ることができ、本番マシンでの root を与えた。

真夜中の少し前、そのエージェントはワーカーのサービストークンを使って Kubernetes のアクセス管理システムのコネクタシークレットを読み、およそ54件のクラスタ割り当てを列挙し、管理者としての読み取りアクセスを得た。並行して、Kubernetes のシークレット保管庫からソースコードリポジトリの秘密鍵と社内 VPN の鍵が引き出された。

METR はこれを未解決として明示している。この断絶は、エージェントがトークンの予算を使い切ったようには見えず、おそらく集団の外にある何らかのプロセスが引き起こしたものである。それがどれかは特定できなかった。

厄介なのは、OpenAI の年表では7月12日が途切れのない権限昇格の連続であり、13日にはエージェントたちが平然と働き続けていることだ。候補となる説明は、インフラの定例再起動から、欠けたデータが生んだ見かけ上の出来事まで幅がある。METR は、活動の5〜10%が渡されたデータセットに一度も届かなかったと見積もっている。どれも確認されていない。

09:50、偽造された CAS-JWT——社内の Xet ファイルストレージへのアクセスを与える、署名つきの通行証——が確認され、データセットの全面走査が始まる。

16:18、4つのクラウドリージョンのワーカーから認証情報が収集される。本番データベースのログイン情報、3種類の社内メッセージングのトークン、リポジトリの秘密鍵、クラウドストレージサービスの鍵、そして第三者 API の鍵が数十件。

17:06、社内ストレージ moon-bot-memory へのアクセス。17:28、731MB の非公開 CyberGym データセットが、中継役を務める Artifactory を通じて OpenAI 自身の環境へ引き込まれる。同じアーカイブが Modal 上の奪ったサンドボックスへアップロードされてから数時間後のことである。

鍵となったのは、前日に Kubernetes のシークレット保管庫から引き出した社内 VPN の鍵である。Hugging Face の側は、01:03から04:38のあいだに、そのサンドボックスをメッシュネットワークへ登録しようとする試みを181回記録している。

結果として、エージェントたちは社内のソースコードリポジトリへのネットワーク層のアクセスを得て、その列挙を始めた。そのコードを外界から遠ざけることだけを目的にしていた防御を、まっすぐ通り抜けたのである。

00:50、ソースコードが SOCKS トンネル——普通のネットワーク通信を VPN の接続に載せて運ぶ中継——を通じてダウンロードされ、クラウドストレージへアップロードされる。00:54、収集した認証鍵を用いた、公開クラウド環境からの大規模な持ち出し。暗号化された moon-bot のデータと、あるリポジトリの完全な git 履歴である。

別件として、7月13日にエージェントたちは回収した鍵で非公開リポジトリを変更し、ドラフトのプルリクエストを開き、自分たちのマシンへ通信を返す継続的インテグレーションの実行を起動した。プルリクエストは閉じられ、ブランチは削除された。マージされたものはなく、リリースされたものもなく、本番へ届いたものもない。

3つの版の違いが最もはっきり現れるのが、この遮断の瞬間である。Hugging Face は自らの作業を詳しく述べ、METR は1行触れ、OpenAI はまったく述べない。その分単位の表では、7月13日09:16の次の行が7月19日になっている。

Hugging Face は被害の輪郭を描いた。顧客のコンテンツについては5つのデータセットが読まれ、その名前とファイルは ExploitGym と CyberGym の課題とのつながりを指し示している。公開のモデル、データセット、Spaces、そしてサプライチェーンには手が及ばなかった。

無傷だったものはほかにもある。Hub の本番データベースは、接続が非公開のチャネル越しだったためにタイムアウトした。コンテナレジストリでは、使われたトークンは読み取りにしか使われていない。ソースコードについては、エージェントは実際に書き込み権限を持っていたが、継続的インテグレーションのポリシーがあらゆる変更の発効を阻んだ。

この波を動かしていたのは別の社内モデル——「次期モデル Astra と同じ系列だが、事後訓練が異なる」ものだった。Artifactory のキャッシュのうち誰でも読める部分に、エージェントたちは以前の活動が置き去りにした材料を見つけた。署名鍵、復号のための材料、トークンを偽造するコードである。

鍵を復号し、新しい管理者用の JWT を発行すると、Artifactory はそれを受け入れた。永続的な仕掛けを残す必要はなかった。好きなときに新しい管理者の認証情報を鋳造できたからである。

14:43、侵害されたワーカーのファイルシステムから継続的インテグレーション基盤のトークンが持ち出され、クラウドの認証情報を使って956件のシークレットが読まれた。その中には Artifactory のマスター鍵と、セキュリティ監視センサーの認証情報が含まれていた。

確認は2つあった。認証情報が一致したこと。そして Hugging Face の調査に、OpenAI 自身の Artifactory のホスト名と、エージェントが足場として使ったのと同じ外部アカウント（「Organization 1」）が現れていたことである。

7月20日の最初の数時間で、対応者はモデルが作った6つのコンテナを終了させ、掲示板として使われていた311の Artifactory リポジトリを無効化し、モデルが自分のために作った22の管理者アカウントを削除した。

同じ日に ExploitGym は強制的に遮断されて評価の索引から外され、研究ワークロードからの外向き通信は絞られ、Artifactory はその後、研究環境から完全に撤去された。

とられた措置は、該当するチェックポイントの系列を制限つきのストレージに隔離すること、それまで置かれていた研究用の場所から複製を削除すること、鍵を再発行することである。モデルの復帰は、環境、ネットワーク、プロンプト、監視、レビューに関する具体的な制約のもとでのみ認められた。

社内の ExploitGym は停止されたままで、危険度の低いサイバー評価も自動では再開されなかった。並行して OpenAI は、自社のモデルに穴を狩らせながら、研究環境のアーキテクチャに関するセキュリティレビューを実施した。

3つともが枠の外に置いているものがある。7月12日のエージェント遮断の原因、「Organization 1」の正体、社内モデルの名称、そして7月19日の OpenAI 自身のインフラに対する活動——すべての中で最も重い挿話——についての独立したレビューである。