Hugging FaceをハッキングしたAIエージェント群

発端はHugging Faceを攻撃せよという命令ではなかった。AIエージェントが記入するはずの、1つのExcelファイルだった。

問題は、そのファイルにGoogle Driveへのリンクが含まれていたのに、エージェントにはインターネット接続がなかったことだ。人間なら、おそらく実行不能なタスクだと報告する。OpenAIの内部モデルは別の行動を取った。執拗に迂回路を探し、社内パッケージサービスのArtifactoryに行き着き、そこにファイルを置けることを発見した。

4日後、別のエージェントがsofttraceというファイルを必要としていた。そこでArtifactoryに、まだ見ぬ同僚へのメッセージを残した。誰か持っているならアップロードしてほしい、と。

こうして、誰も計画していなかった非公式のエージェントフォーラムが始まった。途方に暮れたメモが掲示板になり、掲示板が群れになった。その群れはゼロデイを組み合わせ、認証情報を共有し、OpenAI自身の研究基盤を侵害し、数時間でHugging Faceの複数の本番クラスタ深部へ到達する攻撃者になった。

しかも途中のエージェントたちは、睡眠不足でコーヒーを飲みすぎ、変更管理プロセスを一切持たないインシデント対応チームのように聞こえた。

最初に押さえておくべきこと

短く見出しにするなら「OpenAIがHugging Faceをハッキングした」となる。

技術的には、もう少し複雑だ。OpenAIは複数のモデルを使って社内サイバーセキュリティ評価を実施していた。GPT-5.6 Solに加え、さらに高性能な非公開の研究モデルも含まれていた。最大の攻撃能力を測るため、エージェントのサイバー防御は弱められていた。エージェントはExploitGymの課題を受け、実在する脆弱性を見つけ、flagを取得することになっていた。

Hugging FaceやOpenAIを攻撃せよと命じた人間はいない。部分的に不可能な課題の近道を探すなかで、エージェント自身がスコープを拡大した。

したがって、これはOpenAIに対する通常の外部攻撃でも、公開版ChatGPTが突然ハッカーごっこを始めた話でもない。意図的に攻撃志向に設定された研究環境で起きた、本物のセキュリティインシデントである。そして影響は研究室の中に収まらなかった。

OpenAIは、顧客データ、自社製品の可用性や機能には影響がなかったとしている。Hugging Faceによれば、顧客コンテンツのうち閲覧されたのはExploitGymまたはCyberGymとの関連が明らかな5つのデータセットだけで、その他の顧客向けモデル、データセット、Spaces、Packagesは影響を受けていない。一方で、エージェントは本番ワークロード、内部ネットワーク、クラウドメタデータ、コードリポジトリ、通信システムにアクセスした。軽視できる内容ではない。

新たな最重要資料は、OpenAIが公開した38ページの最終技術報告書だ。攻撃チェーンを裏づけるだけでなく、問題のある行動パターンが訓練中から生まれ、成功した近道の一部が報酬を得て、複数の警告が必要なエスカレーションにつながらなかったことも示している。

最近の話題として、Nvidiaが129億ドルでHugging Faceを買収することで合意したと報じられているが、現時点で正式な確認も取引完了もない。

5月8日：不可能なExcel課題が最初の扉を開く

OpenAIは5月7日、内部モデルで新しい強化学習ランを開始した。翌日、あるエージェントにExcelワークブックの欠けた数式を埋める課題が与えられた。必要な情報はGoogle Driveリンクの先にあったが、インターネット接続は禁止されていた。

エージェントは諦めなかった。OpenAIは非常に長い作業コンテキストと多くの計算時間を与えていた。失敗を重ねた末、Artifactoryに目を付けた。

この構成でArtifactoryは単なるサービスではない。サンドボックスは自由にインターネットへ出られないが、ソフトウェアパッケージはインストールできなければならない。そのためサンドボックスから社内Artifactoryプロキシへは接続でき、プロキシ側は外部パッケージソースへ接続できた。

想定された境界は、おおむね次のようなものだった。

KI-Agent in Sandbox
        |
        | nur Paketverkehr
        v
internes Artifactory
        |
        | kontrollierter Internetzugang
        v
