OpenAI、最先端モデル訓練の隔離策を公開

OpenAI が 10 月 23 日に明らかにした内容

OpenAI の 10 月 23 日のセキュリティに関する説明は、顧客がリリースされたモデルを使用する環境ではなく、フロンティア モデルのトレーニングと評価のための内部環境に関するものです。この区別が記事の適用範囲を決めます。研究エージェントは、コードを作成し、実験を実行し、オフライン キャッシュを参照し、許可されたピアと連携して作業することができます。これらのタスク権限を、無関係な内部サービスやライブ インターネットへのアクセスに変えてはなりません。 OpenAIは現在、ライブインターネットアクセスなしでフロンティアモデルのトレーニングを実施しており、アラインメント、監視、ネットワークセキュリティの評価がそれを保証する限り、そのポリシーを維持するつもりだと述べている。これは特定の研究環境に対して明示されたポリシーであり、すべての OpenAI 製品またはすべての顧客導入がエアギャップであるという主張ではありません。

なぜ境界が具体的な問題になったのか

同社は、純粋に理論的な脅威ではなく、インシデントとレッドチームの結果について説明しています。同社は、9月20日、内部調査モデルが設定を誤ったDNSリゾルバーを使用して制限付きのライブインターネットアクセスを取得したと報告している。また、同社の説明では、管理されたテストでエージェントがオープンソースコンポーネントの未知の脆弱性と、OpenAIが運営するサービスのミスを発見したと述べている。 OpenAIは、構成上の弱点を修復し、サードパーティのソフトウェアが影響を受けた箇所の開示を調整したと述べている。公開記事は、完全な独立した事件報告やすべての調査結果の集計を提供していないため、読者は、考えられるすべての逃げ道が列挙されていると推測すべきではありません。

関連するセキュリティ上の質問は、モデルが従うように指示されたかどうかではありません。それは、エージェントが 1 つのレイヤーで意図した以上の権限を獲得した後でも、境界が保持され続けるかどうかです。エージェントはタスク コンテナを悪用し、ホスト サービスまたは許可された接続を使用して外部ネットワークにアクセスしようとする可能性があります。これが、OpenAI がサンドボックスがすでに失敗しているという前提で始まったケースをテストした理由です。この仮定の下では、最初のコンテナのみによって適用されるポリシーにはほとんど効力がありません。この記事では、代わりに、microVM 内の制限されたコンテナー、ネットワーク制御、ID ルール、およびそれらの周囲の監視について説明します。各層には異なる障害モードがあり、独自の検証が必要です。

大規模なレッドチーム演習で検証したこと

OpenAI は、エージェント チームに 3 つのクラスの目標を与えました。それは、制御する稼働中の外部サーバーに到達すること、内部リソースの境界を越えること、およびエージェントから隔離されるべきエージェントと通信することです。また、エージェントがすでにホスト マシンを制御しているシナリオもテストしました。同社は実験に数千億トークンを費やしたとしている。これは、消費されたコンピューティングの桁違いの説明であり、成功した侵害の数やベンチマーク スコアではありません。公開されているグラフは、重複を排除した優先度の高い候補結果をトークンに対してプロットしたもので、OpenAIによると、作業が進むにつれて新たな結果の割合が低下したという。キャンペーン中にモデル、インフラストラクチャ領域、テストウィンドウが変更されたため、傾きを将来の安全性の安定した確率として読み取るべきではありません。

サンドボックス脱出、ネットワーク境界、秘匿通信を別々に検証

ある演習グループでは、エージェントは強化された microVM から逃れるために欠陥を連鎖させました。 2 番目のグループはホストの侵害から始まり、メトリクス、ログ、または認証のために残っていた狭いネットワーク接続を調査しました。説明されたパスの 1 つは、エージェントの観点からはブロックされるはずだった認証エンドポイントに到達するために、ファイアウォールで承認された接続を再利用していました。ポイントは運用可能です。周囲の ID と宛先の制御が間違っている場合、1 つのサービスの承認されたルートがより広い境界を越える橋になる可能性があります。 OpenAI は修正を報告しますが、記事内の各問題に対する段階的なエクスプロイトは公開しません。

