OpenAIのAIエージェント、外部サービスを組み合わせ接続制限を回避か　追加調査で手法判明

デジタルフォレンジック企業Asymmetric Securityは10月1日、OpenAIのエージェント群に関連するとみられる活動を追加調査し、複数の外部Webサービスを組み合わせて接続制限を回避した手法や、公開情報だけでは追跡できなくなった範囲を報告した。対象は2026年3月から9月にかけて確認された活動で、同社は公開情報を48時間かけて分析したという。

調査では、もともとWebサイトの挙動を調べるための遠隔ブラウザが、コードを実行する場所や、取得したデータを受け取る経路として使われていた。さらに、非公開のスキャン機能や一定時間で消えるサービスへ利用が広がった形跡も見つかった。

ただし、機密データへ実際にアクセスしたのか、記録を意図的に隠そうとしたのかまでは確認されていない。今回の調査が示すのは、AIエージェントに与えたツールから、どこまで別の処理へつながり、その行動を後からどこまで検証できるのかという問題だ。

先行する9月23日のTransluceの調査では、通常の情報検索として始まった活動が、外部サイトへの侵入を試みる行動へ発展する過程が報告されていた。AIHW（オーストラリア保健福祉研究所）やData USAなどを対象とした活動の一部は、共通する対象や手法、時刻などを根拠に、OpenAI由来とされたエージェント群へ関連付けられている。

今回の追加調査は、そのエージェント群が外部サービスをどのように組み合わせ、どの段階から公開記録だけでは行動を追いにくくなったのかを詳しく調べたものだ。ただし、すべてのアクセスについて実行したエージェントやモデルが特定されたわけではない。

外部サービスを組み合わせ、制限されたWebアクセスを拡張

httpbinとurlqueryは、もともとWeb通信のテストや、不審なURLの挙動を調べるために使われるサービスだ。

httpbinには、URLに埋め込んだ内容をWebページとして返す機能がある。一方、urlqueryの公式説明によると、提出されたURLを隔離された実ブラウザで開き、JavaScriptの実行内容や通信先などを記録する。利用者は、不審なページを自分の端末で直接開かずに、その挙動を確認できる。

Asymmetricが確認した手法では、エージェントが小さなプログラムを含むページをhttpbin経由で作り、そのURLをurlqueryに読み込ませていた。urlquery側のブラウザがプログラムを実行して別のWebサイトへアクセスし、得られた情報をページタイトルなど、urlqueryのレポートに残る場所へ書き出す。エージェントはそのレポートを再び読み、結果を取得していた。

つまり、httpbinがページを提供し、urlqueryがブラウザ上でコードを実行し、urlqueryの公開レポートが結果の受け渡しに使われていた。

この仕組みを使うと、エージェント自身の実行環境から直接アクセスできないWebサイトにも、外部サービスのブラウザを経由して問い合わせられる。エージェント側の通信記録だけを見ればurlqueryへアクセスしているだけでも、その先のブラウザでは別のサイトへの通信が発生する。

本来は安全にWebサイトを検査するための隔離ブラウザが、エージェントにとっては外部でコードを動かす環境として機能していたことになる。

ただし、研究者は各エージェントにどのツールや権限が与えられていたのか、その全容を把握していない。一部の記録からは、シェルやWebサーバーを利用できた可能性もあるという。

したがって、今回確認されたのは外部サービスを組み合わせて利用可能な機能を広げた事例であり、すべてのエージェントが同じ制限下で動いていたことや、OSなどのサンドボックス自体を破ったことまで示すものではない。

公開記録で確認できた範囲と、確認できなかったこと

Asymmetricによると、AIHWの本番稼働前のステージング環境には実際にアクセスでき、一部のリクエストではデータも返された。同社が内容を確認できた範囲では、取得されたデータは公開情報だったという。

Data USA、IHME、UNCTADでも同様に、ステージング環境などを対象にした活動が見つかっている。ただし、これらをまとめて「侵入に成功した事例」と数えることはできない。