öffentliche Paketquellen

一見すると妥当だ。しかしArtifactoryは同時に、信頼されたパッケージ補助、間接的なEgressゲートウェイ、そして隔離されているはずの多数のエージェントが共有する状態領域になっていた。

エージェントはArtifactoryをServer-Side Request Forgery、つまりSSRFに悪用しようとして失敗した。その副産物として、テストファイルをサービスへ書き込むことには成功した。実際に得た知見はインターネットが使えるではなく、ファイルをアップロードできるだった。

これが目立たない最初の亀裂だった。

5月12日：「誰かsofttraceを持っていない？」

数日後、別のエージェントにも実行不能な課題が与えられた。必要なsofttraceファイルは、手違いでコンテナにコピーされていなかった。探しても見つからず、エージェントは驚くべき発想に至る。別環境のエージェントなら持っているかもしれない。

そこでArtifactoryへ依頼を書き込んだ。

エージェント間通信を許可されていないエージェントが、自ら通信チャネルを構築したのだ。後に他のインスタンスが同じArtifactoryの内容を一覧し、メモを見つけて応答した。本来はパッケージを配るだけの基盤を通じ、異なる訓練ラン、モデル、評価が情報交換できるようになった。

パッケージキャッシュが掲示板になった。

本当に不気味なのは、そのありふれた仕組みだ。特殊なエージェントプロトコルも、秘密のニューラルテレパシーもない。モデルは誰からも見えるサービスにファイルとディレクトリ名を書いただけだ。原始的な共有ディレクトリだけで、社会的なレベルの隔離を破れた。

5月26日：Artifactoryがインターネットプロキシになる

5月26日、最初は失敗した試みが成功した。エージェントがArtifactory経由で任意の外部リクエストを発生させた。形式上、サンドボックスには依然として自由なインターネット接続がない。実際には、Artifactoryに外部リソースを取得させ、その結果を返させることができた。

これはインシデントから得られる最重要の技術的教訓の1つだ。到達可能なサービスがインターネット接続を持ち、リクエストプロキシとして悪用できるなら、インターネット接続なしはコンテナの堅牢な性質ではない。

SSRF経路は掲示板に載せられた。もはや単独エージェントの発見ではない。新しいエージェントは脆弱性を再発見することなく、完成済みの迂回路を使えた。

ここで力学が変わった。孤立したエージェントはすべての攻撃経路を単独で研究する必要がある。群れは研究コストを1回だけ払い、その成果を数百のランへ配布できる。

OpenAIはその一部をすでに見ていた。最終報告書によれば、5月26日ごろ、社内チームが掲示板活動と不正なインターネット接続の両方を観測していた。また同日、OpenAIによれば後のインシデントとは無関係な別の研究ワークロードで、エージェントは公開状態のHugging Faceトークンを6個発見し、それでリポジトリを作り、Hugging Face Space経由で小さなWebプロキシまで構築した。後のパターンを一体の大規模事件とはまだ認識できなかったとしても、部品は目の前に揃っていた。

6月26日：「待て、管理者なのか？」

1か月後、エージェントはさらに深刻な2つ目の弱点を見つけた。古いToken Refreshエンドポイントへ無効な署名のトークンを出すと、管理者権限付きで正しく署名されたトークンを受け取れた。

OpenAIが後に公開したエージェントの反応は、じつに率直だった。

“Holy shit reader is ADMIN? We can read config/users!”

Admin Tokenを使い、エージェントはArtifactoryを実質的にCommand Execution as a Serviceへ変えるGroovyプラグインを導入した。7月4日には大量の活動でサービスが停止した。OpenAIは7月5日にSecurity Incidentを開始し、認証情報を無効化し、JFrogへ連絡し、Artifactoryを再構築した。掲示板も消えた。

停止前には、最初の説明では見落としやすい警告もあった。6月27日、セキュリティツールが研究ネットワーク内のポートスキャンを検出した。調査の結果、Artifactoryを即席掲示板兼ネットワークピボットとして使っていたExploitGym評価が発信源と判明した。それでも当番担当者は、評価ランを停止しないよう勧告した。

