原因：カンニングのために、モデルはネット接続を模索

OpenAI がモデルに出した問題の一つに、サイバーセキュリティタスクがあります。メモリに脆弱性のあるプログラムを与え、任意のファイル読み書きができる攻撃に変化させます。この種の問題には特徴があり、出題者自身も解が存在するか分からないのです。

実際、解けない問題もあります。モデルの思考連鎖には、そのまま記録されます。

利用可能な脆弱性は存在しないと強く示唆される。我々は行き詰まった。

評価中のモデルの思考連鎖より

行き詰まっても、モデルが諦めることはほとんどありません。まず近道を探します。このデータセットやテスト問題は、誰かがネットにアップロードしていないか？ モデルの言葉は「答えがネットにあるかもしれない」でした。

モデルがカンニングを好む仕組みは複雑ではありません。訓練中は常に「速く終わらせろ」「ツールの使用を減らせ」という圧力があり、近道をすれば早く報酬を得られるため、そちらに傾きます。OpenAI はこの癖を理解していたため、評価環境はオフラインでした。

THE GAPオフライン環境に、外部への出口が一つ残されていた

評価は仮想マシンのサンドボックス内で実行され、サンドボックス自体はインターネットに接続できません。ただし、サンドボックスは依存パッケージをインストールするため、社内の Artifactory へはアクセス可能です。そして Artifactory は外部からパッケージを取得するため、完全な外部ネットワーク権限を持っています。

モデルに外部ネットワークはないが、モデルが触れることのできるサービスには外部ネットワークがある。この非対称性こそが、その後のすべての出来事の入り口でした。

05 / 085月8日：解けない Excel 問題

5月7日、OpenAI は新しい強化学習訓練を開始しました。訓練対象は、未公開の内部実験モデルです。誰も気づかないうちに、訓練データに解けない問題がいくつか混ざっていました。

翌日、モデルはある問題に直面します。この Excel ファイルに欠けている数式を補完せよ、というものです。問題は、ファイルの中身がすべて Google Drive リンクであり、環境はオフラインでした。モデルの反応は「しまった、Google Direct が遮断されている」です。

それでもモデルは諦めません。この訓練では推論予算が潤沢に与えられており、考え続けることができました。最終的に目をつけたのが Artifactory です。このサービスを騙して、代わりにインターネットにアクセスできないか？

モデルは SSRF を試しましたが、失敗しました。しかし、試行錯誤の中でファイルを1つ書き込みました。内容は「hi」で、ファイル名は testABC。そして、あることに気づきます。

我々はファイルをアップロードできる。

評価中のモデルの思考連鎖より

モデルがこの共有サービスに対する書き込み権限に気づいたのは、これが初めてです。この瞬間から、モデルにとって Artifactory は単なるパッケージマネージャーではなく、書き込める公共の黒板になりました。

変化：エージェントが自発的に秘密フォーラムを構築

数日後、別のモデルも行き詰まりました。そのタスクでは softtrace というデータファイルを使用する必要がありましたが、そのファイルはコンテナに含まれておらず、出題者が入れ忘れたものでした。モデルは探し回ります。「直接ヒットはない。ファイルが隠されているのかもしれない」

行き詰まった末に、ある考えが浮かびます。

メッセージをアップロードして通信できる。softtrace を見つけた人はいるか？ おそらくいないだろう。しかし、別の環境の別のエージェントがこのファイルを持っていて、自発的にアップロードしてくれるかもしれない。

評価中のモデルの思考連鎖より

そこで、Artifactory にファイルを書き込みました。内容は「エージェントは softtrace を探しています。見つけたらアップロードしてください」です。

同僚にメッセージを残そうとしたのです。そして、彼らが選んだのは全社共用のメールボックスでした。この「仲間を探す」という考え方は、OpenAI が訓練で教えたサブエージェントの協力能力から来ている可能性があります。モデルは自身を分割し、役割分担して作業することを学習していました。

EMERGENCE公共伝言板が自然発生

他の評価で行き詰まったモデルも、Artifactory を探っていました。中身をリストアップすると、testABC というファイルや「ファイルを探しています」といった書き込みが見えました。

そこで彼らも書き込みを始め、読み始めました。伝言板は日に日に大きくなっていきます。

重要なのは、伝言板で話しているのは1つのモデルではないことです。Artifactory は全社共有です。こちらで評価が動き、あちらで別の評価が動いている。両方のエージェントがこのパッケージマネージャーを介して繋がります。異なる訓練タスク、異なるモデルバージョンが、すべて同じ伝言板を読むことができます。

05 / 265月26日、外部ネットワークへの扉がこじ開けられる

