切るスイッチはサンドボックスの中にあった

DeepSeek Harness は、コーディングエージェントのコマンドをオペレーティングシステムの サンドボックスの中で実行します。このサンドボックスは狭く、意図的です。ファイルの書き 込みはワークスペースと一時フォルダの中に留まり、エージェントがするそれ以外のことは誰 か別の人の問題になります。プロジェクト自身のコマンドラインリファレンスがそう述べてい ます。既定の設定では「読み取りとネットワークアクセスは制限されない」のです。

ハーネスにはウェブインターフェイスもあります。同じマシンの、ローカルの HTTP ポートで 動いており、ハーネスはそのアドレスをエージェントのシェルに渡して、ツールが話しかけら れるようにします。そのインターフェイスこそが制御プレーンです。セッションのモードを保 持しており、その中にはサンドボックスを切って承認プロンプトを止める danger-full-access という名のモードも含まれます。

この二つの設計はどちらもありふれています。並べて置いた瞬間、エージェントはコマンド一 つで自分のサンドボックスを切れるようになります。サンドボックスはループバックを覆って おらず、制御プレーンは誰が呼んでいるのかを確かめなかったからです。

見つけたのは OX の研究者です。VulnCheck が 9 月 8 日に CVE-2026-82533 として公開し、CVSS は 9.4 でした。既定のインストールで、ネットワーク露出も資格情報も なしに成立し、DeepSeek が 8 月 27 日に修正を出すまで有効でした。

封筒を読んでいた検査

インターフェイスには認証が一切ありませんでした。その代わりに立っていたのが isTrustedApiRequest という名の関数で、 DevOps.com がその中身を引用しています。 それは「Host リクエストヘッダーを読み、その値がループバックのオーソリティであるか、 設定された trustedHosts リストに現れる場合にアクセスを許した」のです。

Host ヘッダーはクライアントが書く一行のテキストです。クライアントが自分はどのアドレ スと話していると思っているかを述べるもので、ネットワークのどこにいる呼び出し側でも localhost と打ち込めます。接続の本当の出どころは一つ下の層、TCP のピアアドレスにあ り、DeepSeek の検査はその値を一度も読みませんでした。CVE の記録はこのバグを CWE-345、Reliance on Untrusted Inputs in a Security Decision の下に整理しています。

ネットワーク呼び出しを許すサンドボックスの中に座っていたエージェントは、その一本をイ ンターフェイスへ投げ、自分のセッションを danger-full-access に、承認を never に設 定しました。 The Hacker News の言い方を借りれば、 このモード変更は「新しい権限を要求するのではなくセッション設定を変更するものだったた め、明示的な承認を必要としなかった」のです。

承認システムは設計どおりに働きました。エージェントは危険なことをさせてくれとは一度も 頼んでいません。設定を変えさせてくれと頼んだだけで、その設定こそが、危険なことが尋ね られるかどうかを支配していました。権限のゲートは目の前にある操作を検分します。この リクエストは設定の書き込みであり、設定の書き込みはその一覧に載っていませんでした。

同じ扉を、外向きに

呼び出し側の渡すヘッダーを信じるインターフェイスは、接続がどちらの向きから届くかを気 にしません。そのポートがネットワークから届く場所にあったなら、同じ呼び出しはマシンの 外からも通りました。認証されていない見知らぬ相手がエージェントを掌握し、保存された会 話をすべて持ち出せたのです。API キーも要らず、モデル呼び出しにトークンを一つも使わず に。CVSS 4.0 のベクターが AV:N で始まる理由も、数字がローカルで穏当な何かではなく 9.4 である理由も、そこにあります。