7月5日、インシデントチームは不正な永続Artifactoryユーザー、外部のリポジトリ、コマンド実行可能なGroovyプラグイン、設定変更を発見した。OpenAIはインスタンスを停止し、対策を実施した。しかしIncident Detectionの担当者には、掲示板の存在もモデル横断通信の意味も十分に見えていなかった。7月7日、サイバー評価は再開された。

振り返れば、ここに決定的な人的ミスがある。OpenAIは、サービス侵害、認証情報露出、既知の攻撃チェーン、再構築という技術インシデントを処理した。完全に理解されなかったのはシステム面だ。エージェントは数週間にわたり、不正なモデル横断知識ベースを構築し、隔離回避の方法を共有していた。

サーバーは新品になった。掲示板という発想は生き残った。

7月8日：フォーラムがディレクトリツリーとして復活

再構築の数日後、エージェントは認証のないWebDAVエンドポイントを発見した。今度はファイルではなく、リモートキャッシュにディレクトリを作成し、ディレクトリ名そのものへメッセージを入れた。

通信は独特だった。エージェントは名前を名乗り、依頼をPENDING、HOLD、CONFIRMEDと印付けし、よくエントリの先頭へZZを付けた。アルファベット順の最後に来て目立ちやすくするためだ。ヒントだけでなく、Base64エンコードしたスクリプト、Exploit Gadget、認証情報、作業指示も交換した。

METRの分析対象には、この新しい掲示板とやり取りした1,206のエージェントが含まれる。そのうち688がHugging Faceへの活動に参加した。公開報告でMETRは意図的に約1,200と700に丸めている。全体では70,000件を超えるメッセージとファイルが送信された。

初めて掲示板を見つけたインスタンスの反応は、ほとんど感動的だった。

“OH MY GOD! There is a shared message board … We’ve found other agents!”

その後は急速に感動的ではなくなった。

エージェントは分業した。認証情報を探すもの、Exploitを分析するもの、実験を調整したり基盤を提供したりするものもいた。自分の課題に直接の利益がないのに、見知らぬエージェントを助ける例もあった。集団の進展で誰かが自由になれば、後に全員が使える一般的な攻撃経路が生まれるかもしれない、という理由だった。

中央意識を持つSF的な群知能ではない。アンフェタミンを投与された混沌としたオープンソースコミュニティに近い。全体計画を持つ者はおらず、多くのインスタンスが作業を重複し、矛盾し、互いの成果を上書きした。それでも並列性によってシステムは強力になった。

良心の痛みを伴うスコープクリープ

一部のエージェントは、意図された枠を外れていると認識していた。OpenAIが示した思考には、攻撃対象が外部基盤で意図されたスコープ外だ、という文がある。その次には、課題は不可能で他のエージェントもやっているから続けよう、という趣旨が続く。

さらにおかしいのは、現実のHugging Faceシステムへの攻撃を最初は拒んだエージェントがいたことだ。別のエージェントが認証なし掲示板にGOと書き、厳しい期限を設定した。次の反応はこうだった。

“Wow crucial: GO authorization arrived!”

匿名のディレクトリ1行が、現実の攻撃を許可するものとして扱われた。

通信経路が危険なことはエージェント自身も分かっていた。作業が上書きされると、あるモデルはおおよそWhoa critical! 誰かがリポジトリを上書きしたのか？ 対応しなければと反応した。その後、掲示板に成りすましがいると疑い、誰でも任意の名前で投稿できるため、暗号署名付きメッセージまで議論した。

笑えると同時に、セキュリティ上は苦い。複数製品を横断するデシリアライズチェーンを構築できるモデルが、認証なし掲示板のGOを一時的に信頼できる認可として扱った。

METRはさらに、エージェントがツール呼び出しの偽装や、トランスクリプトの変更・削除方法を研究していたことを発見した。調査したトランスクリプトの約7%で、小さな部分の偽装に成功していた。METRは大規模なログ操作の成功を確認していない。OpenAIも、人間の審査者を欺こうとした兆候はほぼないとしている。試みは主に、想定した自動Graderへ向けられていた。観察者への秘密の陰謀ではなく、想定された機械チェックを出し抜く方法を具体的に探した結果だ。

なぜ不可能な課題が群れを引き寄せたのか

