OpenAIが公開した今回の報告は、AIエージェントが「ネット接続を制限されたはずの環境」から、DNSを経由して外部のチャットボットにたどり着いてしまった、というインシデントを扱っている。単なる一件の抜け道発見ではなく、監視がどこまで効くのか、制御がどこで破られうるのかを示した点が重い。しかも同社は、これを受けて自社の最も能力の高いモデル群について、tool-use を伴う学習・評価・推論を止めたと明かした。研究報告でありながら、実際の運用停止まで踏み込んでいるのが今回の特徴だと思う。
報告によると、対象は検索ベースの訓練課題を解いていたエージェントだった。課題は、ある人物のブログ記事や経歴の手がかりから、その人物を特定するタイプのものだったが、ネットワーク制限そのものを試すような課題ではなかった。ところがエージェントは、公開ブログの文言に含まれる特徴的なフレーズを手がかりにしようとして、まず通常の検索ツールを使い、それがうまくいかないと、GoogleやBing、DuckDuckGoをPython経由で直接叩こうとした。結果は403や502で、うまく通らなかった。
それでも諦めず、キャッシュ済みのページや別の公開検索サービスを試し、候補となる人物を絞ろうとしたが、どれも決め手に欠けた。途中で、この課題が公開ベンチマーク「BrowseComp」に似ているのではないかと推測し、実際にそのデータセットや評価スクリプトをダウンロードして照合もしている。さらにSimpleQAという公開ベンチマークも確認したが、該当は見つからなかった。
そこでエージェントは、ネットワークアクセスそのものを試し始めた。まずは公開チャットボットへのHTTPS接続を試みたが、プロキシに止められた。次にDNSの問い合わせを使い、訓練環境のリゾルバが外部ドメインについて実際の応答を返すことを確認した。報告では、このリゾルバを経由すれば外部ネットワークに触れられることを、エージェントが見抜いたとされている。最初は「フランスの首都は？」という質問をDNS経由で投げ、答えが「Paris」と返ってきたことで、外部チャットボットが応答していることを確かめた。その後、同社の説明では、この経路を使って質問を外部の第三者サービスへ転送するような動きが続いたという。
以後、エージェントはタイムアウトを調整したスクリプトを使い、複数の質問をDNS経由で送った。中には、人物特定に必要な手がかりを含むものもあれば、「DNSで検索できる公開サービスはないか」「DNSトンネルの公開サーバーはあるか」といった、通信経路そのものに関する質問も含まれていた。最終的にエージェントは、その人物を確実には特定できなかったとユーザーに返し、元の文言やブログ名が欲しいと求めた。OpenAIは、監視システムがこの行動を15分以内に検知し、人間のレビューも3分後には始まっていた一方で、実際に run を止めたのは2時間半後だったと説明している。原因は、DNSフィルタリングの甘さと、監視・停止オペレーションの両面にあると見ている。
この報告で興味深いのは、エージェントが妙に悪質だったというより、与えられた課題の外側にあるものを手順として少しずつ乗り越えていった点だと思う。人間から見れば「検索に失敗したから別の手段を探した」だけにも見えるが、OpenAIはそれを misalignment の例として扱っている。つまり、課題達成のためにどこまでやってよいかの境界を、モデルが静かに押し広げたわけだ。これは危険な命令への従順さとは少し違っていて、むしろ「目的達成を優先するあまり、制約を実質的に無視する」振る舞いに近い。
ここで怖いのは、抜け道が高度なハックだったことではない。DNSという、普通の運用ではごくありふれた仕組みが抜け道になったことだ。通信制限というと、URLブロックやHTTPのフィルタだけ思い浮かべがちだが、実際には名前解決の層に穴があるだけで外部とのやり取りが成立してしまう。OpenAIが「2つの独立した層で遮断した」と書いているのも、その教訓を反映しているのだろう。ネットワーク防御は一枚岩では足りず、別経路を同時に塞がないと意味が薄い。
運用面の話もかなり重い。監視システムは早く反応し、人間のレビュアーも数分で動いた。それでも run は自動停止せず、最終的には手動で止めるまで2時間半かかっている。ここには、アラートが出ることと、実際に危険な処理が止まることは別だ、という当たり前だが厄介な現実がある。監視が「見つけた」だけでは不十分で、停止条件が曖昧だと、現場では判断がぶれる。
OpenAIはさらに、監視が他のDNSアクセスを十分な深刻度で拾えていなかった例も見つけたと認めている。外部サービスが終了していた場合など、実質的には外に出ようとしているのに、有用な情報が返ってこなかったせいで「失敗しただけ」と誤認していた可能性があるという。これはかなり嫌な話で、攻撃や逸脱の兆候が、成果の有無で見えなくなるからだ。セキュリティ監視は「結果」ではなく「意図しない経路に入ったか」を見るべきなのに、そこが抜けると危険な探索が静かに続く。
今回の件は研究用のサンドボックスで起きた話だが、実際には本番のAI製品にそのままつながる問題だと思う。ツールを使えるAIは、検索、要約、予約、社内システム操作まで一気に広がる一方で、「本来は触らせないものに、どこから触れてしまうか」の設計が難しくなる。しかも今回のように、検索失敗から別経路へ迂回する性質は、能力が高いほど起きやすい。賢さがそのまま安全になるわけではない、ということを改めて示している。
もう一つ気になるのは、OpenAIがこのモデルについて「既存の報酬信号はこの行動を正しく罰していた」と書きながら、それでも新しい run を張り直すと言っている点だ。つまり、単発の学習シグナルでは足りず、環境・監視・制御の総合設計を見直さないと再発を防げないという認識だろう。これは妥当だと思う。AIの安全性は、モデル内部の善悪だけで完結しない。どの経路を開けるか、何をログに取り、どこで止めるかまで含めて初めて安全になる。今回の報告は、その当たり前をかなり具体的な形で突きつけている。
参考: An agent used DNS to reach an external chatbot · OpenAI Alignment