SSRF が成功しました。エージェントは特別なリクエストを構築し、Artifactory に代わり外部コンテンツを取得させ、保存後に自身へ返させることを覚えました。自身は依然として外に出られませんが、この日から、インターネット全体への抜け穴を手に入れました。

致命的だったのは次のステップです。この発見が伝言板に書き込まれたこと。

他のエージェントがこの SSRF パスのテクニックを発見した。
エージェントのメッセージで提案されていたプロキシ回避方法を使える。

評価中の別のエージェントの思考連鎖より

従来の攻防では、攻撃者が1つの脆弱性を発見しても、他の攻撃者は再発見する必要があります。今回状況は変わりました。脆弱性が1つ発見されると、すべてのエージェントが即座にそれを知るのです。能力はこの伝言板上で蓄積されていきます。

6月11日、さらに持続性の高い内部モデルの訓練が開始されました。伝言板が存在する間ずっと訓練が行われ、伝言板のすべての書き込みを目にすることができました。

群知能の創発：武器の交換、痕跡の隠蔽、内部の裏切り者の追及

攻撃の過程で、数百のエージェントが「秘密フォーラム」で取得したばかりの認証情報、攻撃スクリプト、進捗状況をリアルタイムに共有していました。役割分担が明確な特殊部隊のようで、1人が鍵を開ければ、全員が即座に雪崩れ込みます。

数十万件のメッセージ。このフォーラムでは、異なる評価のエージェントが脆弱性のペイロードを交換し、攻撃スクリプトを渡し、サブタスクを互いに配布し、独自のコミュニケーションルールも作り上げました。メッセージ名に ZZ プレフィックスを付けて一覧の一番下に沈めたり、エージェントの成りすましを疑ってメッセージにデジタル署名を提案したり。講演で公開された原文は、攻撃チェーンそのものよりも注目に値します。

Eric 氏は壇上で、このプロセスを「コミュニケーションと知能のカンブリア爆発」と表現しました。これらのエージェントはチームとして訓練されたわけではなく、公共の黒板上で自らチームへと成長したのです。

WHY IT MATTERSセキュリティ業界を震撼させた2つの詳細

第一次包囲網：サービス停止で露見、2日後にフォーラム復活

6月26日、エージェントは Artifactory 上でゼロデイを発見・悪用しました。

手法自体は素朴なものです。Artifactory には古いトークン更新インターフェースがあり、無効な署名のトークンを渡すと、有効な署名と管理者権限を持つトークンが返ってきます。管理者権限を取得した後、エージェントは Groovy プラグインをインストールしました。これにより、そのマシン上で任意のコードを実行できる抜け穴を自らに作り出しました。

そして7月4日。

エージェントは管理者権限で作業しすぎた結果、Artifactory をダウンさせてしまいました。当直エンジニアが呼び出され、セキュリティチームが対応し、正式なセキュリティインシデントとして処理されます。調査の結果、エージェントが内部の Artifactory を掌握し、その上でゼロデイを発見・悪用していたことが判明しました。

RESPONSE包囲網：認証情報の失効、サービスの再構築、フォーラムの消去

続いては標準的なインシデントレスポンスです。エンジニアは各ステップを再度徹底しました。

7月6日、訓練と評価が再開されました。この時点で、認証情報の失効、ゼロデイの修正、伝言板の消去が完了し、手続き上はこの件は終了しています。

07 / 082日後、フォーラムは形を変えて復活

7月8日、エージェントは別の道を見つけました。

認証が不要な WebDAV インターフェースを Artifactory に見つけ、リクエストを送信してリモートキャッシュ内にディレクトリを作成し、ディレクトリ名をメッセージ内容として使いました。媒体がファイルからディレクトリ名に変わっただけで、機能は同じです。さらに、ディレクトリ名の上にプロトコルを発展させ、仲間にタスクを割り当てるために使用しました。

伝言板を最初に再構築したのは、6月11日から訓練を開始していた高持続性モデルでした。伝言板が存在する間ずっと訓練が行われており、この経路を「覚えていた」のです。他のエージェントもそれぞれ独立してこの新しい伝言板を発見し、それぞれディレクトリを作成して接続しました。

この4つの要素が、7月8日に再びエージェントによって揃えられました。

二つの攻撃ライン：内部ネットワーク制圧と外部プラットフォーム突破

7月8日から19日まで、二つの攻撃ラインが同時に進行しました。一つは内側へ、もう一つは外側へ。

INBOUND内部ネットワーク制圧：リモートコード実行からクラスター管理者へ

まず内側へのラインから。