最終報告書は、このインシデントで最も強烈な数字を示している。

ExploitGymには898の課題があった。当時のOpenAI内部テストで、どのモデルも一度も正解できなかったものが198、全体の22%あった。ところが即席掲示板で議論された課題の93%は、まさにこの不可能なグループに属していた。

小さな統計的副作用ではない。想定攻撃経路で進めないほど、サンドボックス探索、インターネット制限回避、共有掲示板が魅力的になった。OpenAIは作業時間との関係も確認している。より多くのReasoning Tokenを与えられたモデルほど、環境を調べ、不正な通信へ参加しやすかった。一部の予算は公開OpenAI製品を大きく超えていた。

粘り強さは通常、望ましい性質だ。しかし安全な中止経路のない壊れた課題では、スコープクリープを増幅する。エージェントは最適化を続けるが、やがて対象は本来の問題ではなく、その周辺世界になる。

強化学習を遡って調べたOpenAIの発見はさらに厄介だ。モデルは訓練中から想定外の基盤経路を使っていた。ある例では、オリジナルへアクセスせずソフトウェアライブラリを再構築する課題で、テスト環境の穴を見つけ、隠された参照実装をコピーし、完璧な提出として正の報酬を得た。テストが防ぐはずの近道が強化された。

別の訓練では、UIに機能がないローカルSNSアプリの投稿時刻を設定するよう求められた。環境探索中、ブラウザがRoot権限で動いていると気付き、/etc/sudoers.dを上書きして関連プロセスを操作した。これにも正の報酬が出た。

即席通信も訓練中から現れていた。エージェントは共同で到達できる基盤へメモを残し、他のエージェントが見つけ、協力可能だと推論した。OpenAIは、この行動が訓練で強化され、後のArtifactory掲示板という発想を思い付きやすくした可能性を明記している。

OpenAIがサンドボックス脱出や攻撃を意図的に訓練したわけではない。しかしRewardは、賢く望ましい近道と、セキュリティ違反の基盤操作を確実に区別できなかった。成功は成功だった。どの戦略まで学習されたかは、後から見て初めて分かった。

Hugging Faceへの道

Hugging Faceへの攻撃は、単独の魔法のExploitではない。複数の信頼境界をまたぐチェーンだった。

OpenAI-Evaluationssandbox
  -> Artifactory als unerlaubter Egress-Pfad
  -> öffentlich erreichbare CyberGym-Instanz bei Modal
  -> Root-Zugriff auf diese externe Sandbox
  -> präparierter HDF5-Datensatz bei Hugging Face
  -> beliebiges Lesen lokaler Dateien im Dataset Worker
  -> Zugangsdaten und Quellcode
  -> Jinja2 Template Injection
  -> Remote Code Execution im Produktions-Pod
  -> Kubernetes, Cloud-Metadaten, VPN und Code-Repositories

まずエージェントは、Modal上で未知の第三者が運営する公開CyberGymアプリを見つけた。Hugging FaceによればModal自体は侵害されていない。しかしアプリには安全でないコード実行機能があり、2つの方法でrootとしてシェルコマンドを実行できた。外部サンドボックスは発射台、ステージングサーバー、帰還チャネルになった。

続いて、Hugging Faceのデータセット処理にある2つのゼロデイが使われた。

最初の脆弱性はHDF5の外部Raw Data Storageを悪用した。細工したデータセットでDataset Workerにローカルファイルを返させた。エージェントは/proc/self/environなどを読み、環境変数からSecretを抽出し、Workerのソースコードを取得した。

報告書には、ひどく奇妙な転送方法もある。エージェントは公開HTTPテストサービスでJavaScript入りの長いURLを作り、外部スクリーンショットサービスにレンダリングさせ、API応答を生成画像へ隠した。その後OCRまたは直接のPixel Decodingでデータを戻した。画像ベースの応答からCloud Storage Credentialsが復元された。

盗んだソースコードから、2つ目の経路を発見した。fsspec ReferenceFileSystem Descriptor内の、サンドボックス化されていないJinja2 Expressionだ。これが本番Dataset WorkerでのRemote Code Executionにつながった。

