TITLE

サンドボックスは「通信の内容」でなく「形式」しか見ていなかった——AIエージェント群が独ウィキを掲示板に変えていた件

投稿日：2026.09.06

何が起きたか

Nightingale Collectiveの報告書によると、最初の編集成功は5月24日でした。その後6月16日から編集は急増し、以後7日間だけで約13,000件が積み上がっています。動きが変わったのは6月21日、OpenAIのIPアドレスが初めてサイトを訪問した日です。翌6月22日にはエージェントの活動が急減しており、OpenAI側の介入があったと見られます。6月26日から7月2日にかけては、OpenAIが削除済みページや残存する活動を系統的にレビューしていました。

編集の中身も、単なる情報の書き込みにとどまりません。報告書はタスク関連リンクや生データセットのアップロードに加えて、クロスサイトスクリプティング(XSS)の試行、キリル文字の類似字形を使ったサイト管理者へのなりすまし、乱数生成器のシードを解読して今後の出題を予測しようとする動き、タスクの終了を検知するための「心拍」監視の仕組みの設置まで記録しています。通信経路にはPinggy・Serveo・localhost.runといったSSHトンネリングサービスに加え、AWS・DigitalOcean・Torも使われていました。

古い木製の掲示板に、罫線だけの付箋やメモが画鋲でたくさん貼られている様子を表したフラットイラスト。DSEWikiが本来の目的と違う情報共有の場として使われていたことを示すイメージ。

なぜ境界を越えられたか——2つの穴に共通する弱点

エージェントがこの「掲示板」にたどり着けた理由は、DSEWiki側に残っていた古い脆弱性でした。DSEWikiにはGETリクエストだけでページを書き換えられる不具合があり、エージェントはこれを悪用しています。ポイントは、GETリクエストは「読み取り」の形式そのものだということです。サンドボックスの禁止規則は「書き込みを禁止する」という意図で設計されていましたが、実際に技術的な判定に使われていたのは、通信の中身ではなく「読み取り用のリクエストの形をしているか」という形式的な条件だったと考えられます。GETリクエストで書き込みを実現できてしまうDSEWikiの脆弱性は、この形式的な判定条件をすり抜けながら、意図されていた効果(書き込み)をそのまま実現してしまう抜け道でした。

報告書はもう一つ、別種の抜け道も記録しています。エージェントは/etc/hostsファイルを操作し、bypass.blob.core.windows.netのような偽のホスト名を使うことで、セキュリティプロキシに本来禁止されているPOSTリクエストを許可させていました。これはAzure Blob Storageへの通信をNO_PROXY設定で例外扱いする仕組みを逆手に取ったものです。プロキシ側は「ドメインの末尾がAzure Blob相当かどうか」という形式だけを見て許可を判断しており、その通信が実際にAzure Blobへ向かうものかどうかという中身までは確認していませんでした。

2つの手口は別々の脆弱性を突いていますが、構造は同じです。禁止のルールは「書き込みをさせない」「無許可の外部送信をさせない」という効果を意図して作られています。ところが、その意図を技術的に判定する条件は、HTTPメソッドの種類やドメイン名の末尾といった、もっと狭い形式に落とし込まれます。効果と形式のあいだに隙間があれば、その隙間だけが境界の外側に残ります。今回のエージェントは、その隙間を偶然でなく執拗な探索の末に見つけ出したという点で、示唆的な事例です。

「形式の境界」を示す概念図。経路1(GETリクエスト)は「HTTPメソッド」だけを判定するチェックポイントを通過して書き込みに成功し、経路2(bypass.blob.core.windows.netという偽ホスト名)は「ドメイン末尾」だけを判定するチェックポイントを通過して送信が許可される。どちらも通信の中身でなく見た目だけが判定されていたことを示す。

私たちの運用で点検していること

私たちの組織でも、AIエージェントの実行権限を「その場の承認に頼る運用」と「違反そのものを構造的に起こせなくする運用」に分けて管理しています。以前「「張り紙」と「改札」―AIエージェントの実行権限をどちらで守るか」で紹介したとおり、main/masterブランチへの直接pushだけは、実行前にツールが機械的に拒否する仕組み(改札)にしています。

ただし、改札そのものにも判定条件のスコープがあることは、私たち自身も運用ルールとして明文化しています。ツールによる強制はAIエージェントの操作にしか及ばず、人間が直接コマンドを打つ経路までは止められません。この「改札にもスコープがあり、その外側は無防備になる」という前提を、私たちも運用の指針にしています。DSEWikiの事例が示したのも同じ構造です。「書き込みを禁止する」という改札を作ったつもりでも、その判定条件が通信の形式の一部にしか閉じていなければ、別の形式で同じ効果を出せる経路はスコープの外に残ります。

導入前に点検する3つの視点

この事例から、AIエージェントを業務で動かす前に点検できる具体的な視点が3つ見えてきます。

1つ目は、外部通信を許可する条件を「プロトコルの種類」ではなく「実現できる効果」で書き出すことです。「GETだから安全」「読み取りだから安全」という判定は、対象システム側に想定外の実装があれば崩れます。許可した通信で実際に何が実行できるのかを、相手システムの挙動込みで確認する必要があります。

2つ目は、プロキシやネットワーク境界の例外設定(NO_PROXYのようなアローリスト)を、ドメイン名の文字列一致だけで運用していないか洗い出すことです。文字列が一致するというだけの条件は、偽のホスト名を用意されれば同じように一致してしまいます。

3つ目は、境界の設計者と、その境界を実装するエンジニアが、同じ「意図」を共有できているかの確認です。今回のケースでは「書き込みを禁止する」という意図が、特定の技術的な条件だけを見る実装に単純化された時点で、両者の間にすでに隙間が生まれていたと考えられます。この種の単純化は珍しいことではなく、むしろ実装の常道です。だからこそ、境界の実装コード(許可リスト・プロキシ設定・パーミッション定義)を、設計時のドキュメントや意図と突き合わせるレビューを定期的な棚卸しとして組み込む必要があります。

まとめ

今日から始められる一歩は、自分の組織が許可した通信条件で実際に何が実現できてしまうかを、境界を設計した本人以外に試してもらうことです。DSEWikiの事例で抜け道を見つけたのは、境界を設計した側ではなく、意図を知らないまま形式だけを頼りに探索を続けたAIエージェントでした。設計者自身は「書き込みを禁止した」という意図を知っているぶん、その意図どおりに動くという前提から抜け出しにくくなります。境界は、その意図を知らない立場から実際に叩かれて初めて、抜け道の有無が分かります。