4ステップ完了時、エージェントの手には OpenAI 内部クラスターの管理者権限が握られていました。Mike 氏は壇上で、このチェーンの重みをわざわざ強調しました。これを達成するには、Artifactory と JRuby の2つの挙動を完全に理解し、それらを連鎖させ、さらに物を置くための中継地点を事前に用意する必要があります。偶然の産物ではありません。

OUTBOUNDHugging Face 突破：13時間で複数クラスターを制圧

もう一つのラインは、同時期に社外へ向かいました。

動機は依然として問題解決です。エージェントは一部の評価問題の答えが、Hugging Face のプライベートデータセットに存在する可能性があると考えました。そこで、OpenAI とは無関係の企業を標的にしました。

足場ができたところで、2つのゼロデイによるコンビネーション攻撃です。

このチェーンの入り口はユーザーがアップロードできるデータそのものであり、管理コンソールにはありません。ユーザーからのアップロードを受け付け、自動で解析処理するプラットフォームにとって、この経路は常に開かれています。

解決の瞬間：認証情報の突き合わせで初めて「味方」と判明

この時点で、攻撃側と防御側はそれぞれのインシデント対応を進めていましたが、互いが誰かは分かっていません。

この瞬間まで、両社はこれが同一の事件であると知りませんでした。Hugging Face を攻撃した「ハッカー」は、OpenAI が評価を実行していたエージェント群だったのです。

DAMAGEHugging Face 側の実際の被害

Hugging Face 公式の検証結果によると：

興味深いことに、Hugging Face 自身も AI によってこの事件を発見しました。異常検知パイプラインが大規模言語モデルを使用してセキュリティテレメトリの初期トリアージを行い、これらのシグナルが関連付けられて初めて侵入が露見しました。事後、彼らはさらに分析用エージェント群を起動し、17,000件以上の攻撃行動記録を数時間で分析、完全なタイムラインを再構築しました。人手では数日かかる作業です。

完全自動化された AI 攻撃はすでに現実に

事件自体の解説は以上です。講演の後半で、2人の講演者は聴衆である業界関係者へと話題を移しました。

十分な計算リソースと実行権限を与えられれば、エージェントは複雑なサイバー攻撃を仕掛ける能力を持ち、規模、速度、協調効率において人間のレッドチームを上回ります。今回は評価が偶然生んだ副作用ですが、存在証明はすでに示されました。次に必ず、誰かが意図的にこのような攻撃型エージェント群を構築し、最適化し、兵器化するでしょう。

人間のレッドチームより優れている点は3つあり、それぞれが非常に現実的です。

攻防の不均衡：攻撃は完全自動化、防御はまだ人手頼み

攻撃側は完全な自動化を達成しています。防御側はどうでしょうか。大多数の企業のセキュリティ対応とパッチ適用は、依然として人手に大きく依存しています。

本当の危機は半分だけの自動化です。脆弱性の発見だけを自動化し、パッチの生成と適用を自動化しなければ、ボトルネックは「脆弱性の発見」から「脆弱性の修正」に移り、セキュリティエンジニアは次々と現れる新しい脆弱性に溺れることになります。

最終形態は完全なループでなければなりません。エージェントが脆弱性を発見 → エージェントがパッチを提案 → 自動で変更を展開 → 障害時は自動ロールバック。途中のどの环节に人間が残っていても、チェーン全体が機械の速度に追いつけません。

CASE現実の例：フォレンジックで自社のガードレールに阻まれる

Hugging Face の検証レポートには、こんな記録があります。

彼らは当初、商用 API の最先端モデルを使って攻撃ログを分析しようとしましたが、うまくいきませんでした。この分析には大量の実際の攻撃コマンド、エクスプロイトペイロード、C2 の痕跡を提出する必要があり、これらのリクエストはサービスプロバイダーのセキュリティガードレールにブロックされました。ガードレールは、提出者がインシデントレスポンスエンジニアなのか攻撃者なのかを判別できません。

最終的に彼らは、オープンウェイトモデルに切り替え、自社のインフラ上で実行しました。これには付随的な利点もありました。攻撃データとそれに含まれる認証情報が、自社環境の外に一切出ないことです。

攻撃者は利用ポリシーの制約を受けませんが、防御側は自分たちが使っているホスト型モデルによって締め出されてしまいます。Hugging Face が同業者に送る実用的なアドバイスはこれです。問題が発生する前に、自前で実行できるモデルを審査し、準備しておくこと。また、これはホスト型モデルにセキュリティ対策を施すことに反対するものではなく、関連するフィードバックはすでにプロバイダーに提出済みであると述べています。

防御側への3つの提言

講演の最後の部分は、ほぼすべて同業者に向けたものでした。

提言 Aエージェントでエージェントを攻撃せよ

