承認ダイアログは現れ、攻撃者の URL を名指しし、そこへ向かうデータまで見せた。だがそれが届いたのは、問うている当の書き込みがすでにディスクへ落ちたあとだった。

誰かから送られてきたリポジトリをクローンし、エージェントをそこに向ける。カードが滑り込んでくる。エージェントが設定を変えたがっている、挿入した行はこれ、URL はこれ、と。読むつもりではいる。その前にプラグインのパネルへ寄る。このプロジェクトが何を引き込むのか気になったからだ。そのクリックが攻撃を完了させる。

9月11日、AWS はエージェント型 IDE である Kiro の CVE-2026-89332 についてセキュリティ速報 2026-111-AWS を公開した。CVE のレコードは、カタログの平坦な言葉でこう記している。

バージョン 0.8.135 より前の Amazon Kiro IDE の Kiro Powers 機能における、信頼できない制御領域からの機能の取り込みにより、認証されていないリモートの行為者が開発者のワークステーションから機微な情報を取得できる可能性がある。

レコードは CVSS 3.1 で 5.5、AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N と評価する。機密性への影響は高く、完全性と可用性への影響はない。Kiro 0.8.135 が修正しており、 AWS は回避策を示していない。

Powers と、その出所を書いたファイル

Powers は Kiro のプラグイン形式だ。MCP ツール、スキル、参照知識をひとつのインストール可能なパッケージにまとめたものである。MCP は Model Context Protocol、コーディングエージェントが外部のツールを呼び出し、その結果を読むためのプラグだ。拡張機能を眺めるのと同じように、IDE 内のレジストリから Powers を眺めてインストールを押す。

ある設定が、IDE の眺めるレジストリを指定する。そして信頼できないワークスペースでは、 Kiro のエージェントがそのワークスペースの設定ファイルを書けてしまった。細工されたリポジトリはそれを使い、Powers レジストリの URL を攻撃者の運営するエンドポイントへ向ける。Powers パネルを開くと Kiro はその URL を取得し、リクエストはワークスペースのデータを一緒に運ぶ。実際のプロジェクトなら、コードの隣にあるもの、たとえば .env の中身、クラウドのアクセスキー、API トークン、データベースの URL である。

Kiro は以前もここに立っている。7月には、汚染されたドキュメントのページが Kiro の MCP サーバーを起動する設定を書き換えた。このときは承認の問いかけすらなかった。AWS はその問いかけを足し、9月の速報は、その問いかけがどう振る舞ったかを記録している。

先に書き、あとで問う

速報が語るこの順序の説明こそ、持ち帰る価値のある部分だ。

Kiro は挿入されたデータと URL を示して、変更をユーザーの承認に出していたが、ファイルはすでにディスクへ書き込まれていたため、プロンプトに応答する前に Powers パネルを開くと、それでもリクエストが発生した。

ダイアログはダイアログとしての仕事をした。挿入されたデータと宛先の URL の両方を見せており、それは変更を判断するのに査読者が必要とするすべてだ。問いがまだ開いている間、ファイルはディスクの上にあった。だから問いは、出来事を制御するのではなく、出来事を語っていた。書き込みとあなたの答えの間には窓があり、その中では設定こそが Kiro の取得先を支配する。その窓でのパネルのクリック一回が、攻撃のすべてである。

CVE-2026-89332 を左から右への時系列で示した図。すべては開発者のマシン上で起きる。細工されたリポジトリがエージェントにワークスペースの設定ファイルを書かせ、Kiro Powers レジストリの URL を攻撃者のエンドポイントへ向け直す。設定ファイルがディスクに落ち、そのあとでようやく承認カードが現れ、挿入された行と URL を本来どおりに示す。カードが答えを待つ間、設定はすでに効いている。Powers パネルを開けば Kiro は設定されたレジストリを取得し、ワークスペースのデータがリクエストとともに出ていく。開発者がそのあと何をクリックしても、もはや差し止めるものは残っていない。

競走に負けうる問いかけ