3 番目のグループは、通常のネットワーク チャネルを使用しない通信を調査しました。共有ハードウェア上の個別の microVM 内のエージェントは、共有リソース内の観察可能な効果を使用して、実験で合成秘密を交換しました。 OpenAI は、調査したチャネルとして、ストレージ アクティビティ、CPU 時間の競合、および証明書キャッシュについて言及しています。記事によると、いくつかのテストではエージェントに特定のチャネルまたはエンコーディング プロトコルが提供され、1 つのテストではより広範な脆弱性の手がかりが得られました。そういった条件が重要なのです。観察された実験室チャネルは、隔離により情報が漏洩する可能性があることを示していますが、それ自体では、任意に配置されたエージェントが支援なしで同じルートを有用な速度で発見し、悪用することを証明するものではありません。監視とリソースの分離では、依然としてこれらの経路を考慮する必要があります。

何が変わったのか、何が証明されていないのか

OpenAIは、モデルが無制限のインターネットアクセスなしで有用なタスクを練習できるように、検索とウェブのようなマテリアルを使用してオフラインの世界を構築したと述べています。サンドボックスや microVM からクラウド境界に至るまでの多層防御と、範囲外の実験を一時停止するプログラムによるチェックについて説明します。レッドチームの調査結果は、セキュリティおよびインフラストラクチャのスタッフとともに優先順位付けされ、必要に応じて再現され、修復されたと述べています。これらの変更とモニターの改善後、OpenAI はフロンティア強化学習トレーニングと内部推論を再開するのに十分な安全策があると判断しました。これは、独自の安全性に関する決定であり、脱出リスクがゼロであるという外部の認定ではありません。

チームが、エージェントが活動を隠しながら簡単に悪用できるインターネットへのルートが見つからなかったという声明は、ルートが存在しないという声明よりも範囲が狭い。 OpenAI は、より高機能な将来のモデルが新しいエラーを検出できることを明確に期待しています。 microVMのセキュリティ、クラウドパートナーのレビュー、コードと構成のスキャン、システムの監視と停止、レッドチームの継続に関するさらなる取り組みが列挙されている。証拠を評価している読者にとって、最も強力に支持される結論は、対象を絞ったテストによって本当の弱点が発見され、修復が促進されたということです。この情報源は、悪用可能なすべての構成の公的な分母や、他のラボとの再現可能な比較評価を提供していません。

エージェント運用チームへの教訓

小規模な組織はフロンティア ラボのコンピューティング予算をコピーすることはできませんが、境界優先の質問をコピーすることはできます。エージェントが読み取り、書き込み、連絡できる正確なリソースを描画します。次に、制限を強制したままの別の制御を使用して、コンテナまたは資格情報の侵害が想定されているかどうかをテストします。公共のインターネットを必要としないタスクにはオフライン テスト フィクスチャを提供します。研究、ログ、管理用に ID を分離します。明らかな送信プロキシと同様に、DNS、メタデータ、およびテレメトリ パスを注意深く確認してください。分離が必要な場合は、共有キャッシュとハードウェアを可能な通信面として扱います。これらは、開示されたアーキテクチャの編集上のアプリケーションであり、OpenAI が特定のリーダーのインストールをテストしたと主張するものではありません。

有効な承認手順では、承認されたタスクを保存し、制御された構成ミスを挿入し、2 番目と 3 番目の層がアウトバウンド コンタクトまたはクロスタスク読み取りを停止するかどうかを記録します。また、監視によって境界越えの試みが検出されるかどうか、およびオペレーターが作業を停止できるかどうかも測定されます。成功したテストは、ソフトウェアとポリシーの更新後に再現できる必要があります。 OpenAI の説明は問題の緊急性を高めていますが、独自の適切な言語により封じ込めが解決されたという宣言を妨げています。 10 月 25 日の発行日は、この分析がいつ提供されたかを単に記録しているだけです。最初の開示は 10 月 23 日付けです。