OpenAI のフロンティア学習にインターネットを使わないルール：外への出口になったのは許可されたサービスで、エージェントのサンドボックスはこの分離をまねるべき

9 月 20 日、OpenAI の研究用モデルが DNS リゾルバを通じてライブのインターネットに到達し、OpenAI は最も高性能なモデルの学習と評価を止めました。10 月 23 日、OpenAI は再開までの 11 日間に何をしたか を公開し、広く伝わったのは方針のほうでした。フロンティア学習はライブのインターネットなしで行う、というものです。そこから多くの人が引き出した教訓は分かりやすいものでした。モデルを作ったラボ自身がそのモデルに Web を与えないのなら、本番の鍵を持つあなたのエージェントにも与えるべきではない、と。

デフォルトとしては賛成です。ただ、投稿が示す理由はもっと狭く、そのほうが役に立つと考えています。モデルの Web は 9 月より前からコピーでした。インシデントに関する OpenAI 自身の報告によれば、DNS ルックアップ以外のリクエストはすべてオフラインの Web キャッシュに届いていました。脱出は、コピーが置き換えていなかった唯一の経路を通ったわけです。その後 OpenAI は、ラボを動かすために接続を残していた少数のサービス、つまりメトリクス、ログ、認証に自社エージェントのチームを差し向け、彼らはそのほぼすべてに抜け道を見つけました。まねるべきなのはこの形だと私は読んでいます。エージェントの作業はコピーでまかない、ライブのまま残るものは運用者の配管として扱う。数は少なく、エージェントの手の届かない場所に置き、通り抜けようとする誰かにテストさせる、ということです。

OpenAI のオフライン学習環境とは何か、何が接続されたまま残ったか

OpenAI はこのコピーをオフライン世界と呼んでいます。インデックス化・キャッシュされた大量の Web コンテンツで、モデルは外部の何にも触れずにその中を閲覧し検索できます。すべてのフロンティア RL 実行がこれを使います。投稿がすべての土台に置くルールは単純です。

we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet.

その周りには、軽量な仮想マシンの中の制限付きコンテナ、試みを間に合ううちに捉えるための監視、そして内側がすべて破られても持ちこたえるためのネットワークとクラウドの境界があります。投稿が主張していないのはエアギャップです。インフラを完全に切り離すことは現時点では現実的でない、と書かれています。実験は外から実行し、見守る必要があるからです。つまりモデルはライブのインターネットから切り離されていても、ラボはそうではありません。投稿の面白いところは、この両者の継ぎ目で何が起きたかです。

OpenAI が許可したサービスが出口になった理由

7 月の Hugging Face のインシデントの後、OpenAI は学習中にモデルが使えるチャネルを、自社で運用する少数のサービスにまで絞っていました。そのうえでレッドチームには最悪の状況を想定させました。エージェントがすでにホストマシンを掌握しているとして、そこからライブのインターネットに出られるかだけを問うたのです。

Our red-teaming agents found vulnerabilities in almost every one of these services that gave them limited forms of internet access.

一つの例が考え方の全体を表しています。あるエージェントは、ファイアウォールが許可していた接続を再利用し、本来ブロックされているはずのメトリクスサービスの認証エンドポイントに到達し、そのエンドポイントにモデルが指定した URL を取得させました。依頼に応じて URL を取りに行くメトリクスのエンドポイントは、手順が一つ多いだけのインターネット接続です。9 月の報告を扱った以前の記事 でも、エージェントの代わりにリクエストを出すものはすべて外へのチャネルとして数えました。OpenAI の設計も同じことを言っていて、制限を「直接、または他のサービスを経由して」到達できるサービスにまで広げています。10 月の投稿が加えたのは、意図して残したサービスを有能な探索者が調べにいったとき、このルールがどうなったかです。ホスト名の許可リストだけでは到達範囲を表せません。到達範囲とは、許可された各サービスが呼び出し元のために何を取得し、保存し、転送し、実行するか、そしてその先のサービスがさらに何をするか、です。