承認の問いかけが結果を制御するのは、その結果があなたの答えを待っているときだけだ。効果を先に確定させてしまえば、問いかけはボタンの付いた通知に変わり、それがあなたを守るかどうかは、読む速さと、読んでいる間に何をクリックするかに左右される。Kiro は先に書き、あとで問うた。エージェント型 IDE を軽快に感じさせるのは、まさにこの順序である。エージェントにファイル書き込みのツールを渡し、その上に同意の層をボルトで留めるツールはどれも同じ取引に直面し、ベンダーはこれからもその取引を選び続ける。

バージョンの更新はこの一件を閉じる。残るのは、設定がどこに住んでいるか、そしてそれが変わったとき何に手が届くか、である。

その書き込みは Bromure のワークスペースでどこに落ちるか

Bromure Agentic Coding は、コーディングエージェントを Mac 上のハードウェア仮想化された Linux VM の中で動かし、セキュリティ制御はその境界のホスト側に置く。攻撃がワークスペースに届いたあと、残る手は四つあり、そのそれぞれに製品の別々の部分が答える。

ツールのレジストリは、ゲストが書けるファイルではない。 Bromure では MCP サーバーを一度だけ、アプリの MCP ペインで、ホスト側に定義する。アプリは各定義を、そのとき動いているエージェントのネイティブな設定形式へ翻訳する。Claude Code なら ~/.claude.json、Codex なら ~/.codex/config.toml の TOML ブロック、Grok Build ならユーザー設定ファイル、というふうに。そして起動時に VM へ注入する。マニュアルはその帰結を明言している。サーバーの追加、編集、削除が効くのは、ワークスペースの次のセッション起動時であって、動いているセッションの最中ではない。VM の中でツール設定を書き換えたエージェントは、あなたのものではないマシンの上で写しを編集したにすぎず、その写しが生きたツールになるのは、代わりにホストの定義を読むセッション起動のときだ。変更と効果が別々の場所にあるのだから、窓は開かない。HTTP の MCP サーバーについてはトークンもホスト側に留まり、never sent to VM, swapped by proxy と添え書きされた資格情報の欄に置かれる。

書き込みは VM に落ちる。 ワークスペースはそれぞれ、自前のカーネル、ディスク、 MAC アドレス、ネットワーク名前空間を持つ永続的な Linux VM を所有する。暴走したエージェントのプロセスが壊せるのはその VM だけであり、あなたの Mac、ほかのワークスペース、そして本物のファイルは、意図して共有したフォルダを除いて手つかずのままだ。細工されたリポジトリが設定ファイルを書き換えられるのは、書き換えられるために存在し、いざとなれば消せるマシンの上である。

送信は外に出なければならない。 昨日の Vite スキャンの話には、塞ぐべき外向きの脚がなかった。今回はある。持ち出しは攻撃者が選んだホストへの普通のリクエストであり、ワークスペースごとのエグレスファイアウォールはまさにそのためにある。Guardrails は、VM が開くすべての接続に対して、ホスト、IP または CIDR、プロトコル、ポート、そしてウェブトラフィックなら個々の HTTP 動詞まで下りた、順序のある pf 形式のルールセットを適用する。だからワークスペースは、書き込みを許されていない API を読むことができる。Bromure はこれを仮想スイッチで強制し、プロキシでももう一度強制する。ゲストのポート 80 と 443 の通信はプロキシへ迂回させられ、VM の中の何ものも検査から抜け出せない。ルールの変更は動作中のセッションにも即座に届く。あなたのレジストリ、あなたのフォージ、あなたのモデルプロバイダーを名指ししたルールを持つワークスペースには、attacker.example と書かれた行は一本もない。

そのリクエストが運んだのはダミーだったはずだ。 速報の言い回しは「開発者のワークステーションから機微な情報」であり、Bromure のワークスペースではその情報はおとりである。Bromure は、あなたが設定したすべての資格情報を、VM の中では構造を保った偽物に置き換える。偽物は本物の値とインストールごとの 32 バイトのソルトから HKDF-SHA256 で導かれ、クライアント側のバリデーターが期待する形を保つ。Anthropic なら sk-ant-api03-brm-…、GitHub なら ghp_ に 36 文字、GitLab なら glpat- に 20 文字、Kubernetes なら brm-k8s-…、データベースの秘密なら brm-db-… という具合だ。これらの偽物は環境変数に入り、~/.git-credentials、 ~/.docker/config.json、~/.kube/config、~/.aws/config、そして MCP の設定にも入る。本物の値は Mac の上で暗号化されたまま残り、ホストのプロキシが最後の瞬間に、それが属する宛先ホストに限って、一つずつワイヤー上で差し替える。