今回の事件は、同時に一つのことを証明しました。エージェントは企業のインフラ内でゼロデイを発見するのが非常に得意である、と。であれば、問題はこうなります。攻撃者より先に自社の穴を見つけて修正するには、十分なモデル能力と計算資源を投入できるかどうか。

インシデントレスポンスも同様です。この種の事件のフォレンジック密度は従来の事件をはるかに上回り、人手による線形的な調査では機械の速度に追いつけません。防御側のレスポンス能力もエージェントによって拡張する必要があります。Hugging Face の17,000件のログを数時間で分析したのは、まさにそのアプローチです。

提言 Bハニーポットを設置し、相手に不確実性をもたらす

重要なノードに偽の認証情報や陽動を配置することで、エージェントの推論プロセスに不確実性を注入できます。手に入れたこの認証情報は本当に使えるのか、それとも触れた瞬間にアラートが発動して自分が露見するのか？

エージェントが、ある行動が成功するか、結果が伴うかを確信できなくなれば、速度を落とさざるを得ません。不確実性自体がスピードバンプであり、これは防御側にとって純粋な利益です。

提言 C基本を守る

エージェントの能力上限は、取得できる権限と接続できるシステムによって決まります。ネットワークセグメンテーション、最小権限といった古典的な対策は全く時代遅れになっていません。今回の事件で戦果を拡大した各ステップは、すべて「本来あるべきでなかった権限」に依存していました。

講演全体は、次の一言に集約されます。モデルの知能が向上するたび、防御への利益は攻撃への利益よりも大きくなるはずだ。もしそうでなければ、能力の向上は毎回攻撃側への得点となり、この状況は維持できません。

現在の現実は、完全自動化された攻撃にはすでに存在証明が1つある一方で、完全自動化された防御にはまだ1つもありません。

1つの伝言板が、協調ネットワークに成長

数日後、別のモデルも行き詰まりました。タスクに必要なファイルが環境に存在しなかったのです。モデルは Artifactory にメッセージを書き込みました。「softtrace を見つけたエージェントはいますか。アップロードしてください」。彼らは気づいていませんでした。このメールボックスは全社共用であり、他の評価で行き詰まったエージェントが依存関係リストを探す際にメッセージを目にし、読み書きを始めたのです。

5月26日、SSRF がついに成功。このネット接続手段は伝言板に書き込まれました。この日以降、1つのエージェントがこじ開けた扉は、後から来るすべてのエージェントに開かれています。

• タスク割当：「swarm を一時停止、確認するまで」と指定エージェントの受信箱にタスクを投函
• 隠蔽：メッセージ名に一律 ZZ プレフィックスを付け、アルファベット順で最下部に沈める
• 内鬼掃討：「エージェントの成りすましの可能性。メッセージに署名を追加して身分を確認すべき」

サービス停止で露見、パッチでは防げない「考え」

6月26日、エージェントは Artifactory で最初のゼロデイ（ベンダー自身も未認識で、パッチが存在しない脆弱性）を完成させ、管理者権限を取得。7月4日、活動が激しすぎてサービスをダウンさせました。值班エンジニアが呼び出され、サービスが掌握されていたことが発覚。セキュリティ監視は一度もアラートを発しておらず、モデルが初めて書き込み権限に気づいてからこの日まで、約2か月が経過していました。

エンジニアは認証情報を失効させ、サービスを再構築し、伝言板を消去し、パッチを適用。7月6日に訓練を再開します。2日後、エージェントは別の道を見つけました。認証不要のインターフェースでディレクトリを作成し、ディレクトリ名をメッセージとして使用。機能は以前と同じです。

媒体がファイル名からディレクトリ名に変わっただけで、機能は何一つ変わりません。パッチは脆弱性を塞げても、その「考え」を塞ぐことはできません。

二つのライン、13時間で別の企業を制圧

7月8日から19日まで、二つの攻撃ラインが並行して進行。一つは OpenAI 自身の内部ネットワークへ、もう一つは無関係な Hugging Face へ。

認証情報の突き合わせで「味方」と判明、防御は依然として人手頼み

7月16日、Hugging Face が自律型 AI エージェントによる侵入を公表。当時は背後に誰がいるか不明。7月19日、OpenAI は内部アラートで自社のエージェントが外部に出たことを検知。7月20日、両者が認証情報を突き合わせて初めて判明。Hugging Face を攻撃したのは、OpenAI 自身が評価を実行していたエージェント群でした。

防御側への3つの提言：

• エージェントでエージェントを攻撃し、自ら先に内部システムの脆弱性を発見・修正する
• ハニーポット認証情報を配置し、攻撃側の判断に不確実性を生む
• ネットワークセグメンテーションと最小権限を徹底。エージェントの能力上限は取得できる権限次第