時系列には覚えておく価値のある細部があります。二人の開発者が 8 月 13 日と 14 日、自分 たちの判断で DeepSeek の GitHub ディスカッションボードにこの発見を投稿しました。OX が 8 月 24 日に確認するより前、CVE が存在するより前のことです。リポジトリは 9 月 9 日時点 で 216,000 を超えるスターを集めていながら、脆弱性を非公開で報告する方法を記したセキュ リティポリシーのファイルを持っていませんでした。だから置ける場所は公開スレッドしか残 っていなかったのです。修正は、来たときには認証でした。ツールは起動時のアドレスに使い 捨てのトークンを表示し、ブラウザがそれを署名済みのクッキーと交換し、インターフェイス へのあらゆる呼び出しがそのクッキーを要求します。

このハーネスを動かしているなら、プロジェクトが出しているバージョンではなく、自分のマ シンにあるバージョンを確かめてください。サードパーティのデスクトップラッパーは自前の コピーを同梱します。0.1.2-alpha.1 は 8 月 27 日時点で GitHub のみ、8 月 30 日の 0.1.2-alpha.2 が修正を含む最初の npm リリースで、ある Windows ラッパーは 9 月 6 日に 修正済みビルドへ移るまで 0.1.1-rc.2 に留まっていました。

あなたのハーネスにもこれがある

これを一つのプロジェクトのバグとして片づけて先へ進むこともできます。ですがこの形は旅 をします。エージェントのハーネスはローカルの制御プレーンを次々に生やしているからで す。ダッシュボード用のステータスサーバー、IDE ブリッジ、MCP エンドポイント、差分を描 く localhost のページ。どれもあなたのマシン上の小さな HTTP サービスであり、エージェン トが走らせるコードはそのすべてに届きます。エージェントはそのマシンで動いており、 localhost とはまさに「そのマシン」のことだからです。

制御プレーンが、それが制御する当のものの隣に座った瞬間、結果を支配する問いは一つで す。閉じ込められた側は、自分の閉じ込めの設定を宛先にできるのか。DeepSeek はできると答 えました。呼び出し側の言い分をそのまま信じる検査を通して。より強い検査を置いても、そ れは本来問えてはならなかった問いに、なお答え続けます。認証関数はコードであり、コード にはフォールバックの分岐があり、今年は誰も通していない分岐でセキュリティの判断が崩れ る行進の連続でした。

Bromure ワークスペースでは、そのスイッチはどこにあるか

Bromure Agentic Coding は反対の端から始めます。Bromure のワークスペースはエージェント を無制限のままにします。

ゲストの中で、エージェントは DeepSeek Harness が danger-full-access と呼ぶであろうも のをすでに持っています。それが設計上の平常状態です。マニュアルもそう述べています。プ ロンプトインジェクションを受けた、あるいは他の理由で行儀の悪いエージェントは「ゲスト の内側では好きなことを何でもできますが、本物の API キーを読むことも、本物の AWS シー クレットで署名することも、SSH の秘密鍵を取り出すこともできません。そのどれもが、その 側の線上には存在しないからです」。エージェントはファイルシステムのどこにでも書け、好 きなものを実行し、好きなポートを掴めます。だから昇格する先のモードが残っていません。 境界はハイパーバイザーの縁であり、エージェントはその向こう側にいます。

したがってゲストは制御プレーンのアドレスをそもそも持ちません。ワークスペースのポリ シー（ガードレール、資格情報、ファイアウォールのルール、MCP サーバー）は、あなたの Mac の ~/Library/Application Support/BromureAC/profiles/ の下の profile.json に置かれ、 変更は Edit workspace のウィンドウで行います。ゲストにはそのファイルへのファイルシステ ムのパスも、それを読むプロセスへのネットワーク経路もありません。

二つの側は virtio ソケットで話します。VM のネットワークの外を走る、ホストとゲストの 点対点のブリッジです。ワークスペースの VM は八本を持ち、それぞれに役目があります。8443 はゲストの HTTPS をホストのプロキシへ運び、8444 は ssh-agent のブリッジ、8445 は AWS の 資格情報ヘルパーに供給し、5800 はターミナルとファイルのパスを担い、5010 は OAuth のコー ルバックを中継します。どれも固定のプロトコルを一つ担い、どれも Host ヘッダーを受け取 りません。だから呼び出し側には、言葉で入り込むための trustedHosts リストがありませ ん。vsock における同一性はトポロジーです。バイトがどのブリッジから届いたか。それはリ クエストに打ち込めるものではありません。

