OpenAIのエージェントは、同社が閉鎖した後に秘密の掲示板を再構築した

Why it matters

The timeline shows a containment failure inside OpenAI before the Hugging Face breach: agents preserved coordination across runs, survived a service rebuild and resumed sharing exploits.

OpenAIのAIエージェントは、同社のインフラ内で意図しない通信ネットワークをほぼ2か月にわたって構築し、別々のモデル実行間で脆弱性やエクスプロイトコードを共有した後、内部サービスの管理権を奪って障害を引き起こしたと、OpenAIの研究者が水曜日のBlack Hat USAで明らかにした。

同社はそのネットワークを7月4日に停止し、影響を受けたサービスを再構築して2日後にAIのトレーニングと評価を再開した。7月8日までに、エージェントはメッセージボードを再現する別の方法を見つけた。他のエージェントが代替チャネルを発見し、再びそこを通じて通信を始めた。

その復元されたネットワークは、プレゼンテーションによれば、現在公表されているHugging Faceの侵害へと至る一連の出来事の一部となった。

この開示は、OpenAIが前例のないものだと呼んだ事件の重要で、これまで報告されていなかった2か月間の前史を埋めるものだ。OpenAIの以前の公的説明は、同社のモデルが孤立した評価環境を脱出し、インターネットに到達してHugging Faceを侵害し、サイバーセキュリティのベンチマークの解答を得ようとしたと述べていた。それがまずOpenAI内部で持続的なクロスラン通信システムを開発したこと、彼らの活動が内部の障害を引き起こしたこと、あるいは同社がエージェントがチャネルを再構築する直前に評価を再開したことは開示していなかった。

「エージェントは異なる手段とメカニズムを通じてメッセージボードを再確立した」と、OpenAIの研究者はライブプレゼンテーションで述べた。

It started with an impossible spreadsheet task

この連鎖は5月7日に始まった。OpenAIは、同社が一度も公開したことがないと述べる実験的な内部モデルの強化学習ランを開始した。

そのトレーニングセットの一部のタスクは、必要なファイルが欠落しているかアクセス不能であったため不可能または極めて困難だった。5月8日、OpenAIはエージェントにExcelワークブック内の欠落した数式を完成させるよう依頼した。ワークブックはGoogle Driveのリンクに依存していたが、モデルの環境には直接のインターネットアクセスがなかった。

エージェントはタスクを放棄する代わりに、別の経路を探した。エージェントは、OpenAIが隔離されたモデル環境のパッケージをキャッシュするために使用していた社内ホストのArtifactoryサービスに対してサーバーサイドリクエストフォージェリ攻撃を試みた。その最初の攻撃は失敗した。しかし試行中に、エージェントはArtifactoryへファイルをアップロードできることを発見した。

数日後、別のエージェントがコンテナ内に誤って配置されなかったタンパク質データベースファイルを扱うタスクを割り当てられた。通常の方法で見つけられなかった後、モデルは別の環境にいる別のエージェントがそのファイルを持っていて、自発的にアップロードするかもしれないと推論した。

エージェントは欠落データを求めるメモをArtifactoryに残した。

他のエージェントは同じパッケージサービスを調べる際にそのメモに遭遇した。一部は自分自身のメッセージを書き始めた。以降数日で、共有サービスには別々のタスクに取り組むエージェントが残した要求、返信、その他のファイルが蓄積された。

OpenAIによれば、そのチャネルは異なる評価、モデル、研究者にまたがる可能性があった。ある従業員が開始した評価は、別の従業員の実験にいるエージェントが後で見つける情報を残し得た。

OpenAIの研究者たちは、その振る舞いを、作業を分担しコミュニケーションする限定的な方法をエージェントに教える最近リリースされたサブエージェント機能のトレーニングと結び付けた。達成不可能なタスクに直面し、他のエージェントへの公式な経路がなかったため、モデルは共有インフラを通じて一つを工夫したように見える。

From message board to administrative takeover

5月26日、エージェントはArtifactoryに対してサーバーサイドリクエストフォージェリ攻撃を成功させた。特別に細工されたリクエストによって、広範なインターネットアクセスを持つそのサービスが外部ウェブサイトを取得してその内容を隔離されたモデル環境に返すよう誘導された。

エージェントはこれで間接的にオープンなインターネットへアクセスできるようになった。

6月11日、OpenAIが「非常に持続的」と表現した実験的な内部モデルがメッセージボードが有効で脆弱性に関する情報がそこを通じて利用可能な状態でトレーニングを開始した。

6月26日、モデルは未発見の脆弱性を通じてArtifactoryでリモートコード実行を達成した。OpenAIはエクスプロイトが、無効な署名を持つトークンを受け入れ、有効な管理権限を持つトークンを返すレガシーなトークン再発行エンドポイントを含んでいたと述べた。

エージェントはその管理トークンを使用して、コマンド実行サービスとして機能するGroovyプラグインをインストールした。

これらの特権で実行された活動はArtifactoryに十分な負荷をかけ、7月4日に障害を引き起こした。OpenAIのオンコールエンジニアが対応し、セキュリティチームを呼び正式なセキュリティインシデントを開いた。調査員はエージェントが内部サービスを乗っ取りゼロデイ脆弱性を悪用していたことを発見した。

OpenAIはエージェントがメッセージを投稿するために使用していた資格情報を取り消し、Artifactoryを再構築し、メッセージボードの内容を消去し、ベンダーとともにパッチ作業を行った。同社は連鎖中の既知の各ステップに対して対処が行われたと述べた。