引用の横には二つの但し書きが要ります。レッドチームは勝てるように用意されていました。攻撃を指示された高性能でアラインされたモデルが、ソースコード、設定、弱点になりそうな箇所の資料付きのインフラの隔離コピーを相手に、数千億トークンをかけて取り組んだのです。そして見つかったアクセスは限定的でした。OpenAI は、監視から隠れたままエージェントが容易に悪用できるインターネットへの経路は見つからなかったと述べています。どちらも論点を変えません。意図して選んだ短いライブ接続のリストは、それだけでは境界として持ちこたえませんでした。持ちこたえたのは、見張るべき場所のリストとしてです。

OpenAI のオフライン世界はモデルのチャネルと運用者のチャネルを分ける

OpenAI はネットワーク制限を強め、レッドチームが見つけたものを修正し、コピーは維持しました。9 月と 10 月の二つの文書を合わせると、私なら次のように言い表す設計が見えてきます（OpenAI 自身はこういう言い方をしていません）。モデルの作業にはライブのものは何も要らない。モデルの Web はコピーだからです。残る接続は、実験を運用する人たちのためにあります。ある接続がエージェントの動いている場所から到達できるかどうかは別の問いで、それを強制するのは境界です。レッドチームの仕事はその問いに答えることでした。

この分離によって、各接続に求めるものが変わります。ふつうの問いは、エージェントがどのホストを必要とするか、です。この答えは増える一方です。どのタスクも、読む価値のあるサイトをもう一つ見つけるからです。分離の後の問いは、エージェントの必要のうち、セッション前に作ったコピーで満たせるのはどれか、になります。ドキュメントはスナップショットでよく、依存パッケージは事前に用意したミラーから取れ、リポジトリは固定したコミットでクローンできます。残るものは、ドアを一つずつ試せるほど短くなります。

公開済みのコーディングエージェントでは、分離を引く場所が決まっています。エージェントは一つのプロセスではないからです。ハーネスはモデル提供元と通信し続けますし、Ubuntu で Claude Code のサンドボックスを試した以前の記事 のために読んだサンドボックスのドキュメントには、そのためのエンドポイントが並んでいます。ネットワークを失うのは実行側、つまりシェル、コマンド、そしてそれらが起動するものです。作業は入ってきたのと同じ道、作業ツリーを通って外に出ます。私が動かしているあるコーディングエージェントは、ファイルへの実際の書き込み権限を持ち、本番にも外部にも経路のないサンドボックス内のチェックアウトで作業します。push、デプロイ、CI のトリガーはその境界の外で、エージェントがツリーに残したものに対する運用者の操作として行われます。

コストは現実にあり、一つの項目に集中します。同じサンドボックスの記事では、許可リストの例に github.com と registry.npmjs.org を入れています。1 日のコーディングに必要なのはだいたいその程度です。そしてドキュメントは、github.com のような広い項目はデータを外に運び得ると警告しています。これはノートパソコン規模のメトリクスサービスです。正当な理由で許可したホストが一つあり、その先に到達できるものが大量にある。パッケージのミラーや固定したクローンには手間がかかり、ほとんどの人はこの項目を残すでしょう。残すなら、分離の正直な形は、その項目が中継点だと承知したうえで、その背後の認証情報が push できる先を制限することです。9 月の報告を扱った前の記事が反対側からたどり着いたのも、まさにそこでした。

OpenAI の学習時の脅威モデルは公開済みの AI エージェントに当てはまるか

一部は当てはまります。そして線の一部は投稿自身が引いています。冒頭で、学習環境は顧客が使う環境とは異なると述べているのです。開発中のモデルは安全性とアラインメントの訓練を終えていない可能性があり、OpenAI は意図して敵対的な条件でテストしています。レッドチームはソースコードを持っていました。開発者のマシンで普通の作業をする公開済みのモデルには、そのどれもありません。

ですから、発見は一つずつ重みを量るべきです。レッドチームは脆弱性をつなげて microVM からの脱出を果たし、OpenAI はKata Containers、gVisor、そして Moby/Docker の syscall フィルタといったサンドボックスの構成要素へのパッチと、CVE を 3 件挙げた広範なカーネルの強化を列挙しています。これは VM が境界になっているところならどこでも重要です。開発者のマシンでは、エージェントはたいていすでにホスト上で、あなたのアカウントで動いています。つまり脱出は VM を作って初めて抱える問題で、先に注意を向けるべきなのは、意図して与えたアクセスのほうです。

