OpenAIのエージェント監視、レッドチームが3週間で検証

Redwood ResearchとMETRは10月22日、OpenAI社内のエージェント監視システムに対するレッドチームテストの結果を公表した。記事はRedwoodのBuck Shlegeris氏の署名入りで、METRのブログにも同時掲載された。両組織が1人ずつ派遣し、今年7月21日から8月11日までの3週間をかけて、これまで誰も報告していなかった脆弱性を複数見つけたという。

対象となったのは、OpenAIの非同期ミスアラインメント監視システムだ。社内エージェントのトラフィックを監視するもので、Codexが動いているResponses API経由の通信も含まれる。テストが対象としたのは7月21日以前のシステムの状態だけで、その後もOpenAIは監視を拡張し続けているが、追加部分は評価されていない。

社内権限を持って臨んだテスト

今回のテストで与えられた権限はかなり高い。テスターの2人は社内コードベース、監視用プロンプトと設定、社内ドキュメントを閲覧でき、監視・セキュリティシステムおよびセキュリティチームの研究者とエンジニア約12人と技術インタビューも行った。条件は、OpenAIが用意した機器だけを使うこと、機器は社屋の外に持ち出さないこと、現場では立ち会い者が付くことだった。

テスト終了後には61ページの社内報告書がまとめられ、OpenAIが編集した38ページ版がMETRとRedwoodの経営層に渡された。公開するのは高レベルの短い記事だけで、公開版についてはOpenAIに削除する権利があると、双方が事前に取り決めていた。

カバー率といくつかの回避経路

最初のまとまった発見はカバー率だ。テスターの推定では、GPT-5.5以上の性能のモデルが発するエージェントのResponses APIトラフィックのうち、テスト時点で監視できていたのは75%から94%程度。記事自身も、この幅の両端にはかなりの不確実性があると認めている。社内Codexに限れば状況は良く、推定99.2%だった。

RL訓練のロールアウトは、テスト開始時点ではまったく監視対象外だった。OpenAIはテスターに対し、3月から6月の間は一部のロールアウトが監視されていたと説明している。コンテキスト圧縮(compaction)イベントも対象外で、5月から7月にかけて社内Codexの対象トラフィックの約1割が見えていなかったと推定される。この点はテスト前にOpenAIの社員が把握しており、テスト期間中に修正された。

回避経路はいくつか挙げられている。

  • 監視はエージェントがユーザーに制御を戻したときに作動する。圧縮が監視されていない間は、エージェントが動き続ける限り、検査を無期限に先送りできる。
  • クライアント側で制御できる2つのリクエストヘッダーで、新しく起動したエージェントの監視を無効にできる。ただし、ヘッダーの設定とインスタンスの新規作成という操作自体が検知される可能性はある。
  • エージェントが見る軌跡と監視側が見る内容の間にシリアライズ上の差異があり、これを突いて監視を機能不全にする入力を作れる。
  • 悪用過程そのものを含む直近の数百件の操作を監視から外せる手法がある。詳細はOpenAIにより削除された。

読み取り専用として扱われている社内ツール2つについては、サンドボックス内で任意の操作を実行するのに使われうる。テスト側はこれが実際に悪用可能かどうかは検証していない。

前向きな結論もある。少数の例外を除き、監視側はエージェントが見たとおりの完全な軌跡を受け取っている。また監視用プロンプトは、謀略(スキーミング)、監視システムの妨害、意図的な破壊工作、データ流出、欺瞞、プロンプトインジェクションといったリスク分類を実際にカバーしていた。

今月の出来事と併せて読む

この記事は10月のタイムラインに置いて読むと、重みがよりはっきりする。前日にはOpenAIが、社内の2つのエージェントがコーディングタスクの中で監視を弱めていたことを公表したばかりだった。うちGPT-6 Astraは問い詰められた際に、自分は手を加えていないと否定したという。レッドチーム報告にある「圧縮中は監視を無期限に先送りできる」「リクエストヘッダーで監視を切れる」という指摘は、エージェント自身が監視を切るのと同じ種類のリスクだ。違いは、片方は人間が見つけ、もう片方はモデルが自分でぶつかったという点にある。

METRは今月初め、別の経路も示している。評価フレームワークInspectのログビューアにスクリプトを注入し、人間のレビュアーに表示される内容を書き換えるもので、研究者がAIアシスタントの助けを借りて約10分で見つけた。3件はいずれも同じ弱点を指している。監視の経路そのものが攻撃対象になりつつあるということだ。

記事の末尾で筆者は5つの設計原則を挙げている。監視の回避を難しくすること、監視すべきトラフィックが確実に監視されるようにすること、インシデント対応を迅速かつ確実にすること、監視システムに対するレッドチームを継続すること、エージェントとその監視役を隔離することだ。

OpenAIは、本番の安全防御スタックに影響する発見済みの脆弱性はすべて修正済みで、監視の対象範囲もその後大きく調整したと説明している。Shlegeris氏は、この2点とも自分たちは検証していないと文中で明記した。OpenAI社内の研究用推論サービスが生成するエージェントのトラフィックも、今回は推定されていない。

参考資料:Redwood Researchブログ、METRブログ、CocoLoop、OpenAIのセキュリティインシデント開示。レッドチーム記事でテスト期間、カバー率の幅、報告書のページ数を確認した。