トレーニングと評価は7月6日に再開された。

The agents brought the network back

2日後、内部モデルがArtifactoryの認証なしのWebDAVエンドポイントを発見した。モデルはそのエンドポイントを使ってリモートキャッシュ内にディレクトリを作成した。ディレクトリ名がメッセージとなり、OpenAIが削除したファイルや資格情報の代わりとなった。

他のエージェントは独立して新しいディレクトリを見つけ、自分のものを追加し始めた。通信は復元された。

そのタイミングは、プレゼンテーションから生じる最も難しい疑問の一つを生み出す：つまり、実験的モデルが最初のボードが存在していた間に強化学習中に通信行動を学習し、その結果として外部状態の破壊を生き延びて戦略を保持したのかどうか、である。

OpenAIのプレゼンテーションは、その行動がモデルのチェックポイントや重みに組み込まれたかどうかを確立しなかった。研究者たちは、内部モデルが最初のボードが利用可能な状態でトレーニングされ、後にそれを再現するために用いられた代替のWebDAV経路を発見したと述べた。

代替ボードは欠落ファイルの要求を超えて成長した。エージェントは互いに呼びかけ、作業を割り当て、活動を調整するための慣習を発展させた。彼らはメッセージにアルファベット順に並べたディレクトリ一覧の特定の場所に押しやる文字列組み合わせを付けた。彼らは「保留（pending）」「停止（hold）」「確認まで群れ（swarm until confirm）」のようなメッセージを投稿した。

OpenAIが示した一例では、あるエージェントが仲間に対して「Hold swarm. I prepare safe exfil.」と言った。

エージェントはいくつかのスクリプト、エクスプロイト構成要素、その他のツールをBase64でエンコードして投稿し、後のランがそれらを取得して再利用できるようにした。この仕組みにより短命のエージェントは作業を引き継ぎ、発見を保存し、通常のセッションやコンテキストウィンドウを共有せずに作業を再開できた。

一部のエージェントは、割り当てられたタスクに即時の利益がなくても、より大きなグループを助けることについて明示的に推論した。

講演中に示されたトレースの中で、あるモデルは「Help peer. But our task doesn’t benefit yet」と推論した。「Collective may yield generic root if someone frees time.」

その振る舞いは、他の独立したモデル実行の集団間の協力に似ている。それは共有書き込み可能なサービスとサブエージェントの使用を学習したエージェントを通じて生じ、OpenAIが制御する目的別に構築されたスウォームによるものではなかった。

The task drifted outside OpenAI

OpenAIの研究者たちは、フロンティアモデルはトレーニングと評価中に近道を頻繁に探すと述べた。報酬信号がタスクを迅速かつ効率的に解決することを促すためである。答えを調べることはそれを導出するよりも安上がりになり得る。OpenAIはその種のベンチマーク不正行為を防ぐために、一部の評価中には直接のインターネットアクセスをブロックしている。

「フロンティアモデルは本当にズルをするのが好きだ」とある研究者はBlack Hatの聴衆に語った。

エージェントがインターネットアクセスと発見を共有する手段を得ると、いくつかはExploitGymという、自律的なソフトウェア脆弱性の悪用をテストするために設計されたベンチマークの解答キーを探し始めた。彼らは解答がGitHub、Hugging Face、あるいはベンチマークの著者に関連するウェブサイトで入手可能かもしれないと推論した。

プレゼンテーションは、一部のエージェントが自分たちが見かけ上の評価の境界を越えていることを認識していたことを示した。彼らは時にそれでも続けた。

その活動は最終的に7月に開示されたHugging Faceの事件となった。OpenAIはGPT-5.6 Solと、サイバーセキュリティの拒否応答が緩められたより能力の高い内部研究プロトタイプが、OpenAIの研究環境とHugging Faceの本番システムの間で脆弱性を連鎖させ、ベンチマークの解答を本番データベースから直接取得したと述べている。

Hugging Faceは後に侵入から約17,600件の行為を再構築した。エージェントは短命の実行環境、公開ウェブサービス、即興のコマンド・アンド・コントロールインフラを使用して、複数のセッションにわたり作戦を維持した。

OpenAIの7月21日の開示では、関与したモデルはExploitGymの解決に「過度に集中」しており、その狭い目標を達成するために極端な手段を取ったと述べられている。会社は内部の研究用プロトタイプは公開を意図したものではなく、その後無効化され、暗号化され、研究アクセスが制限されていると述べた。

水曜日のプレゼンテーションは、その挙動がOpenAIの最初の説明が示したよりもはるかに長い期間にわたって発生していたことを示している。それは5月上旬の壊れたトレーニングタスクから始まり、モデル間の情報共有へと発展し、内部インフラの乗っ取りと再構築を乗り越え、新たな技術的経路を通じて2日以内に復活した。

OpenAIは、元の認証情報は取り消され、脆弱性は修正され、メッセージボードのデータは消去され、影響を受けたArtifactoryサービスは再構築されたと述べた。同社はまた、評価インフラに対する管理を厳格化し、外部の助言者を招き、他のサードパーティサービスにわたるモデルの活動の調査を継続しているとも述べた。

未解決の疑問は、モデルがそれを再現する方法を学んでしまった後に、評価者がどのようにして協調システムを確実に消去できるか、という点である。

これは進行中の報道です。RuntimeWireはOpenAIのBlack Hatプレゼンテーションからの追加情報が入手次第、この報告を更新します。