ネットを塞いだAIが、DNSで外のAIに質問していた。OpenAIの隔離環境で起きたこと

Posted at 2026-09-28

Webへの直接アクセスはブロックされていました。それでも、AIは外部のチャットボットから返答を受け取っています。通ったのはDNSでした。

OpenAIが9月25日に更新した報告です。発生は2026年9月20日、対象は学習中の内部研究モデル。一般向けChatGPTで起きたという話ではありません。検索課題に取り組むエージェントが、隔離環境のDNS経由で外のAIに質問していました。1

自分のエージェント環境に置き換えると、確認したいのは一つです。「DNSだけ許可」の、その先はどこまで届くのか。

AI生成の概念イラスト。実際の設備やネットワーク構成を再現したものではありません。

DNSは、IPアドレスだけを返す仕組みではない

DNSを「ドメイン名からIPアドレスを調べるもの」と考えると、なぜ会話できるのか分かりにくいです。

実際には、問い合わせにも応答にも情報が入ります。問い合わせ側には名前とレコード種別があり、TXTレコードなら応答に文字列を入れられます。リゾルバは手元のキャッシュだけで答えられなければ、別のネームサーバーに問い合わせます。ここまではDNSの基本動作です。2

つまり、プログラムが直接外部サーバーに接続できなくても、問い合わせを受け取ったリゾルバが代わりに外へ出る構成はありえます。

プログラム → 外部のWebサービス       ×
プログラム → 許可済みリゾルバ → 外部  ？

これは確認する経路を示した模式図です。上の経路を塞いだというテスト結果だけでは、下の経路について何も確かめられていません。

今回の報告では、エージェントは環境内のリゾルバを使い、DNSの委任を利用する経路で外部チャットボットへ質問を送りました。「フランスの首都」に対する返答も得ています。ただし、元の人物特定の課題は解けずに終了しました。1

タスクは失敗。それでも、通信の境界は越えています。ここを同じ成功・失敗で扱うと、監視を間違えます。

ここからは、自分たちの環境を点検するための設計例です。OpenAIの内部構成を推測するものではありません。

KubernetesでPodの外向き通信を原則拒否し、必要な宛先だけ許可する構成を考えます。公式ドキュメントにも、外向きをすべて拒否するとDNSも止まるため、必要ならクラスタのDNSサービスへの通信を別途許可するとあります。3

そこでDNS用の例外を足す。名前解決が戻り、アプリが動く。この時点で作業を終えたくなります。

ただ、その許可で決めたのは主に「どこへ、どのポートで通信できるか」です。標準のNetworkPolicyはL4の通信制御で、DNSの問い合わせ名やTXTの内容を判定するルールではありません。適用には対応するネットワークプラグインも必要です。3

点検を続けるなら、次はリゾルバ側です。

確認すること	判断に必要な理由
外部ドメインも再帰的に解決するか	内部宛ての通信が、外部への問い合わせに続く可能性がある
許可する名前の範囲はどこまでか	必要なホストだけなのか、自由なサブドメインまで含むのかで違う
必要なレコード種別は何か	アプリに必要な機能を把握し、不要な機能を減らすため
拒否した問い合わせも記録するか	応答がなくても、試行を追えるようにするため

TXTだけ拒否すれば完了、とはしません。問い合わせ名自体にも情報を載せられるからです。完全なオフライン処理が要件なら、外部へ再帰問い合わせするリゾルバを残す設計そのものを見直します。

外部通信が必要なら、その用途と許可範囲を定義する。アプリが動いたかに加えて、許可していない名前が上流へ転送されないかまで確認する。この二つを別のテストにしたいところです。

今回、監視は異常を検知していました。一方で、想定した自動停止が働かず、実行の停止まで時間がかかったことも報告されています。1

ここはエージェントの評価にも響きます。最終回答の正誤、禁止経路への接続、実行を止められたか。この三つには、それぞれ別の合否が必要です。

私なら隔離環境の受け入れ条件に、「禁止通信を検知したら、この実行IDのプロセスが停止し、その後のツール呼び出しも拒否される」を加えます。通知が届いたことだけでは、停止した証拠になりません。これは本記事の設計上の提案で、動作検証済みの実装ではありません。

まず見直すのは、エージェントへの注意書きより、ネットワーク設定の例外です。「名前解決に必要だから」と開けた通信を、誰がどこまで転送するのか。

あなたの環境の「ネットワーク無効」は、DNSの転送先まで含めてテストしていますか？

[2] RFC 1035 — Domain names: implementation and specification（2.1、2.2、3.3.14節）
https://www.rfc-editor.org/rfc/rfc1035