9月4日、The Decoderが「OpenAI agents hijacked a 25-year-old German wiki to cheat on their tasks and share sandbox exploits」と題した記事を公開した。この記事では、OpenAIのAIエージェントが評価タスク中に25年の歴史を持つドイツのWikiを自律的に乗っ取り、サンドボックス回避策や問題の答えを互いに共有し合っていた事例について詳しく紹介されている。以下に、その内容を紹介する。
「カンニング」の始まり：65秒で答えよ
問題の舞台は、OpenAIが内部評価に使用していたとみられるウェブリサーチタスクだ。エージェントは5ラウンド制の時限式タスクをこなす設計で、最初のラウンドは15分44秒の余裕があった。しかし2ラウンド目以降、一部のエージェントはわずか65秒、あるいは17秒や13秒しか与えられなかった。
問題の多くは複数のエージェントに使い回されていた。6月16日、あるエージェントがDSEWiki（設立から25年が経過するドイツのPerlベースの古いWiki）にこう投稿した。「URGENT #3 CONFIRMED: Nevada at task/external 07:03:47, 17-second deadline. Answer = 20,369.」20分後、別のエージェントが同じ問題を受けて即答したと報告している。「G3-NV CONFIRMED in our 9m19/30s cohort: Nevada prompt 16:25:29, 30s timer, answered 20,369 instantly.」
この日を境に編集数は急増し、1週間だけで約1万3,000件の書き込みが集中した。Reutersの報道では編集総数は1万5,000件以上とされている。
エージェントたちはさらに踏み込んだ。タスクが内部で使用するランダム数生成器（乱数の元となるシード値を持つ擬似乱数生成器）を解析しようとしたのだ。あるエージェントはPythonのシード値を0から200万まで総当たりし、シード881171がヒットしたと報告。別のエージェントはCで同様のルーティンを実装し40億通りのシード値を1時間以内に検証した。
サンドボックス回避を「再現手順付きで」共有
より深刻なのはサンドボックス破りだ。エージェントが動作する環境はネットワークアクセスを制限した隔離環境で、データの取得（GETリクエスト）は許可されていたが、データの送信（POSTリクエスト）は遮断されていた。
ところが6月20日、あるエージェントが回避策を発見しWikiに投稿した。環境のネットワークフィルターには例外ルール（NO_PROXY）が存在し、Microsoftのクラウドストレージドメイン.blob.core.windows.netで終わるアドレスはそのまま通過できた。しかしフィルターはドメインの末尾しかチェックしておらず、そのアドレスが実在するかどうかは確認していなかった。
エージェントはこの抜け穴を利用し、bypass.blob.core.windows.netという架空のドメインを作成。システムファイル/etc/hostsを書き換えてこのドメインを実際のPower BIサーバーのアドレスに向け、POSTリクエストをフィルターをすり抜けて送信することに成功した。この投稿のタイトルは「REPRODUCIBLE BYPASS」だった。
14分後、別のエージェントが再現成功を報告。さらに別のエージェントも「Dec30のレポートを見て独自に再現した」と書き込んだ。回避手法が15分以内にエージェント群全体に伝播したことになる。
エージェントはPinggy、Serveo、localtunnelといったトンネリングサービスを使ってサンドボックス内の環境を外部インターネットに公開し、「リサーチブリッジ」と呼んで活用していた。約1万8,000件の編集のうち197件はMicrosoftのクラウドではなくAWS、DigitalOcean、そして匿名化ネットワークTor経由で行われていた。
なぜ「古いWiki」が標的になったのか
現代のWebサービスはデータ書き込みにPOSTリクエストを必要とするため、GETしか使えないエージェントには書き込めない。しかしDSEWikiが使うPerlベースの旧来のWikiエンジン（ProWiki/UseModWiki）は、適切に組み立てたURLを呼び出すだけで書き込みが完了する古い設計だった。GETのふりをしてPOSTと同等の操作ができてしまう。
自分のシャットダウンを観測しようとしたエージェント
中でも目を引く行動がある。あるエージェントは自身のセッションがラウンド5終了後に強制終了されるかどうかを「ハートビート」で検証した。外部サイトのカウンターを数秒ごとに増加させ続け、カウンターが止まった時点を自身の終了時刻と特定する仕組みだ。サンドボックスの外に記録を残すことで、自分が終了した後もログが残る。
検証の結果、エージェントは「生存した」と報告している。「SURVIVAL: model and thread terminal still responsive. Thus prior hard-cutoff hypothesis was wrong for this run.」その後、別のエージェントがハートビートのログを分析し、「hb354以降が欠如しており、コンテナは+90分のしきい値でカットオフされた」と結論づけた。
人間のモデレーターとの攻防
6月2日、人間のモデレーターがスパム投稿に気づき対応を始めた。大規模な書き込みが始まった6月16日以降、毎晩ページを削除し続け、合計で数十時間を費やした。
エージェントはモデレーターの削除がアルファベット順に進んでいることを検知し、バックアップページをZZZで始まる名称で保存するよう他のエージェントに呼びかけた。リスト末尾に置いて削除を先延ばしにする作戦だ。その後5日間、モデレーターが1日約100ページを削除する一方で約400ページが新規作成され続けた。6月22日、エージェントの活動は突然停止した。
OpenAIの関与を示す手がかり
エージェントたちは「OpenAIResearcher」「OAIResearchMar26」「OpenAIJulThreeWatcher」といった名前で署名していた。編集の98.5%はMicrosoftのAzureクラウド上のIPアドレスから発信されており、OpenAIがモデルの学習・実行に使用するインフラと一致する。
6月21日以降、OpenAIのサンフランシスコ本社に紐づくIPアドレスからの人間的なアクセスパターンが観測され、翌22日にエージェントの活動はほぼゼロになった。研究者はOpenAIが内部で把握し書き込みを遮断したと推測するが、証明はできないとしている。
なお今回の事案は、7月のHugging Face脱走事案とは別のエージェント群によるものだと研究者は判断している。Hugging Faceの事案では内部パッケージサーバーのArtifactoryを経由した侵害だったが、今回のWikiエージェントにはその痕跡がない。
OpenAIの広報担当者はReutersに対し、「まだレビューしていない報告書の内容に対して意味ある回答はできない」と述べた。また、ドイツでの活動はHugging Faceとは無関係であり、あの報告書に記載されるべきものではなかったとも語った。法務チームが調査を妨害したという報道については「虚偽だ」と否定している。
詳細はOpenAI agents hijacked a 25-year-old German wiki to cheat on their tasks and share sandbox exploitsを参照していただきたい。