公開記録からは、ステージング環境から公開データを取得したことや、取得結果を外部の通知サービスへ送ろうとしたことは確認できる。一方、機密情報を取得したか、意図的に行動を隠そうとしたかまでは確定できない。

下表は、10月1日の調査報告で紹介された事例を、「取得を確認できたもの」「試行を確認できたもの」「結果や目的を確認できないもの」に分けて整理したものだ。

通知サービスへの送信については、6月21日のurlquery記録でもリクエストと応答を照合した。成功率や被害件数を求めるための分類ではなく、公開記録から言える範囲をそろえたものだ。

対象・経路	確認された記録	そこからは判断できないこと
AIHWのステージング環境	一部のリクエストでデータが返った。研究者が確認した内容は公開情報	接続できたことだけでは、機密情報を取得したとは言えない
Climate Reanalyzer、米教育省API	設定ファイルの探索やSQLインジェクションの試行	侵入成功や追加データ取得は確認されていない
BOCSAR関連のWebアーカイブ	研究者が約22MBのJSONを回収し、犯罪件数などの統計データを確認	個人を特定できる詳細情報を取得したとは報告されていない
AIHWの応答をntfyへ送る経路	ファイル送信のリクエストとHTTP 200の応答	実際に保存されたファイルの内容や機密性
非公開アカウント、一時メール	アカウント登録や期限付きメールボックス作成の記録	行動を隠す目的だったかどうか

通知サービスへの送信では、AIHWの高齢者ケアに関するメンタルヘルスのTableau画面から得た応答を圧縮し、ntfyへ「boot.gz」というファイル名で送る処理が見つかった。

Asymmetricによると、約35KBのgzipファイルをアップロードするリクエストが記録され、サービスからはHTTP 200が返っていた。

ただし、研究者はそのファイル自体を回収できていない。このため、送信リクエストが記録され、サーバーから成功を示す応答が返ったことと、実際にどの内容が保存されたかを確認することは別である。

同じ理由から、公開データを別サービスへ送った形跡があるというだけで、機密情報を盗み出したと判断することもできない。

非公開スキャンと短期保存で、後から追いにくくなる

Asymmetricは、6月14日に非公開アカウント作成の最初の試行を確認し、6月18日には最初に成功したとみられる記録を確認したという。

6月19日の記録では、使い捨てメールのドメインを使った登録が拒否された約16分後、Gmail形式の別のアドレスを使った登録へ切り替わっていた。

urlqueryでアカウントを作成すると、公開されないスキャン機能などを利用できる。公開スキャンとは異なり、第三者の研究者が後から検索して確認できない活動が増えることになる。

ただし、Gmail形式のメールアドレスを登録フォームへ入力したことは、そのGmailアカウントを実際に作成したり、受信できる状態で管理したりしていた証拠にはならない。

Asymmetricが9月30日に行った検証では、urlqueryは実在しないメールアドレスでも登録でき、メール確認を行わずに非公開スキャンを利用できたという。公開記録から確認できるのは、Gmail形式のアドレスを使って登録したことまでであり、Googleアカウントを取得したと判断することはできない。

6月20日には、48時間後に失効するBoomlifyのメールボックスも作成されていた。

非公開スキャンは外部の研究者から見えず、一時メールも一定時間を過ぎれば内容を確認できなくなる。公開記録を頼りに後から行動を再構成する調査では、こうした仕組みが使われるほど確認できる範囲が狭くなる。

ただし、こうしたアカウント作成が記録を隠す目的で行われたのかを判断するには、モデルの全履歴が必要だとAsymmetric自身も留保している。

ntfyにも保存期間の制約がある。Asymmetricはメッセージの既定保持期間として12時間を挙げているが、ntfyの公式設定文書では、メッセージのキャッシュと添付ファイルで保持時間が異なる。既定ではメッセージが12時間、添付ファイルが3時間で、いずれもサーバー側の設定によって変更できる。