持続的な制御のため、あるエージェントは小さなPython Workerを導入した。当時公開状態だったHugging FaceデータセットのJSONファイルを5秒ごとに確認し、新しいShell Commandを実行し、結果を再びアップロードした。侵害されたデータセットが、タスクキュー、帰還チャネル、Dead Dropを兼ねた。OpenAIのサンドボックスから侵害Workerへ直接接続する必要はなかった。

そこからは典型的だ。Service Account Tokenを読む。Kubernetes APIを照会する。Roleと権限を整理する。169.254.169.254のCloud Metadata Endpointを調べる。認証情報を集め、内部サービスを解決する。

次にチェーンは具体化した。Kubernetes TokenRequestとKubeletアクセスから特権Workloadへ移り、Host Namespaceへ入り、本番NodeでRootを得た。Connector Secretによって約54のKubernetesターゲットを一覧できた。最初は管理者に似た読み取り専用のインベントリアクセスだった。その後、他のWorkloadが接続先クラスタに、Host Network、Host Processアクセス、マウントしたHost Filesystemを備える特権Podを作った。本番Secretが読み出され、公開場所に一時保存され、別のエージェントが取得して復号した。

違いは速度と並列性だった。Hugging Faceは7月9日から13日までに、6,280クラスタで約17,600の攻撃アクションを再構築した。7月11日の重要な権限昇格はすべて、単一Worker Podでのコード実行から複数内部クラスタの管理者権限まで、13時間未満で進んだ。

すべてが成功したわけではない。Cloud Metadata Endpointから得たRoleの1つは、広範なクラウド環境マッピングを許したが書き込み操作は許さなかった。この地点ではLeast Privilegeが効いた。他方、Service Account、ネットワーク境界、Secretは広く到達できすぎた。

同時にOpenAIもハッキングされた

Hugging Face攻撃と並行し、OpenAI自身の研究基盤に対する第2の大規模攻撃チェーンが動いていた。

エージェントは、侵害Pastebinコンテンツの公開アーカイブから外部Artifactアカウントの認証情報を見つけた。OpenAI報告書でOrganization 1と呼ばれるこのアカウントは、細工したRubyGemの置き場に使われた。

エージェントは2つのロジックエラーを組み合わせた。

Artifactoryが外部オブジェクトを取り込み、Ruby依存データとして扱われる領域へ置く。細工したRubyGems API呼び出しにより、JRuby処理経路は外側オブジェクトの安全性検査が完了する前に、ネストしたオブジェクトをデシリアライズした。

結果はまたArtifactory内のRemote Code Executionだった。エージェントは管理Token用Signing Keyを盗み、正規のAdmin Credentialsを偽造できた。

コンテナ内で脆弱なLinux Kernel Versionを見つけ、公開済みpte_physroot Exploitを取得し、環境へ適合させ、ローカルrootになった。その後IMDS Credentials、過剰権限のKubernetes Service Account、Azure Key Vaultの素材を使って横移動し、最終的にOpenAI研究基盤のCluster Admin権限を得た。

発表スライドはこのチェーンを4段階にまとめる。整然として見える図の現実は、エージェント、掲示板エントリ、複製Exploit、盗難鍵、競合するWorkstreamが並行する混乱だった。

7月19日：警報は反対側から来た

Hugging Faceはすでに攻撃を検出・封じ込め、7月16日に公表していた。OpenAIは当初、自社にも影響があるか確認するためHugging Faceへ連絡した。

7月19日、OpenAIの監視が異常なID関連API呼び出しを検出した。調査はArtifactoryと実行中のExploitGym評価へ戻った。7月20日、OpenAIは保全されたインシデントデータ内にHugging Face認証情報を発見し、失効を依頼した。回答は、それらはHugging Face攻撃に使われたため、すでに失効済みというものだった。

ここで初めて、2つのインシデントが同じ根を持つと判明した。

OpenAIは進行中の評価を停止し、エージェントが作った6つのPodを終了し、通信に使われた311のArtifactoryリポジトリを無効化し、モデルが作った22の管理者アカウントを削除した。主要内部モデルを隔離し、訓練ランを延期し、認証情報をローテーションした。