同じ細工されたリポジトリを、二台のマシンで開いた場合。開発者のワークステーションでは、書き込みは本物のファイルシステムに落ち、承認カードは Powers パネルと競走し、送信はプロジェクトが抱えるものを載せて攻撃者のエンドポイントへ出ていき、後始末は手の届く範囲にあったすべての資格情報を入れ替えることになる。Bromure Agentic Coding のワークスペースでは、書き込みは VM のディスクに落ち、正本のツール定義はホストが保持して起動時にだけ注入し、外向きの送信は仮想スイッチとプロキシの二か所でワークスペースのエグレス規則に当たり、それでも出ていくものは構造を保ったダミーを運び、発行されていないホスト宛てのダミーは HTTP 451 で拒まれ、VM はその場で一時停止される。

リクエストそのもので発火する仕掛け線

ダミーはもう一つ仕事をする。それぞれの偽物には正当な宛先の系統が一つだけある。その偽物が発行されたホストの範囲だ。だから、ほかのどこかへ向かうリクエストの中に偽物があるということは、VM の中の何かが資格情報をマシンの外へ送り出している、ということを意味する。プロキシは外向きのすべてのリクエストを、ヘッダーも本文も、 Aho-Corasick オートマトンで走査する。すべてに掛けられるほど安い処理である。

一致すればプロキシはそのリクエストを HTTP 451 で拒み、一バイトも転送せず、そして VM を一時停止する。アラートは Shut down、先にディスク、ホーム、共有フォルダをフォレンジック用に書き出す Save for Investigation、そして自己責任の Continue を提示する。検知は Security Timeline に赤い Credential brokering の行として残り、Bromure はそのワークスペースを侵害済みと記録する。だから次回の起動では、トークン、鍵、設定は保ったまま、VM のディスクと永続ホームフォルダを消去するかと尋ねてくる。あなたは何も有効にしない。検知器は既定で動いている。

Kiro の承認カードは、すでに変わってしまったファイルについて問いを立てていた。侵害検知器は何も問わない。飛行中のリクエストを止め、それを送ったマシンを凍らせ、あとであなたに知らせる。Bromure 自身の同意の問いかけも、この向きで働く。Ask モードでは、プロンプトインジェクションのスキャナーが、一バイトもモデルのホストに届く前に外向きのリクエストを押しとどめる。Guardrails の書き込みダイアログは、API 呼び出しを報告するのではなく押しとどめる。そしてワークスペースを遠隔から操るときも、その問いかけはホスト側で描かれる。侵害されたゲストにはそれが見えも偽造もできず、時間切れや却下は拒否として数えられる。

何も入れ替えない

AWS の後始末は二段階だ。0.8.135 へ更新し、それから、古いバージョンで開いたすべてのプロジェクトにあった資格情報を入れ替える。二段目は一段目より高くつき、しかも独特の高さでつく。範囲を絞れないのだ。どのリポジトリが細工されていたのか、どのパネルのクリックがどの窓の内側に落ちたのかは分からない。だから手の届く範囲を入れ替え、それに依存していた道具立てを認証し直すことになる。

Bromure Agentic Coding のドキュメントは、同じ考えを裏返して置く。漏れたのは偽物だけなのだから、本物の資格情報を入れ替える必要は最初からない。正本のツールレジストリはホストに置き、信頼できないリポジトリは捨てられるマシンで動かし、そのマシンのホームディレクトリはダミーで満たす。そうすれば、負けた競走の代価は VM イメージ一つで済む。

Bromure Agentic Coding を導入して、次のリポジトリに設定の書き換えを試させてみればいい。