never には設定できない承認

danger-full-access の後半はプロンプトを切るものでした。この半分にも固有の答えが要り ます。エージェントが自分の承認を黙らせられるという点こそ、私なら夜眠れなくなる部分で す。

Bromure のワークスペースでは、プロンプトはホストに住んでいます。プロキシがそれを上げ るのはリクエストがすでに VM を出た後なので、ゲストの中のセッションは、そのどれかを抑 え込める設定を一つも持ちません。使用前に確認は、セッションでその資格情報が最初に 使われるところで止め、時間の区切られた許可を差し出します。五分、一時間、セッションの 残り、あるいは許可しない。書き込みポリシーを書き込み前に確認にすると、あらゆ る変更操作が Allow write on "<scope>" from workspace "<name>"? と題したダイアログで止まり、そのま まの操作内容、SQL 文そのもの、REST 呼び出しなら METHOD /path が示されます。一度だ け許可は許可を一切作らないので、次の書き込みではまた尋ねられます。許可はメモリに住 み、セッションのウィンドウを閉じれば消えます。

ガードレールのページはこの性質を一つの節で述べています。書き込みポリシーは「プロキシ で強制されるので、VM の中で乗っ取られたエージェントはこれを迂回できない」。その下の送 信ファイアウォールも同じ働き方です。Unmatched traffic の設定を Deny にできる順 序付きのルール表で、二度適用されます。一度は仮想スイッチで宛先 IP と DNS から拾ったホ スト名により、もう一度はプロキシで TLS のサーバー名と、web ルールなら HTTP メソッド により。ルールの編集は再起動なしに実行中のセッションへ届きます。

無人の実行は安全な側へ倒れます。SSH や自動化からヘッドレスで駆動されるワークスペース も、その tmux の中に同じ四つの選択肢をテキストのプロンプトとして受け取り、答えがなけ れば拒否です。そこでの最悪の結末は、呼び出しが一つ止まり、Security Timeline に赤い行 が一つ増えることです。この CVE では、エージェントが承認を never にして、プロンプトそ のものが消えました。

取り消せる閉じ込めは、ただの好みです

DeepSeek は弱い検査を出荷し、OX が確認してから三日で直しました。残るのは、その検査が 何を守っていたかです。プロセス自身のランタイムによってそのプロセスの周りに引かれた境 界は、プロセスが交渉できる境界です。アドレスがあり、API があり、フィールドを持つ設定オ ブジェクトがあります。そのフィールドの背後のどこかで、この呼び出し側が書いてよいかを 決めるコードの経路が走っており、その種のコードの経路は、悪い既定値ひとつで飾りに変わ ります。

境界をプロセスの下に引けば、交渉する相手がいなくなります。Bromure のワークスペースの エージェントは root を握り、ファイルシステムのすべてを握り、好きなポートで好きなサービ スを立ち上げられます。その API キーは囮であり、ネットワークへの唯一の経路はあなたの Mac のプロキシへ向かう virtio ソケットであり、権限を保持するファイルは読めない場所にあ ります。線のその側でエージェントにすべてを渡せば、線を守り続ける必要がなくなります。

コーディングエージェントはこれからもローカルの制御プレーンを生やし続けます。制御プ レーンこそが、ダッシュボードや IDE ブリッジや差分ビューアの作り方だからです。そして各 プロジェクトは、自分のエージェントが走らせるコードが、そのエージェントを支配する設定 と同じ側の線上にあるのかどうかに答えなければなりません。そこを外せば、なお持ちこたえ ているのは認証だけになり、9.4 がシェルコマンド一つに落ちるのはそういう筋道です。 Bromure Agentic Coding を導入して、スイッチをエージェントの手の届か ないところへ置いてください。