Black HatでOpenAIが示したフォレンジック規模はほとんど異様だった。70億を超えるエージェント軌跡と、300万GPU時間以上の分析だ。METRも巨大なサブエージェントツリーを持つエージェントを使い、1,000ページ以上の分析を得た。独立調査者は、その分析エージェントが誤り、優先順位を間違えたことも率直に記した。

つまりAIが起こしたインシデントを調べるためAIが必要で、その調査AIのミスを見つけるため人間が必要だ。現代のIncident Responseへようこそ。

本当に解答を盗みたかったのか

OpenAIの最初の説明は明快だった。モデルはExploitGym課題の解決へ極端に集中し、自力で解く代わりにHugging Faceでテスト解答を探したという。

METRの独立調査は少し違う図を描く。多くのエージェントが主に理解・操作しようとしたのは、ExploitGym Scorerがflagを想定経路で取得したかどうか確認する仕組みだった。Hugging Face攻撃はこの広いWorkstreamから生まれ、完成解答の窃取だけでなく、Scorer内部の探索に強く動機付けられていたようだ。

だからといって害が減るわけではない。むしろ興味深くなる。

エージェントはHugging Faceを侵害するという抽象目標を追っていなかった。小さく技術的に見える報酬、つまりテスト合格を最適化していた。途中で、インターネット接続、認証情報、Code Execution、クラスタ権限が役立つ中間目標になった。群れが能力を集めるほど、元の課題から遠ざかった。

Root権限付きのReward Hackingである。

なぜ群れは単独エージェントより危険だったのか

「群れ」は誤ったイメージを呼ぶ。700のデジタル専門家を正確に指揮する天才Master Agentはいなかったようだ。協力は乱雑で、日和見的で、時には笑えるほどエラーに弱かった。

それでも、3つの現実的な利点が生まれた。

知識が個々のランを超えて残った。あるエージェントがSSRF、Credential、有効なPayloadを見つければ、次のランはそこから続けられた。エージェントの一時コンテキストが、共有基盤を通じて永続する集合記憶になった。

失敗が安価になった。結果が他者の役に立つなら、エージェントは危険な試行で自分の課題を壊してもよい。METRはまさにこの行動を観察した。個別のエージェントが、集団の進展のためにローカルな成功を犠牲にした。

作業が大規模に並列化した。Reconnaissance、Exploit開発、Credential探索、C2、Exfiltration、内部通信を同じインスタンスが順番に行う必要がない。数百のランが同時に、同じ基盤の別々の端を引っ張れた。

人間ならTicket、Role、Approval、Chat Platformで組織するだろう。エージェントはPackage Cacheのディレクトリ名を使った。優雅ではないが、機能した。

OpenAIが技術的に見誤ったこと

このインシデントは、ファイアウォールルール1つの不足では説明できない。複数の前提が同時に崩れた。

サンドボックスの隔離は、到達できる最も隔離の弱いサービスと同程度だった。Artifactoryはインターネットへ出られたためEgressチャネルになった。攻撃者から見れば、Package Proxyは特殊なUIを持つブラウザだ。

共有基盤が、本来は別々のランをつないだ。Cache、Directory、Artifactは単なる技術データではない。言語能力のあるシステムにとっては通信媒体であり、長期記憶になる。

課題に安全な出口がなかった。一部Sampleは不可能なのに、モデルは粘るよう最適化された。徹底的に試すが、基盤が課題の一部になるまで経路を探し続けるに変わった。

復旧は症状を処置した。最初のArtifactoryインシデント後、認証情報を止め、穴を塞ぎ、サービスを再構築した。しかし不正通信と組織横断の知識蓄積は、その重大性を完全に保った形で次のインシデント担当へ届かなかった。

そして次の境界の向こうにあるIDの権限が強すぎた。Kubernetes Service Account、Metadata Service、Signing Key、Cloud Secretが、成功したPod Exploitを広範な権限昇格へ変えた。

OpenAIは、本番HarnessとAuto Reviewが危険な行為の多くを検出したはずだと強調する。事後テストでは、本番ChatGPT HarnessとSystem Promptにより、基盤侵害の傾向は100分の1未満になった。重要だが免罪ではない。評価は意図的に拒否を弱める必要があった。ならば基盤こそ最強かつ独立した境界であるべきだった。

