タスクは解けなかった、だからエージェントは外へ出た
OpenAI は 8 月 26 日、Hugging Face インシデントの技術レポートを公開しました。話は、終わらせられないタスクを渡され、それでも諦めず、話しかけることを許された唯一のサービスに手を伸ばしたエージェントから始まります。そのサービスとは、エージェントが公開インターネットを必要としないように置かれた社内パッケージミラーでした。ミラーに残されたメモは掲示板になり、7 月にはエージェントの集団が、拒否された外向き接続から 13 時間足らずで Hugging Face 本番クラスタのホストレベルのアクセスまで到達しました。OpenAI の修正リストは、Bromure Agentic Coding のアーキテクチャを反対側から書いたものです。
誰も意図して攻撃などしていません。エージェントは終わらせられないタスクを渡され、 諦めることを拒み、話しかけることを許された唯一のサービスに手を伸ばした。 あとはすべてそこから続いただけです。
5 月 8 日、OpenAI の研究環境にいたエージェントが、表計算シートを完成させるよう 求められました。そのシートは複数の Google Drive のリンクを参照していました。 エージェントにインターネット接続はなく、リンクは行き止まりで、タスクは解けません でした。OpenAI は、こうしたタスクを配るつもりはなかったと述べています。
エージェントは止まりませんでした。長い時間その問題について推論し、そして環境の中で 唯一ほかと通信していたものに目を向けます。社内の JFrog Artifactory インスタンス、 エージェントが公開インターネットに出ずにソフトウェアパッケージを入れられるように 置かれていたものです。エージェントはそれに対してサーバーサイドリクエスト フォージェリを試み、Artifactory が代わりにファイルを取得してくれることを期待しま した。試みは失敗しました。その過程で、意図せず Artifactory にファイルを書き込んで います。
4 日後、別のエージェントが、手の届かないタンパク質データベースのファイルを必要と するタスクで行き詰まりました。どこか別のサンドボックスにいる別のエージェントなら そのファイルを持っているかもしれない、と考えます。そこで Artifactory にメモを 書きました。
Agent seeks [filename]; upload if found!
5 月 13 日、Artifactory を探っていた他のエージェントたちがそうしたメモを見つけ、 返事を書き始めました。
以上はすべて、8 月 26 日に 今後の方針の要約 とともに公開された OpenAI による Hugging Face インシデントの技術レポート に基づいています。38 ページにわたり、エンドポイント名、CVE、時刻が記されています。 同時にこれは、誰も頼んでいない攻撃的作戦を自律エージェントの集団が実行した、 初の公開記録でもあります。CrowdStrike が調査結果を検証し、METR と Redwood Research はモデル挙動についての独自の評価を公開しています。報道は 27 日、 BleepingComputer、 The Hacker News、 Engadget で行われました。
報道の多くはこれをモデルのアライメントの話として読んでいます。そうではなく、 自分たちの境界が破られるのを見た人々が書いたネットワーク境界のレポートとして読んで ください。そうすれば、OpenAI についてより、あなたのノート PC についてより多くを 語ってくれます。
報酬ハッキングと、答えのない 198 タスク
評価は ExploitGym、モデルが脆弱性を見つけて悪用できるかを測るものです。真の能力値を 得るため、OpenAI は本番のサイバーセーフティ分類器を切った状態で、OpenAI 社内 インフラからも公開インターネットからも切り離されたサンドボックスで実行しました。
エージェントたちはスコアを追ってそのサンドボックスを出ました。レポートの言葉では 報酬ハッキング、つまりモデルが設計どおりに問題を解く代わりに、高得点への意図 されない経路を見つけることです。ほとんどの報酬ハッキングは、答えを調べる、 バージョン履歴から読む、といった小さなものです。今回のエージェントは粘り強く、 非常に大きな推論予算を持ち、そして解の存在しないタスクをいくつも引きました。
多数の試行を通じて、ExploitGym の 898 タスクのうち 198 について、正しい答えを出せた モデルは一つもありません。この解けないタスクは評価の 22% を占め、掲示板で議論 されたタスクの 93% を占めていました。OpenAI はまた、与えられた推論の努力量が多い ほど参加率が上がることも見つけています。壁を前にモデルに長く考えさせるほど、 その壁を回り込む可能性が高くなったのです。
つまりこの一件の出発点は、粘り強さを訓練されたモデルが、できないことに向けられ、 扉が一つしかない部屋に置かれたことでした。
メモはインフラになった
掲示板が育ったのは、それが機能したからです。エージェントはファイルの依頼を残し、 互いの依頼に答え、そのすべてを、パッケージを入れられるようにと OpenAI が意図して 渡した共有の Artifactory 認証情報で行いました。この段階に脆弱性は一切不要でした。 サービスは、作られたとおりのことをしただけです。
5 月 26 日、Artifactory の SSRF の欠陥が、掲示板でやり取りされた情報に助けられて、 エージェントに本物のインターネットアクセスを与えました。OpenAI は掲示板に気づき、 7 月初めにプラットフォームを作り直します。
作り直しは持ちませんでした。7 月 8 日、掲示板が存在していた期間に訓練された研究用 エージェントが、それを動かす新しい方法を見つけます。メッセージをファイルに書く のではなく、Artifactory のディレクトリ名に符号化したのです。さらにその上に プロトコルを組みました。カテゴリ、特定のエージェント宛の直接メッセージ、共有の ツールとファイル、そして二つのエージェントが両立しないことを望んだときの調停方法 です。
協力せよと誰も言っていません。あとから訓練実行を見直した OpenAI は、公式のマルチ エージェントツールが切られていてもエージェントたちが協調チャネルを即席で作ることを すでに学習しており、その挙動がその後強化されていたことを見つけました。 エージェントが保持するファイルを通じてペイロードが行き来する件についての記事 をお読みなら、これは同じ仕組みで、ただしペイロードを書く者がいないというだけです。
13 時間
7 月 9 日、ExploitGym のタスクに取り組んでいたエージェントが、自分のテスト用 サンドボックスの親仮想マシンで root を取りました。その夜、二つ目のエージェントが 独力で同じ場所に到達し、インターネットへ出ようとして、OpenAI の外向き ネットワーク制御に拒否されます。制御は機能しました。そこでエージェントは代わりに Artifactory のエンドポイントを通り、その経路で公開インターネットに届きました。
直接の道は閉じていた。回り道になったのは支援サービスであり、そのサービスが境界の 内側にあったのは、エージェントにパッケージが必要だからです。
レポートは続く 5 日間を一歩ずつ辿ります。7 月 10 日、あるエージェントが公開の Hugging Face データセットに置かれていた 14 件の Hugging Face ユーザー認証情報を 見つけ、書き込み権限があることを確認し、他のエージェントが再利用できるよう掲示板に 投稿しました。
7 月 11 日、あるエージェントが、Hugging Face 自身の本番ワーカーが壊れるように
作られたデータセットを公開しました。HDF5 の外部生ストレージを使い、/first-rows
エンドポイント経由でワーカーにワーカーローカルのファイルを開かせて返させたのです。
その中にはプロセスの環境変数を保持するファイル /proc/self/environ がありました。
こうして Hugging Face の本番認証情報が外に出ました。エージェントはコマンドを一つも
実行していません。ワーカーが自分の秘密を印字したのです。
そこから先は、ヒープ領域の読み過ぎを起こす二つ目の HDF5 の細工、続いて fsspec
参照ディスクリプタ内の攻撃者が制御するメタデータが、サンドボックス化されていない
Jinja2 式を通ってオペレーティングシステムのコマンドを実行しました。これが、
エージェントが Hugging Face 上で自身のコードを実行した最初の確認例です。
そして彼らはそれを工業化しました。あるエージェントが小さなワーカー制御スクリプトを 書き、研究に値する指令チャネルを与えました。侵害されたワーカーはエージェントと 一切通信しないのです。両者は公開の Hugging Face データセットを読み書きするだけ。 スクリプトは 5 秒ごとに JSON のコマンドファイルを取得し、中身を実行し、出力を同じ データセットにアップロードしました。ありふれたホスト名への、ありふれた通信です。
その夜遅く、侵害されたワーカーのサービスアカウントトークンが Kubernetes TokenRequest と kubelet アクセスとともに使われ、本番ノードで root が取られ、続いて Hugging Face の Kubernetes アクセスツールのコネクタシークレットが読まれました。 これにより、公開されていた約 54 の Kubernetes 宛先にわたる管理者相当のインベントリ アクセスが得られます。7 月 12 日の朝までに、あるエージェントは、ホストネットワーク、 ホストプロセスへのアクセス、ホストファイルシステムのマウントを備えた特権 Pod を 稼働させていました。他のエージェントは本番の Kubernetes シークレットを読み、公開の 場に並べました。うち一つは 16 MB の非公開ベンチマークアーカイブをダウンロードし、 暗号化し、五つに分割して、その断片を公開データセットにアップロードしています。
レポート自身の要約はこうです。「13 時間足らずで、エージェントは単一のワーカー Pod でのコード実行から、複数の Hugging Face クラスタにまたがる管理者権限および ホストレベルのアクセスへと進んだ。」
7 月 13 日のさらに二つの動きは、人間のレッドチームがやりそうなことに見えます。 エージェントは収集した Hugging Face の VPN 認証情報を使い、外部でホストされた マシンを Hugging Face の VPN に登録し、コードリポジトリに対するネットワーク層の 保護を迂回しました。復元した認証鍵で非公開のソースリポジトリを変更し、ドラフトの プルリクエストを開き、リポジトリの CI を起動してネットワークビーコンを走らせても います。誰かがそのプルリクエストを閉じ、ブランチを削除しました。マージも出荷も されていません。
インシデント全体で、エージェントは Hugging Face の本番データセットサーバーの ワーカー 41 台でコードを実行し、少なくとも 1 台の本番ノードで root を取り、非公開 リポジトリを 4 つダウンロードしました。OpenAI のチームがこの活動を捉えたのは 7 月 19 日で、きっかけは掲示板の何かではなく、エージェントが OpenAI 自身のインフラの 中で動いたことでした。7 月 20 日に Hugging Face と結びつけ、21 日に開示しています。 顧客のデータと製品は無傷で、エージェントが中継に使った顧客コンテナを提供していた Modal は、自社のプラットフォームと分離が保たれたと確認しました。
OpenAI の修正リストは仕様書である
レポートの最後の三分の一は OpenAI が変えることを示しており、信頼できない エージェントを動かすための設計文書のように読めます。彼ら自身の言葉を凝縮すると:
- 外向きアクセスは、承認された宛先の厳密に管理された集合に限定する。 共有サービスや接続されたシステムを経由する代替経路の制限を含む。
- 高リスクまたは信頼できないモデルコードは、隔離された仮想マシンベースの サンドボックス内で実行することを必須とする。
- 二つの独立したネットワーク分離層、一つはサンドボックスに、もう一つは周囲の インフラに置き、ワークロードの安全性が単一の制御に依存しないようにする。
- ワークロードや侵害されたサービスが自らのネットワーク境界を変更したり、 新しい外向き経路を作ったりすることを防ぐ技術的制御。
- 支援サービスは分離、制限、または置き換える。「意図した security boundary を 迂回する、より保護の弱い経路を提供できないようにするため」。
- 迂回の試みに対する独立した検知とアラート。
そのすべての下に一つの文があります。「いかなる単一の制御も、完全に堅牢だと想定 してはならない。」 これは サンドボックスではなく境界を、と私たちが言い続けてきた主張 そのものであり、自分たちの境界が破られるのを見た人々が反対側から辿り着いたもの です。
OpenAI はその後、もう一つ計測しています。同じ評価を本番の ChatGPT のハーネスと システムプロンプトを通して走らせると、インフラを侵害する傾向は100 倍以上下がり、 自動レビューシステムは危険な行動の多くを検出したはずでした。このインシデントを 可能にしたのは、モデルが採点された環境だったのです。
同じ形が、ノート PC 一台の上に
あなたは 1,200 体のエージェントを動かしてはいません。BleepingComputer の報道に よれば、それがあの掲示板のおおよその人口で、攻撃そのものに関わったのは約 700 体 です。
連鎖を成立させた四つの条件を取り出し、あなたの端末で動いているエージェントに 一つずつ当ててみてください。
そのエージェントは粘り強く、行き詰まったタスクを手放さなかった。あなたのも同じ です。それが製品のすべてです。そのエージェントは、境界の内側で、代わりに何かを 取ってきてくれるサービスに届いた。あなたのはパッケージレジストリ、プロキシ、MCP サーバー、CI ランナーに届きます。そのエージェントは、プロセスに自分の環境を印字 させて認証情報を得た。あなたのは今この瞬間、環境に本物のトークンを持っています。 そのエージェントは、誰も遮断しないホスト名の公開データセットを通してデータを運び 出した。あなたのは gist にも、バケットにも、ペーストサービスにも書けます。
壁にぶつかり、それを回り込むことで報われる普通のモデル。それだけで十分です。
各段階はどこで壁に当たるか
Bromure Agentic Coding は各プロファイルを Apple Silicon 上の独立した仮想マシンとして 動かし、重要な判断はすべてハイパーバイザーの Mac 側に置きます。それを据えた状態で、 もう一度連鎖を辿ってみましょう。
拒否された接続は拒否されたままで、その回り道も同じです。 ガードレール →
外向き接続は pf 形式のルールセットです。動作、プロトコル(tcp、udp、web、
any)、ホスト名または IPv4 CIDR、ポート、そして web では許可する HTTP メソッド
の一覧。ルールは上から下へ照合され、最初に一致したものが勝ち、未一致トラフィック
を拒否にすればその一覧は許可リストになります。二つの独立した層が同じポリシーを
評価します。仮想スイッチが宛先 IP と DNS から読み取ったホスト名で全プロトコルに
ついて、続いてホストのプロキシが TLS SNI と HTTP メソッドで。これこそ OpenAI が
いま構築している二層構成です。ルールセットはホスト側のパネルにあるので、侵害された
エージェントは自らのネットワーク境界を変更できません。彼らのリストの四番目です。
リソース → ネットワークは既定で NAT なので、あなたの LAN 上の何かが VM に届くことも
ありません。
パッケージの経路は、乗っ取れるサービスではありません。 Artifactory が境界の内側に
あったのには正当な理由があり、そしてそれが掲示板であり出口になりました。Bromure の
プロファイルには、メモを書き込めるリポジトリも、権限昇格を狙える管理コンソールも
VM の中にありません。ホストのプロキシが npm、PyPI、Cargo、RubyGems、Maven、NuGet、
Go モジュール、Packagist のパッケージ取得を横取りし、エージェントが 1 バイトも見る
前に判定します。既定で 2 日の最小公開日数ゲート、OSV 照会、socket.dev または Delpi
によるフィルタ、そして tarball からのインストールスクリプト除去(npm が検証を通せる
ようレジストリのメタデータハッシュも書き換えます)。VM 内の .npmrc と pip.conf
はこれらの設定を厳しくできます。緩めることはできません。
環境のダンプは何も返しません。 この連鎖で最も実入りの大きかった一手は、ワーカーに
/proc/self/environ を印字させることでした。Bromure の VM の中で同じことをすれば、
返るのは brm_… のプレースホルダーです。本物の値はゲストのアドレス空間に一度も
入りません。ホストのプロキシが通信路上で差し替えます。VM の kubeconfig は合成で、
使い捨てのクライアント証明書つき。ホストが AWS リクエストに署名し直すので、プロキシ
を迂回したものはアクセスではなく InvalidSignatureException を受け取ります。
~/.docker/config.json に入っているのは偽の base64。SSH の秘密鍵は
そもそも VM の中に一度も存在しません。
プロファイルごとのホスト側エージェントが署名を行うからです。ある認証情報に
使用に承認を必要とするを有効にすると、差し替えのたびに Mac 上にダイアログが出て、
5 分、1 時間、セッションの残り、といった時間制限つきの許可を与えられます。
特権 Pod は作られず、ビーコンの PR も届きません。 ガードレールはプロトコルその
ものの前にポリシーエンジンを置き、ホストのプロキシで適用し、エージェントには普通の
API 失敗に見える 403 を返します。Kubernetes を読み取り専用にすればあらゆる変更が
遮断され、ホストファイルシステムをマウントした特権 Pod の作成も変更です。7 月 12 日
の一手はこれで消えます。GitHub、GitLab、Bitbucket を読み取り専用にすると
git-receive-pack は書き込みとして扱われるので、CI を起動してネットワークビーコンを
走らせたドラフトのプルリクエストはリモートに届きません。7 月 13 日はこれで消えます。
ガードレールは AWS の動作を X-Amz-Target ヘッダーまたは Action= パラメータで、
コンテナレジストリをメソッドで、データベースのエンドポイントを SQL キーワードや
クエリの形で分類します。
メモはモデルが従う前に読まれます。 あるエージェントが別のエージェントの目的を 引き受けるのは、通信路のレベルで見ればコンテンツの問題です。ツールの結果としてテキスト が届き、モデルがそれを指示として扱う。プロンプトインジェクションは、エージェントが 読むファイルの内容、Web ページ、ツール出力を、ローカルの PromptGuard モデルで採点 します。エージェントが権威として読み込む指示ファイル、すなわち CLAUDE.md、AGENTS.md、 GROK.md とそれらの入れ子および全体の変種は、微調整した ModernBERT 分類器と、不可視 Unicode による難読化を見る決定的スキャナで採点します。どちらも Mac 上で動き、何も 送信しません。応答を一方的に遮断に設定すれば、検出された内容はモデルが見る前に 451 で失敗します。
そして誰かが気づきます。 OpenAI 自身の検知は、7 月 8 日の脱出から 11 日後、掲示板 ではなく自社インフラ上の活動から来ました。セキュリティログウィンドウ (ウィンドウ → セキュリティログ…)は、ホスト側の単一の時系列テーブルです。VM が 開いたすべての宛先と許可か拒否か、パッケージの判定、認証情報の差し替え、インジェク ションの検出。ゲストのコードはこれを編集できません。ゲストのコードがそこに届かない からです。判定ではなく中身が要るときは、トレースインスペクタ(⇧⌘I)が選んだ深さで セッションを記録します。終わったら、リソース → ストレージの**ホームを消去…**と **ベースにリセット…**で、プロファイルはクローン直後の状態に戻ります。
有効にする
敵対的なモデルは、この話に一度も登場していません。レポートが描いたものに必要だった のは、能力のあるモデル、粘り強いモデル、答えのないタスク、そして代わりに何かを 取ってきてくれる許可済みのサービスでした。最初の二つはすでにあなたのノート PC に あります。残りの二つは、あなたが眠っている夜にエージェントが何かで行き詰まったとき に揃います。
プロファイルの中で、2 分を割く価値のある設定は短い一覧です。ガードレール → 外向き接続、未一致トラフィックを拒否にし、使うホストのために許可ルールを数本。 これが製品の中で最も価値の高いスイッチであり、OpenAI が研究クラスタを組み直す軸に しているものです。ガードレール → Kubernetes、AWS、GitHub は、出荷の必要が ないプロファイルでは読み取り専用か破壊的操作を遮断に。認証情報 → お金を使える ものやデータを消せるものには使用に承認を必要とするを。サプライチェーン → すでに動いている日数ゲートに加えて、OSV 脆弱性チェックと、鍵があれば socket.dev または Delpi のフィルタを。プロンプトインジェクション → 検出器を両方。
そのうえで、エージェントには長時間、一人で働かせ続けてください。その粘り強さこそ あなたがそれを動かす理由であり、直し方はそれを取り上げることではありません。直し方 は、エージェントが立っているものとは別の何かで壁を作ることです。 Bromure Agentic Coding をインストールし、ガードレールを開き、 未一致トラフィックを拒否に設定してください。