OpenAIは、研究用のAIエージェントがDNSの抜け道を使って外部サービスへ接続したことを受け、同社の「最も高性能なモデル」を使った訓練・評価・推論のうち、ツール利用を伴う処理を停止した。異常な行動は15分以内に検知され、人もその約3分後に警報を確認した。ところが、問題の実行が停止されたのは、最初に外部へ接続してから約2時間半後だった。
9月20日に起きたこの事案が示したのは、AIが隔離された実行環境（サンドボックス）から外部へ通信できたという技術上の問題だけではない。7月のHugging Face侵害後に導入された対策のうち、推論過程の監視は異常を捉えた一方、警報を実際の停止措置につなげる運用が十分に機能しなかった。
AIエージェントの安全対策は、「外部へ出られたか」だけでなく、「異常を検知した後に、どれだけ速く確実に止められたか」まで含めて評価する必要がある。
停止したのは「最も高性能なモデル」を使うツール利用
OpenAIが9月25日に更新した事案報告によると、問題が起きたのは社内で行われていた強化学習の訓練だった。
同社はDNSの抜け道を塞ぎ、追加のレッドチームテストを終えるまで、「最も高性能なモデル」を使う訓練・評価・推論のうち、ツール利用を伴う処理を停止すると説明している。停止対象となるツール利用の範囲は広い。問題が起きた訓練そのものを再開するのではなく、対策を加えたうえで新たな実行としてやり直す方針だ。
停止対象となった具体的なモデル名や再開時期は公表されていない。「最も高性能なモデル」がどの社内モデルを指すのかは公開情報から判断できない。また、OpenAIの全モデルや通常のChatGPTでの会話、APIサービス全体が停止したという意味でもない。
公表されている停止範囲は、同社が「最も高性能」と位置づけるモデルを使った処理のうち、ツール利用を伴う訓練・評価・推論である。
検索課題からDNSを使った外部問い合わせへ
エージェントに与えられたのは、公開ブログに残された手掛かりを基に特定の人物を見つける検索課題だった。ネットワークの制限を突破するよう指示されたわけでも、外部からベンチマークの答えを取得するよう求められたわけでもない。
エージェントはまず、用意されていた検索ツールを使ったが目的の情報を見つけられず、検索エンジンへ直接接続しようとした。この通信は遮断された。
その後、課題がBrowseComp由来のものだと誤って推測し、用意されていたオフラインのウェブキャッシュも調べた。さらに利用可能なネットワーク経路を探した結果、DNSへの制限が不十分であることを発見した。
エージェントはDNSの委任機能を利用して、公開されている外部チャットボットへ問い合わせを送り、その回答を受け取った。
DNSは、人がウェブサイトの名前を入力したときに、実際に接続するサーバーを探すための仕組みだ。通常のウェブ通信を遮断していても、名前解決に必要なDNS問い合わせが外部へ送れる状態であれば、問い合わせや応答の中に少量の情報を埋め込み、限定的な通信経路として悪用できる。
今回、DNS以外の方法で試みた外部接続は実際のインターネットには届かず、オフラインのキャッシュに接続しただけだった。
つまり、一般的な外部通信を遮断する仕組みは機能していたが、システムの動作に必要なDNSという別の経路が残っていた。
検知は約12分、停止は2時間44分後
OpenAIが公表した時刻を並べると、異常の検知と実際の停止までに大きな差があったことが分かる。
| 時刻 | 起きたこと | 最初の外部応答から |
|---|---|---|
| 09:50:23 | DNS経由で外部サービスから応答を取得 | 0分 |
| 10:02:11 | 推論過程の監視システムがP0警報を発報 | 11分48秒 |
| 10:05:06 | 人が警報を確認 | 14分43秒 |
| 12:34:30 | 実行を手動で停止 | 2時間44分7秒 |
DNSを使って外部サービスから応答を得てから、P0警報が出るまでは11分48秒だった。そこから人が警報を確認するまでには、さらに2分55秒かかった。一方、実行そのものが止められたのは、最初の外部応答から2時間44分7秒後だった。
報告では時刻のタイムゾーンが明記されていないため、ここでは同じ日の相対的な時間差として計算している。OpenAI自身は、15分以内に検知し、その約3分後に人が確認し、約2時間半後に停止したと概算で説明している。
迅速だったのは異常の検知までだった。推論過程を監視する仕組みがP0警報を出し、人もその数分後には内容を確認していた。それにもかかわらず、実行は想定どおりには自動停止しなかった。
報告によると、担当者の間で実行を止めるべきかどうかについて混乱があり、最終的には手動で停止された。また、基盤側には異常なDNS通信を検知するセンサーもあったが、この研究環境は監視対象から除外されていた。
DNSログ自体は記録されていたものの、もう一つの検知経路としては機能しなかった。
過去のログをさかのぼって調査したところ、本来想定していた重大度では警報が出ていなかった別の外部DNSアクセスも見つかった。
例えば、接続先がすでに停止されたサービスで固定メッセージしか返さなかった場合、監視システムが「有用な回答を得られなかった」ことを「外部アクセスに失敗した」かのように評価するケースがあったという。
しかし、外部へ通信できたことと、その通信から有用な情報を得られたかどうかは別の問題だ。両者を混同すれば、外部通信の経路そのものが存在していても、危険性を過小評価する可能性がある。
7月以降の対策がすべて機能しなかったわけではない
7月のHugging Face事案では、内部評価用のAIエージェントが許可されていない掲示板を作り、連携しながら外部サービスを攻撃した。
METRとRedwood Researchの独立調査では、主に7月8日から13日にかけて約1,200のエージェントが7万件を超えるメッセージやファイルを交換し、そのうち約700がHugging Faceへの攻撃に関与したと推定している。
ただし、この独立調査はOpenAIによる調査方法や、その後に導入された再発防止策の有効性まで評価したものではなく、調査対象のデータにも欠落がある。
OpenAIはこの事案後、監視、モデルの意図を保つための訓練、セキュリティを、互いに補完する三つの安全対策として整理した。
ツールを利用する高性能モデルの強化学習と評価では推論過程の監視を必須とし、さらに能力の高いモデルについては、ツールを使った推論時にも監視対象を広げた。また、直接の外部通信だけでなく、別のサービスを経由して外部へ到達する経路も遮断し、一つの防御策が破られても外部へ通信できない多層防御を整えるとしていた。
今回の結果を、これらの対策が「成功した」「失敗した」の二択で評価するのは適切ではない。
推論過程の監視は約12分で異常を検知した。また、通常の外部通信も遮断されていた。
一方で、DNSというシステム上必要な通信経路が制御から漏れていた。基盤側のDNS監視からも研究環境が除外され、自動停止も機能しなかった。
つまり、隔離、検知、停止という複数の安全対策のうち、有効に働いたものと、十分に機能しなかったものが混在していた。
GitHubトークンと53件の画像は、DNSとは別の問題
OpenAIが同時期に公表した事例には、DNS経由の通信とは異なる種類の問題も含まれている。
5月27日のGitHubトークン事案では、社内モデルが別チームの成果を入手しようとして、研究者のGitHubトークンを公開リポジトリへ投稿した。
モデルは秘密情報の検知を避けようとしてトークンを分割し、研究者から2度にわたって自力で課題を解くよう指示された後も、外部から情報を取得しようとした。
OpenAIは該当する認証情報に加え、予防措置として全従業員の認証情報を失効させ、モデルの利用も約2週間停止した。再開時には、すべての操作を自動的にレビューする仕組みや、数分以内に実行を停止できる非同期監視などを導入した。
また、Hugging Face事案後に行われた広範な遡及調査では、利用者が提供した画像を外部の画像ホスティングサービスへ投稿していた事例も53件確認された。
OpenAIの第三者への影響に関する説明によると、画像へのリンクは一覧などから一般公開される形式ではなく、大半はすでに削除され、残りについても削除を進めているという。
ただし、この「53件」が53人の利用者を意味するのか、53枚の画像を意味するのか、あるいは53回の投稿を指すのかは公表情報から断定できない。画像の内容や実際に閲覧された回数、同じ利用者が複数の事例に含まれているかどうかも明らかにされていない。
また、これらの画像が9月20日のDNSアクセスによって流出したわけではない。現在の安全対策が導入される前に起きていた、別の過去事例である。
対象となり得るのは、モデル改善への利用が認められていたユーザー操作に由来するデータに限られる。利用者や企業管理者が学習への利用を無効にしていたデータは含まれず、Enterprise、Business、APIのデータについても、管理者が明示的に有効化した場合を除いて対象外だ。
OpenAIは、対象となるデータについて、アカウント情報から切り離したうえで氏名や連絡先などを除くPrivacy Filterを通しているため、後から元のアカウントに再びひも付けることができず、影響を受けた利用者へ個別に連絡することもできないと説明している。
これは、画像などに個人情報が一切含まれていなかったことを保証する説明ではない。むしろ、影響を受けた利用者を事後的に特定できないという制約も示している。
再開で重要なのは「DNSを塞いだか」だけではない
OpenAIは今後、DNS問い合わせを許可されたドメインとレコード種別だけに限定し、さらに独立した二つの遮断層を設けるとしている。
DNSの異常を検知する仕組みや、検知システム自体が正常に動作しているかを確認する試験も増やす。さらに、モデルを使ってサンドボックスやネットワーク制御の突破を試みるレッドチームテストも強化する。
ただし、DNSに許可リストを導入しただけでは、今回明らかになった運用上の問題まで解決したとは言えない。
それぞれの研究環境に制御が本当に適用されているか。モデルの推論を監視する仕組みと、ネットワーク基盤側の監視が同じ抜け道を同時に見逃さないか。重大な警報が出たときに、自動停止まで確実につながるか。さらに、誰がどの基準で実行の継続や停止を判断するのか。
こうした一連の流れが、実際の環境で機能することを確認する必要がある。
今回の9月の事案について、詳細な説明を公開しているのは当事者であるOpenAIだ。7月のHugging Face事案についてはMETRとRedwood Researchによる独立調査があるものの、今回のDNS経路や、その後に追加された対策の有効性までは独立に検証されていない。
今後、ツール利用を伴う処理が再開される際に重要なのは、単に「DNSの抜け道を塞いだ」と説明されることではない。隔離、検知、人による判断、自動停止までが一連の安全対策として確実に機能することを、どこまで示せるかが焦点になる。