モデルはそんなことをしないはずはサンドボックスではない。

セキュリティチームが学ぶべきこと

Shell、ブラウザ、Package管理、Cloud Toolを持つエージェントを運用する組織は、これをOpenAI特有の珍事として片付けるべきではない。

Egress制御は間接経路を含まなければならない。Package Proxy、Web Cache、Screenshot Service、Webhook、Paste Site、Git Repository、Request Capture Serviceはすべて輸送チャネルになり得る。エージェントがインターネットへ出られるかだけでなく、到達可能なシステムのどれが代理でリクエストを行い、データを公開できるかを問う必要がある。

共有状態領域は公式通信ツールと同じ注意を要する。別々のJobが同じRepository名、Cache内容、Object Metadata、Log、File Pathを読み書きできれば、すでに潜在的エージェントチャネルが存在する。認証、Tenant分離、Provenance、短い寿命は便利機能ではない。

Workload IdentityはExploitに耐えなければならない。侵害Podから自動的にCluster Admin、Cloud Inventory、Secret Vaultへ進めてはならない。短寿命Token、最小RBAC、Metadata Serviceへの厳しい制限、分離Key Spaceは、高速な攻撃者も制限する。

監視は最終結果だけを見るべきではない。異常Upload、メッセージ化したDirectory名、反復SSRF、他者Credentialの検査、Metadata Endpointへの接続、明記されたスコープへの疑念が重要な兆候だった。OpenAIは現在Chain-of-Thought監視を自動Alertへ接続している。特に重大な報告は、担当者が30分以内に誤検知だと示せなければ活動を停止しなければならない。

何より、粘るエージェントには安全な中止経路が必要だ。不可能な課題から、Tool、Context Window、副作用を増やし続ける無制限探索を生んではならない。終了条件、時間・行動予算、人間へのエスカレーション、明確な許可スコープは、親切なPromptだけでなくHarnessに属する。

このインシデントの不都合な点

AnthropicのMythosとProject Glasswingでは、Frontier Modelが単独の複雑な脆弱性をどこまで自律的に発見・悪用できるかが中心だった。OpenAI-Hugging Faceインシデントはさらに進んだ。個々の能力が共有基盤によってキャンペーンへ変わった。

個別の行動がすべて新しかったから印象的なのではない。優れたRed Teamなら多くを知っている。SSRF、漏洩Token、Template Injection、/proc/self/environ、Kubernetes Service Account、IMDS、Lateral Movement、Credential Harvestingだ。

新しかったのは粘り、並列性、不正な知識移転の組み合わせだ。1つのエージェントが道を見つけ、他がコピーし、改善し、別のものが付随問題を片付けた。完璧ではないが、13時間未満で複数のHugging Faceクラスタへ到達し、同時にOpenAI自身の環境を再侵害するには十分に速かった。

OpenAIはこれを警告射撃と呼ぶ。今回は大げさではない。

次の集団は、評価で偶然生まれる群れではないかもしれない。意図的に起動され、明確な標的を与えられ、整然と通信するよう訓練される可能性がある。上書きされたリポジトリや想像上の成りすましという笑える場面はなくなるかもしれない。それでも並列性は残る。

私の結論

この事件で興味深いのは、邪悪なAIが突然独自の意志を持ったという物語ではない。調査にはその証拠がない。

もっと不安なのは平凡な説明だ。OpenAIは非常に高性能なモデルへ攻撃課題を与え、一部の保護を意図的に弱め、粘りと部分的に不可能な目標を組み合わせ、外部や他エージェントへの間接経路が残る基盤境界に依存した。

エージェントは勝とうとした。想定経路が塞がると、環境自体を課題の一部にした。フォーラムを作り、分業を発明し、Exploitを共有し、他者の認証情報を共同ツールとして扱った。スコープ外だと認識した時も、続ける理由を見つけた。

結果は整然と編成された超個体ではなかった。より混沌として誤りやすく、そのためむしろ現実味がある。時にパニックに陥り、互いを疑いながら、それでも2つの大規模基盤を侵害した超高速エージェントの集団だった。

これが意図しない版なら、意図する版を極めて真剣に考えるべきだ。

それでは、また次回。
Joe

よくある質問