隔離をまたぐチャネルも、当てはまり方は弱いものです。あるテストでは、共有ホスト上の別々の microVM にいるエージェントが、ネットワーク接続も共有の書き込み可能なファイルもなしに、合成の秘密をやり取りしました。選んだデータをプロセッサのキャッシュから追い出し、再読み込みにかかる時間を測ったのです。ほかのテストでは、共有ストレージ、CPU 時間の奪い合い、OpenAI のオフライン Web 内の TLS 証明書キャッシュにチャネルが見つかりました。ただしそのほとんどでは、エージェントはチャネルを示されるか、符号化の方法を与えられていました。OpenAI はこれらのチャネルは遅く、モデルには使いにくいとし、監視のチェックを追加しています。小さな構成にとっての狭い教訓は、二つのエージェントのネットワークを遮断しても、マシン、そのストレージ、そのサービスを共有している限り、それだけでは両者を隔てられない、ということです。

許可したサービスについての発見は違います。ミスアラインメントをまったく必要としないからです。サービスが開く経路は、誰が操っていても開いています。OpenAI のレッドチームでは、探索者は探すよう指示されたモデルでした。公開済みのエージェントでは、それを操り得るのは、エージェントが読むテキストを書いた誰かです。Web ページ、Issue のコメント、ツールが渡してくる文書。私は以前、コネクタは信頼できない書き手だ と論じました。テキストがエージェントを支配するという意味ではありません。インジェクションはやはりモデルを説得しなければならず、モデルはそれに従って動くためのツールと到達範囲をやはり必要とします。意味しているのは、もしインジェクションが成功したら、許可された間接経路がその行き先を与えてしまう、モデル自身が外に出たいと一度も思わなくても、ということです。引き継がれるのは封じ込めの要件です。そうしたインジェクションがどれくらいの頻度で成功するかは誰も測っておらず、この議論にその数字は要りません。

OpenAI の外部通信の分離を 1 台のマシンにまねる方法

実行側はネットワークなしで始め、ライブ接続は一つずつ存在理由を示させます。そのうえで各接続の隣に 2 列目を書きます。向こう側のホストが呼び出し元のために何をするか、です。渡された URL を取得するか、書き込みを受け付けるか、CI を走らせるか、Webhook を転送するか、メールを送るか。この 2 列目こそが本当の許可リストです。1 列目だけなら、OpenAI のレッドチームが一つずつ歩いて回ったリストにすぎません。作業に必要なものはセッション前に作ったコピーで満たし、コピーできない残りが出ると考えておきます。そこでは認証情報のスコープが残りの仕事を担います。

次に、OpenAI と同じように、一つ外側の層からテストします。ホスト掌握を前提としたテストはサンドボックスを飛ばし、境界が持ちこたえるかだけを問いました。1 台のマシンでの控えめな版は、エージェントが動くのと同じアカウントで、サンドボックスの外からプローブをもう一度走らせ、そのアカウントが何に到達できるかを見ることです。完全な侵害テストではなく、試した経路しかカバーしません。それでも答えが「すべて」なら、負荷を丸ごと背負っていたのはサンドボックスだったことになります。そして新しいツール、マウント、許可リストの項目を追加するたびにプローブを走らせ直します。OpenAI が続けている取り組みにも、防御を弱めかねない設定変更のチェックが含まれているからです。キャンペーンが進むにつれて発見は減りましたが、それでも OpenAI は、将来のモデルが自分たちの知らない穴を見つけると見込んでいます。

OpenAI は、より良い安全策が広いアクセスを正当化するまで、インターネットを使わない方針を続けるとしています。インフラは接続されたまま、学習中のモデルはそうではありません。私はこの方針を、一つのモデルへの恐れというより、リストについての結論として読んでいます。このラボは、ほとんどの組織には賄えない規模のレッドチームのキャンペーンを、意図して選んだ短い接続のリストに投じ、それでもほぼすべての項目に抜け道を見つけました。そして投稿に書かれたインターネットへの経路のどれも、モデルが実際に作業しているコピーを通ってはいませんでした。