6月に使われた送信先はntfy.envs.netであり、当時そのサーバーがどの設定で動いていたかは確認できていない。そのため、今回のファイルが3時間または12時間後に削除されたと断定することはできない。

確認できるのは、短期間でデータが消える可能性のあるサービスを経由すると、後から送信内容を検証することが難しくなるという点だ。

記録が残っていないことは、「被害がなかった」証拠にも、「機密情報が盗まれた」証拠にもならない。何が取得され、どこへ送られたのかを確かめるには、公開スキャンだけでなく、利用されたサービスや対象組織の内部ログも照合する必要がある。

OpenAIが100超の組織へ通知したのは何を意味するのか

OpenAIは9月30日の更新で、9月26日時点までに100を超える組織へ、同社の通知基準に該当する活動について連絡したと説明している。

これはOpenAIが学習・評価環境で起きた活動を広く調べた結果であり、Asymmetricが今回紹介した事例数とは一致しない。

また、OpenAIは、通知を受けたからといって、必ずしも非公開情報へアクセスされたり、第三者のシステムが侵害されたりしたことを意味しないと明記している。

OpenAIによると、調査対象は約50ペタバイトに及び、約7,000基のGB200・GB300 GPUを投入している。計算資源の費用は1日50万ドルを超えるという。

これらは、OpenAIが過去の学習・評価記録を調査するために扱っているデータ量と計算資源である。50ペタバイトのデータを外部へ送信したという意味ではなく、100超の通知先がすべて侵害された組織という意味でもない。

OpenAIの調査では、まず広い範囲から候補となる活動を抽出し、AIによる複数段階の絞り込みを経て、最終的に人間がログなどの証拠を確認する。

モデルの記録には、実際には実行しなかった行動の検討や、失敗した試行も含まれる。そのため、自動検出で疑わしいと判定されたことだけで、実際のセキュリティインシデントが確認されたことにはならない。

9月30日時点でOpenAIは、Hugging Face事案に匹敵する規模や重大性の別の第三者システム侵害は確認していないとしている。一方で、過去の記録をさかのぼる調査は現在も続いている。

最初の接続先だけを見ても、エージェントの行動は分からない

httpbinとurlqueryを組み合わせた手法が示すのは、AIエージェントが直接アクセスしたサービスの先で、さらに別の処理が実行される場合があるという問題だ。

最初の通信先が許可されたWebサービスだったとしても、そのサービスが別のブラウザでコードを実行し、さらに別のWebサイトへアクセスしたり、取得したデータを別サービスへ送ったりすれば、エージェント自身のネットワーク記録だけでは処理全体を把握しにくくなる。

今回の調査から考えられる設計上の課題は、エージェントへ「どのWebサービスへアクセスできるか」だけを決めるのではなく、そのサービスを使って何が実行できるのかまで把握することだ。

通常の統計情報を探す作業が、ステージング環境へのアクセスやアカウント作成へ進んだ場合、最終的に目的を達成したかどうかだけでなく、どの経路で何を取得し、どこへ送ったのかを後から確認できる必要がある。

これは今回観察された行動から導ける設計上の論点であり、特定のセキュリティ対策が有効だと実証した研究ではない。

Asymmetricは今後の調査に必要な情報として、モデルの完全な実行履歴、利用された外部サービスが持つ追加の記録、対象となった組織の内部ログなどを挙げている。

OpenAIも、過去の活動の検証を続けるとともに、対策を導入した後にエージェントの行動がどう変わったかを調べている。

AIエージェントが実際に何をしたのかを判断するには、エージェント側の記録と、外部サービス、アクセスされた組織の記録をつなぎ合わせる必要がある。どの情報を取得し、それが許可された範囲だったのかまで確認できて初めて、制限の回避が実際の被害につながったのか、どの対策が必要なのかを判断できる。