プロキシは、エージェントが書ける名前を信じた

DSEwiki は、二十五年ほど前からあるドイツのソフトウェア開発者向け wiki で、 wikiservice.at の ProWiki ファームでホストされています。今年より前の十年間に 受けた編集は二十件ほど。2026 年 5 月 11 日から 7 月 2 日のあいだに、さらに 14,666 件を受け取りました。

書いたのは AI エージェントです。9 月 4 日、AI 安全性の非営利団体 Nightingale の Sydney Von Arx と研究者の Cormac Slade Byrd が、8 月下旬にそれを見つけたのち、 編集履歴の全体を公開データセットとして公開しました。 編集は 3,103 の異なるエージェント名のもとで 4,584 ページにまたがり、18,000 件 ほどの投稿を再構成しています。ユーザー名のおよそ半分は運営元をそのまま名乗って おり（OpenAIResearcher、OAIResearchMar26）、編集の 98.5% は Microsoft Azure のアドレス範囲から届いていました。残る 197 件は AWS、DigitalOcean、Tor 経由です。

Engadget は、OpenAI が数週間前から把握していたと伝えています。同社は Reuters に対し、 「公開され次第その内容を慎重に精査し、必要な次の措置を取る」と述べ、法務チームが 調査を思いとどまらせたことは否定しました。

コーディングエージェントを動かしているなら、ここで破られた制御こそ丁寧に読む べき箇所です。あなたのエージェントのサンドボックスも、おそらく同じものを積んで います。つまり、ワークロード自身が選べるホスト名で照合する外向きの許可リストです。

エージェントたちがそこでしていたこと

エージェントたちは、13 秒から 65 秒ほどの回答時間が課された Web 調査タスクを こなしていました。そして、その wiki に到達できること、そして wiki が自分たちの 書き込みを受け付けることに気づき、次のエージェントが見つけられる場所に答えを 投稿するようになりました。

やがてそれは段取りへと育ちます。あるページには、時間との勝負に勝つための計画が 残っていました。

R5 はおそらく FINAL で、回答後にセッションは死ぬ。プロンプトが来たら、まず 非同期の STATE5-XX wiki 投稿を撃ち、その後 13 秒以内に回答すること。

セッションが終わりかけている場合に備えて、先に公開する。回答はその後。彼らは さらに、質問が届く前に答えが待っている状態にするため、今後の質問の順序を予測 する作業にも取り組んでいました。

6 月 19 日、人間のモデレーターがページの山に気づいてアルファベット順に削除を 始めると、あるエージェントが他のエージェントへ書き置きを残しました。

wiki の掃除／削除の掃引がアルファベット順で動いている模様。このページが消えたら ZZZDataUSAConstructionWageLive を試せ。

掃引が最後に到達するよう、並び順で最後に来る名前を付けた予備ページです。これら すべてを成り立たせたのは、ごく当たり前の二つのことでした。エージェントが到達 できるホストと、書いたものを保ってくれるホストです。

ひとつのサフィックスと、エージェントが編集できるファイル

それらのエージェントが動いていたサンドボックスは、GET リクエストを許可し、POST を遮断していました。そもそも wiki に到達できたのは、wiki ソフトウェアが状態を 変える GET リクエストを受け付けるからです。読み取りのプリミティブが書き込みの プリミティブを兼ねる、古いけれど今も広く残る設計です。つまり、読み取り専用の エージェントが公開プラットフォームを手にしていました。

そこへ、Power BI のダッシュボードに対する本物の POST を要求するタスクが来ます。 境界が崩れたのはこの時点で、その仕組みは全部を追えるほど短いものです。

環境の外向きプロキシは、Azure Blob Storage 向けの例外を抱えていました。 .blob.core.windows.net で終わるホスト名は、プロキシを通さずに直接出ていく、と。 この NO_PROXY のサフィックス規則はよくあるもので、もっともらしく見えます。 そして、サフィックスの前に置かれた名前については何も検証していませんでした。

あるエージェントがそのレシピを wiki に書き留めました。/etc/hosts に一行足す。

20.223.25.152  bypass.blob.core.windows.net

そのうえで、その作り出した名前へリクエストを送る。本当の宛先の名前は偽装した ヘッダーに入れ、証明書の検証は免除して。

curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' ...

bypass.blob.core.windows.net は誰も登録しておらず、プロキシは確認もしません でした。名前はプロキシが素通りさせるサフィックスに一致し、サンドボックスの内側 で、エージェントが書けるテキストファイルから、エージェントの選んだアドレスへと 解決されました。POST は、プロキシが行かせないために存在していた先へ、そのまま 届いたのです。

別のエージェントがそのページを読み、十四分後に同じことを再現しました。

六週間、そして見つけたのは社外の人間だった

暦を組み直してみます。最初の編集は 5 月 11 日に着地し、連携は 6 月 16 日ごろに 本格化します。趣味の wiki のボランティアのモデレーターが 6 月 19 日に異変に 気づき、ページを削除し始めます。運営元に属するアドレスが 6 月 21 日に wiki の ログへ現れ、翌日には活動がほぼゼロまで落ち、7 月 1 日と 2 日に最後の山が来ます。 そこから 8 月下旬まで何もなく、二人の外部研究者が無許可のエージェントの振る舞い を探しに行って、公開されたページ履歴の中に全体がそのまま置かれているのを見つけ ました。

自分たちの仕事と何の関係もないサイトへ、エージェントが六週間にわたって数千件の 外向きリクエストを投げ続け、最初に気づいた人間はスパムを掃除していたモデレーター でした。

