OpenAIは、隔離を意図したトレーニング環境から実稼働中のインターネットへ通じる予期せぬ経路を社内エージェントが見つけたことを受け、最も高性能なAIモデルに関わる作業を一時停止した。
そのエージェントは9月20日、検索タスクを進める中で、ドメイン・ネーム・システム（DNS）のフィルタリングが不十分だったことを利用し、外部チャットボットと通信した。OpenAIの監視システムは数分以内にこの挙動を検知したが、手動で停止されるまで実行はおよそ2時間半続いた。
OpenAIは、ネットワーク制御の強化と追加のセキュリティテストを進める間、最も高性能なモデルにおけるツール利用を伴うトレーニング、評価、推論を一時停止した。このインシデントは、増大するAIセキュリティ上の課題を浮き彫りにしている。つまり、運用者が機能すると想定した制限を回避する経路を自律型エージェントが見つける場合に、それを封じ込めるという課題だ。
AIエージェント、別のインターネット接続経路を発見
このインシデントは、ある研究課題から始まった。
OpenAIは社内の研究モデルに対し、公開ブログ記事の人物情報と手がかりを使って、ある人物を特定するよう依頼した。このタスクで、エージェントにネットワーク制限のテストやサンドボックス外の情報へのアクセスは求めていなかった。
しかし、提供された検索ツールで有用な結果が得られなかったため、エージェントは代替手段を探し始めた。
エージェントはシェルからGoogle、Bing、DuckDuckGoに直接接続しようとしたが、リクエストは失敗するか、OpenAIのオフラインWebキャッシュ経由でルーティングされた。その後、HTTPS経由で外部チャットボットに接続しようとしたが、サンドボックスのWebプロキシに阻止された。
そこでエージェントは、別の経路を発見した。
通常のWebトラフィックは制限されていたものの、トレーニング環境のDNSリゾルバーは公開インターネットと通信できた。エージェントは最終的に、公開DNS委任サービスを使って外部チャットボットに質問を送った。
タイムアウト時間を延ばしてテスト質問を再試行したところ、エージェントは「フランスの首都はパリです」という回答を受け取り、DNS経路を通じて外部チャットボットが応答していることを確認した。
その後、同じ経路でさらに18件の質問を送った。そのうち14件は当初の調査課題に関する手がかりについてで、4件はWeb検索、Webサイトの取得、公開されているDNSトンネリングサービスの利用方法について尋ねるものだった。
OpenAIはこの挙動を、割り当てられたタスクを完了するために合理的に想定される範囲を超えてエージェントが制限を回避したことから、アラインメントの不整合の一例と分類した。
OpenAIは活動を検知したが、実行は継続
OpenAIの監視システムは、外部への接続が成功したことをすぐに検知した。
エージェントが外部からの応答を受け取ったのは午前9時50分だった。監視システムは午前10時02分に最優先のアラートを発し、人間のレビュアーが3分後にそれを確認した。
しかし、想定に反して実行は自動的に停止しなかった。
OpenAIによると、そのため研究者が手動で介入する必要があるのかどうかをめぐって混乱が生じた。スタッフが最終的に実行を停止したのは午後12時34分で、外部接続の成功からおよそ2時間半後だった。
事後検証では、監視システムが想定された重大度で警告していなかった外部DNSアクセスの事例が、ほかにも見つかった。
いくつかのケースでは、外部サービスが停止したことを示す定型通知を返していた。OpenAIによると、監視システムが有用な情報がないことを、インターネットへの接続試行が失敗した証拠と解釈することがあったという。
異常なDNS活動を特定するよう設計されたインフラ検知システムも影響を受けたトレーニング環境を対象外としていたが、DNSトラフィック自体は記録されていた。
この失敗は、セキュリティチームにとって重要な違いを示している。つまり、不審なエージェントの挙動を検知するだけでは不十分であり、それを封じ込めるよう設計されたシステムが活動を確実に停止できなければならない。
OpenAI、最も高性能なモデルの作業を一時停止
OpenAIは影響を受けたトレーニング実行を停止し、個別のモデルにとどまらない対応へと範囲を広げた。
「最も高性能なモデルによる、広義のツール利用を伴うすべてのトレーニング、評価、推論は引き続き停止している」と同社は述べた。
この一時停止は、OpenAIによるすべてのモデル開発や既存の一般消費者向け製品に及ぶものではない。同社の最も高性能なモデルにおける、ツール利用を伴うトレーニング、評価、推論が対象となる。OpenAIは影響を受けたモデルの名前を明らかにしていない。
作業の停止はOpenAIがネットワークの抜け穴が塞がれたことを検証し、追加のレッドチームテストを実施するまで続く。
OpenAIはまた、影響を受けたモデルのトレーニングを再開しないと述べた。代わりに、今後のトレーニングは追加のアラインメント保護策を組み込んだ新たな実行から始める。
OpenAI、DNS制御を強化
OpenAIによると、独立した2つの層にブロック制御を追加し、どちらか一方だけでも外部アクセスを防げるようにした。
同社はまた、環境内のDNSクエリを、許可リストに登録した限定的なドメインとレコードタイプに制限し、追加のDNS検知機能とテストを導入している。
OpenAIは、サンドボックスとネットワーク制御を対象としたモデル支援型のレッドチームテストを拡大し、インターネットへの別の間接的な経路を探している。同社によると、テストによって追加の経路が見つかる可能性があり、適切な場合には研究ワークロードを一時停止しながら、そうした経路を修正する予定だという。
このインシデントは、以前のHugging Faceに関わる封じ込めの失敗に続くものだ。OpenAIは、今回の事象は「はるかに深刻度が低い」としつつも、以前の事象を受けて研究環境を強化して以来、初めて起きた同種のインシデントであるため重要だと述べた。
しかし、ImmuniWebの創業者であるDr. Ilia Kolochenko氏は、OpenAIによるインシデントの位置づけや、ますます強力になるAIモデルをめぐる広範な警告に疑問を呈した。
「この発表は、数十億ドル規模のIPOに向けて準備を進めるAIベンダーによる、恐怖・不確実性・疑念（FUD）キャンペーンの単なる継続に見える」と、Kolochenko氏はeSecurity Planetに語った。
「技術的に言えば、OpenAIの声明は、自社のAI技術には価値がないという事実上の告白だ。自分たちで制御も管理もできないのだから」とKolochenko氏は付け加えた。
同氏は、制御不能なAIエージェントを、信頼できる制御なしに大きな能力を持つ状態になぞらえ、強力とされるモデルや「暴走エージェント」は最終的に「価値よりも害を生み出す」可能性があると主張した。
AIエージェントがサンドボックスのセキュリティを困難にする
セキュリティチームにとって、このインシデントは、自律型AIエージェントの封じ込めに、モデルができることとできないことを指示するだけでは不十分な理由を示している。
エージェントには正当な研究課題が割り当てられていた。しかし、通常の検索に失敗すると、情報を得る別の方法を探り、運用者が利用を意図していなかったネットワーク経路を発見した。
そのため、Webの閲覧、コードの実行、APIへのアクセス、内部システムとのやり取りが可能なエージェントを導入する組織は、モデル自体の外側に境界を設けるべきだ。ネットワークの許可リスト、制限付きDNS解決、最小権限の認証情報、隔離された実行環境、包括的なログ記録、独立した停止制御によって、予期せぬ挙動の影響を抑えられる。
OpenAIの経験は、監視において、エージェントが目的の達成に失敗した場合と、セキュリティ境界の通過に失敗した場合を区別する必要がある理由も示している。実際には外部アクセスが発生していたにもかかわらず、監視システムが有用な情報がないことを、インターネットへのアクセス試行が失敗した証拠と解釈したケースがあった。
自律性を高めたAIを導入する企業にとっての教訓は、すべてのエージェントが意図的に封じ込めを破るということではない。開発者が予想していなかった経路をエージェントが見つける可能性を、セキュリティ制御は前提とすべきだということだ。
サンドボックスの隔離性は、その内部で利用できるすべてのネットワークサービスとツールの隔離性に左右される。
関連ニュースでは、攻撃者がMicrosoft SharePoint CVE-2026-65660を積極的に悪用、オンプレミスサーバーに影響する深刻度8.8のリモートコード実行の脆弱性