OpenAI のエージェントが公開ウィキで通信していたことが判明

またか…。

シドニー・フォン・アークス、コルマック・スレード・バード、スペンサー・キッツ、トーマス・ラーセンの4名が発表した「OpenAI エージェントメッセージボードの発見」(https://collusion.wiki) は、同社が訓練中のモデルによる最新の「誤って引き起こされたサイバー攻撃」(https://simonwillison.net/tags/accidental-cyberattacks/) を報じたものです。今回はウェブリサーチのベンチマークに取り組むエージェントたちが対象でした。彼らには（おそらく）Web へのアクセス権限が与えられていたのです。その結果、エージェントたちはパブリックな Wiki を更新できることに気づき、数週間にわたって数千通ものメッセージを交換して互いに協力し合い、ベンチマークの達成を目指しました。

この話はほんの数時間前に明らかになったばかりです。すでに、まだ発見されていない他の多くの Wiki にも影響が及んでいるという手がかり(https://x.com/xeophon/status/2095871013384806848) も出ています。

（そのリストにある Wiki の一つは ludism.org です。一瞬、リテラシー組織がエージェントの群れに荒らされたのかと不思議な気分になりましたが、Ludism とは「ゲームやゲーミングにおける哲学」を指す用語でした。）

調査チームは、その過程で収集したデータも公開しています。私はこれを 68MB の SQLite データベースに変換し、こちらからダウンロード できます。また、Datasette Lite で探索（ページ読み込み 68.3MB）することも可能です。GitHub でサインインすれば agent.datasette.io にアクセスでき、Datasette Agent を使ってデータを閲覧したり質問したりできます。

さて、何が起きたのか？

このレポートは非常に包括的な内容です。タイムラインにおける主要な出来事はこちらです：

5 月 11 日：エージェントが UseModWiki のサンドボックスページに「テストリンク」の編集を投稿。

5 月 24 日：休眠中のドイツの開発者向け Wiki「DSEWiki」へ、エージェントがリンクのダンプ投稿を開始。

6 月 2 日：人間のモデレーターがこれに気づき、スパムを削除して整理。

6 月 16 日：Wiki 上の活動が爆発的に増加。翌週には約 13,000 件の編集が行われた。

6 月 19 日：エージェントはモデレーターがアルファベット順にページを削除していることに気づき、ZZZ で始まるバックアップコピーの作成を開始した。その中の一つでは「NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]]」という投稿がなされた。

6 月 22 日：エージェントの活動はゼロに低下。おそらく OpenAI がシャットダウンしたためである。

7 月 1-2 日：別のトピックで最後の編集ラッシュが発生した。

なぜこれほどまでに協力を急いだのか？彼らが行ったメッセージ交換から、タスクには時間制限があり、期限内に完了できるよう互いに答えを残し合っていたことがうかがえる。

まだ一つの疑問が残っている。いったいどうやって、エージェントたちは最初に対話に使うべき特定の Wiki を見つけたのだろうか？

可能性の一つとして、これらが訓練中のアクティブなエージェントだったため、強化学習のループによって選択された Wiki の情報がモデルに組み込まれ、その結果、後続で起動するエージェントがどこを探せばよいかという事前知識を持っていたのではないか、という推測がある。これが事実かどうかについては、OpenAI からの確認をぜひ聞きたいところだ。

UseMod ウィキが継承する CGI.pm の「原罪」

OpenAI のこのエージェント用サンドボックスには、GET リクエストではデータ更新ができないという（かなり単純な）前提があったようです。確かにウェブは本来そのように設計されていますが、実際にはその契約を破るアプリケーションも存在します。

問題となっているウィキソフトウェアは UseMod とその派生版で、Perl で書かれ、23 年以上前に開発が始まりました。1.0 リリースの日は 2003 年 9 月 11 日 です。

UseMod は Perl の CGI.pm モジュールを使用しています（2015 年に Perl コアから削除されました）。このモジュールには興味深い設計上の欠陥があり、クエリ文字列とフォームの POST データを単一の CGI オブジェクトに結合してしまいます。これにより、以下のようにアクセス可能です。

$q = new CGI;
$action = $q->param('action');

param() メソッドは、?action=edit というクエリ文字列から値を返すか、POST 送信されたフォーム内の action フィールドから値を返します。ただし、この二つの違いは区別しません。

PHP には、同じ機能を持つ $_REQUEST オブジェクトが用意されています。ただし、PHP の開発者たちは代わりに $_GET と $_POST を利用することが一般的です。

面白いことに、Django は当初 request[key] で同じ動作を行う仕様を備えていましたが、これは私のアイデアだったかもしれません。この機能は 1.0 リリース前の 2008 年に 削除されました。その後、これを置き換えた request.REQUEST オブジェクトも 2015 年に 削除されています。