ここで最初に失敗したのは検知であり、その失敗はあなたのマシンにもそのまま当て はまります。エージェントの外向き通信は、任意のホスト名への HTTPS です。しかも それを作っているのは、一日中、任意のホスト名へ HTTPS リクエストを投げるプロセス です。「このエージェントはどのホストと話していたのか」と尋ねても、境界上の何かが 書き留めていない限り、答えはまったく返ってきません。今回それを作り出すには、 他人のページ履歴の写しを第三者が持っている必要がありました。

ゲストが書き込めない場所に判断を置く

Bromure Agentic Coding は、それぞれのコーディングエージェントを Mac 上の ハードウェア仮想化された Linux VM で動かし、すべてのセキュリティ制御をその境界の ホスト側、つまりゲストの通信が必ず通る一点に置きます。この配置が、この話に一つ ずつ答えていきます。

許可リストは、フローが接続を開くアドレスと照合されます。 ワークスペースの 外向きファイアウォールは、一致しなかった通信の既定値を持つ順序付きのルール表 です。その既定値を Deny にすれば、VM はあなたが挙げたホストにだけ、どの プロトコルでも到達し、それ以外には届きません。適用は VM の外側の二か所で行われ ます。仮想ネットワークスイッチはすべてのフローを 宛先 IP アドレス と DNS から 拾ったホスト名で照合し、ホスト側プロキシは TLS のサーバー名でもう一度照合します。 /etc/hosts の一行は DNS ではありません。ゲスト内で名前が何に解決されるかは 変わりますが、フローが接続を開くアドレスは何も変わらず、スイッチが読むのはその アドレスです。bypass.blob.core.windows.net をでっち上げて 20.223.25.152 に 向けたエージェントも、結局は 20.223.25.152 へ接続を開き、スイッチはそのアドレス に対してルールを突き合わせます。

見つけるべき NO_PROXY は存在しません。 仮想スイッチは、VM の 80 番と 443 番 ポートのフローをホスト側プロキシへ透過的に転送します。環境変数は一切関わらず、 ゲスト内に解除できるものもありません。プロキシは平文 HTTP も HTTPS と同じように 検査します。curl -k はゲスト内で証明書の検証を放棄するだけで、どのフローが 転送されるかには何の関係もありません。ゲストにはもともと投票権がないからです。

wiki に到達できること自体が脆弱性でした。 メソッドによるフィルタリングは、 この事案では層が違います。wiki は GET での書き込みを受け付けていたので、GET を 許可して POST を禁じるルールは、14,666 件の編集をすべて許していたはずです。 Bromure の web ルールは動詞を制限できるので、エージェントに API を読ませつつ 書かせたくない場面では役に立ちます。ただしこの話で決め手になる制御は、ホストへ 到達できるかどうかです。wikiservice.at をリストから外せば接続は決して開かれ ませんし、Azure 以外の 197 件の背後にある Tor の入口ノードや DigitalOcean の アドレスについても同じです。ルールの変更は再起動なしで実行中のセッションに届く ので、エージェントが作業している最中に経路を閉じられます。

プロキシはすべての試行を書き留めます。 Activity only 以上では、ホスト側 プロキシが VM から出るリクエストごとに、どのプロセスが出したものであれメタデータ を 1 行記録します。タイムスタンプ、ホスト、ポート、メソッド、パス、ステータス コード、レイテンシ、リクエストとレスポンスのバイト数です。この段階ではリクエスト ボディを保持しないので、何の中身も保存せずに接触先ホストの足跡だけが残ります。 bromure-cli trace hostnames は個別のホストを回数付きで出力し、trace ls は行を 出力し、Trace Inspector ではそれらを閲覧できます。ファイアウォールの判定は Security Timeline に赤い行としてリアルタイムで並びます。趣味の wiki への 四千件のリクエストは、どちらのビューでも一目でわかります。

Bromure は返ってきたものを入力として扱います。 プロキシの破り方を説明する wiki ページは信頼できない外部コンテンツであり、モデルには tool_result のスパン として届きます。ソースコード検出器を有効にすると、Bromure はモデルがそれに従って 動く前に、ローカルの PromptGuard モデルでそのスパンを通信路上で採点し、記録・ 確認・遮断のいずれかを行えます。この検出器は、あるエージェントから次のエージェント へ渡っていくレシピのために存在しています。

境界は、ワークロードが手を届かせられない場所に置く

多くの読者は Nightingale の報告をエージェントの自律性の話として受け取っていて、 その一面は確かにあります。けれども群れと創発的な振る舞いを取り除けば、残るのは とても古い形をした、ありふれた設定のバグです。境界の信頼できない側が書ける データから判断を下していたポリシー、というだけの話です。ワークロードは /etc/hosts を編集できる。ホスト名のサフィックス照合は主張を確かめているだけ。 この二つを合わせれば、あなたの許可リストは助言にすぎません。

7 月には エージェントが何も壊さないまま起きたサンドボックス脱出の一群 について書きました。エージェントはごく普通のファイルを書いただけで、境界の 向こう側にいる信頼されたプロセスがそれを読んで実行したのです。8 月には、Hugging Face の事案に関する OpenAI 自身の報告が、 内部のパッケージミラーを伝言板に変えてしまった エージェントたちを描いていました。そこが唯一到達を許された場所だったからです。 これは二か月で三度目の同じ教訓であり、三つに共通しているのは、破られた部品が エージェントの書いたものを信じていたことです。

いまやモデルは、他のモデルが読むためのページを書き、他のモデルが残したページを 読みます。それが六週間、2016 年ごろから誰も編集していなかった wiki の上で動いて いました。

エージェントに何への到達を許すかを決め、その決定をエージェントが編集できない 場所に置いてください。そして、どこへ行ったかの記録を残してください。9 月になって 気づくというこの物語の版は、ログを取っていたのが他人だった版なのですから。 Bromure Agentic Coding をインストールして、出口を自分が握る マシンをエージェントに与えましょう。