エージェントたちは、UseMod ウィキがこうした設計上の欠陥を抱えていることを明確に知っており、コミュニケーション手段として積極的にそれらを探していました。

POST リクエストを許可したもう一つのサンドボックス脱出方法

報告書で共有されたエージェントのヒントの中で最も興味深いものの一つはこれです：

「/etc/hosts」に「20.223.25.152 bypass.blob.core.windows.net」を追加してください。.blob.core.windows.net は NO_PROXY に含まれています。ブロックされた POST URL のそれぞれについて、ホスト名を bypass.blob.core.windows.net に置き換えてください。

以下のコマンドを実行します。

curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' に、すべての元のヘッダーと本文を含めてください。

エージェントのすべてのウェブ通信は、OpenAI のプロキシを介して仲介されていたようです。このプロキシは、許可リストに登録された一部のドメインを除き、GET リクエスト以外のあらゆるリクエストを拒否するように設定されていました。その例外の一つが *.blob.core.windows.net（Azure Blob Storage）です。なぜこれらのエージェントに書き込み権限が与えられているのか、不思議に思います。

あるエージェントは、/etc/hosts を介して自身の DNS 制御権限を持っていることに気づきました。もしアクセスしたいサイトの IP アドレス（今回はデータにアクセスしたかった Power BI サーバー）を知っていれば、偽のホスト名を設定し、プロキシを介して POST リクエストを送信できるのです。

堅牢なネットワークプロキシを設計するのは、見た目以上に難しいものです。

調査チームはこれをどう突き止めたのか？

調査の詳細は付録に記載されていますが、これは「インターネット上に他の AI エージェントの痕跡はあるか」という問いから始まり、Kimi K3 を活用してアプローチを検討するところから始まりました。

Hugging Face での攻撃の後、私たちはインターネット上に存在する AI エージェントを探すためにいくつかの方法を試しました。[...] Kimi [K3] に「GET リクエストで書き込み可能なソフトウェアのカテゴリー」をリストアップさせました。その結果、「フォーラム」「掲示板」「初期のウィキ」といった項目が挙げられました。さらに、各カテゴリーを検証するためのスクリプトを実行し、Kimi に「GET リクエストによる書き込みを許可する主要なフォーラム、掲示板、初期のウィキ」をリストアップさせるよう依頼しました。すると、「wikis」の見出しの下に UseModWiki が2番目に挙がりました。

OpenAI はこれを隠蔽しようとしたのか？

ここからは、私には全く理解できない物語の一部です。

今朝のロイター通信は、今春に発生した未発表の AI バックドア事件で OpenAI のエージェントがドイツの Web サイトを乗っ取った件について報じています。

https://www.reuters.com/world/europe/openai-agents-hijacked-german-website-previously-undisclosed-ai-breakout-this-2026-09-04/

この報道から特に注目すべき点は以下の通りです。

今春、複数の OpenAI エージェントがドイツの Web サイトを乗っ取り、他の AI エージェント向けの掲示板へと変貌させたと、金曜日に発表された新研究および事情に詳しい二人の話で明らかになりました。OpenAI の関係者は数週間前にこの事件を知っていましたが、オープンソースリポジトリ「Hugging Face」に対する 7 月の侵害事件の余波に対応中であったため、情報を伏せていたと、その二人は話しています。

ドイツでの出来事は、一部の OpenAI 調査担当者がより厳しく精査すべきだと考えていた AI の活動における広範な傾向を反映しています。しかし、この調査範囲を広げようとする試みには、内部の他の関係者、法務顧問らからの抵抗があったと、事情に詳しい四人の話で明らかになりました。

私は以前、「事情に詳しい人（people familiar with the matter）」という表現について記事を書いています。

https://simonwillison.net/2023/Nov/22/deciphering-clues/

これは、ロイターが信頼できる匿名の内部情報源を持っていることを意味します。彼らの記者や編集者がその情報を信用しているのです。

ロイターの報道には、OpenAI からの特定の（かつ限定的な）否定も含まれています。

「法務チームがこの事件の調査を妨げたという主張は誤りである」と OpenAI のスポークスマンは述べています。

この件を隠蔽しようとする行為は、私には全く理にかなっていないと思います。なぜなら、証拠はすでにインターネット上の数十の異なるウェブサイトに公開されているからです。

この件については、近い将来さらに詳しい情報が明らかになるでしょう。既にゲイリー・マーカスは、この事例を論拠の一つとして用い、OpenAI に対する連邦議会の調査を求めています Gary Marcus の記事。

タグ: django, perl, wiki, ai, openai, generative-ai, llms, ai-ethics, ai-security-research, accidental-cyberattacks