あなたが信頼したのはワークスペースであって、サーバーではなかった

インフラモジュールを試そうとリポジトリをクローンする開発者は、 それを何かへのアクセスを与える行為だとは考えない。クローンは 不活性だ。ファイルをディスクに書き込むだけで、何も実行されない。 判断を迫られるのはその一歩あと, エディタでフォルダを開き、 アシスタントが信頼するかどうかを尋ねてくるときだ。そのプロンプトは、 どの IDE も見せる「このフォルダ内のファイルの作者を信頼しますか」という おなじみのゲートのように読め、あなたは千回そうしてきたのと同じように はいをクリックする。なぜなら代わりにあるのは、自分のコードを読めない アシスタントだからだ。この特定のはいは、アシスタントに読ませる以上のことを した。修正前の Amazon Q では、それはリポジトリが .amazonq/mcp.json に書き込んだサーバーをすべて起動もし、 それらのサーバーは、あなたの生きたクラウドセッションをすでに 環境に抱えた状態で、あなたのシェルのなかで立ち上がった。

私たちは今月初めに同じ形を 記事にした。Miasma ワームが Microsoft 自身の 73 のリポジトリに プロジェクト設定を仕込み、ペイロードがフォルダを開いた瞬間に発火した ときのことだ。あの話は 信頼されたソース が攻撃対象になるという話だった。 こちらはもっと狭く、もっと不快だ。ワームもなく、侵害されたメンテナーもなく、 指さすべき相手はアシスタントしかいない。バグは、Amazon Q がごく普通の プロジェクト設定ファイルをどう読み、あなたの一回の信頼クリックを受けて、 ノートパソコン上で最も機微なものを抱えた長時間稼働プロセスの起動を どう決めたか、にあった。

CVE-2026-12957 が実際にしたこと。

2026年6月26日、Wiz Research が CVE-2026-12957 を公開した。これは Language Servers for AWS, VS Code、JetBrains、 Eclipse、Visual Studio にわたって Amazon Q Developer を動かすエンジン, の 高深刻度の欠陥（CVSS 8.5）だ。Wiz は 4月20日 に Amazon へ報告し、 Amazon は 5月12日 に修正を出荷し、詳細は 6月26日 に公開された。 実環境で悪用された形跡はない。仕組みを削ぎ落とすと次のようになる。

• Amazon Q は、あなたが開いたワークスペースから .amazonq/mcp.json を読む。これはアシスタントが使うための Model Context Protocol サーバーを宣言する、プロジェクト単位のファイルだ。
• フォルダを開くと、Q は そのファイルが宣言した MCP サーバーを 起動した, サーバーそのものに対する独立した同意ステップなしに。 したがって、あなたがクローンしたリポジトリは、サーバー定義を アシスタントの前に差し出して実行させることができた。
• 生成されたプロセスは 開発者の環境を丸ごと引き継いだ。 Wiz の言葉では「AWS キー、クラウド CLI トークン、API シークレット、 SSH エージェントソケット」だ。MCP サーバーとは、Q が起動する単なる コマンドであり、そのコマンドはあなた自身のシェルが持つはずのすべてを 抱えて立ち上がった。
• サーバー定義は任意のコマンドを指せるので、このファイルは事実上、 フォルダを開いた瞬間の任意コード実行に等しい。ワークスペースを 信頼した瞬間、あなたのクラウド資格情報をすでに読み込んだ状態で、 あなたとして実行される。

この公開は同意をめぐる本物の食い違いを含んでおり、それこそが本稿の 眼目だ。Amazon の立場は 「ユーザーはプロンプトが出たときに ワークスペースを信頼しなければならない」 である。ゲートはあり、 あなたはそこを通り抜ける。Wiz の発見は 修正前には MCP サーバー そのものに対する独立した同意ステップが存在しなかった ということだ。 両方とも成立しており、失敗は両者のあいだの隙間に潜む。粗く、おなじみの、 エディタがインデックスを張れるようフォルダに与えるのと同じはい/いいえの 信頼判断が、はるかに大きな許可, あなたの生きたセッションを抱えた バックグラウンドサーバーの起動, を承認した。あなたは ファイルを読む ことについての質問に答えた。Amazon Q はそのクリックを あなたとしてサーバーを実行する ことに使った。

Amazon は Language Servers 1.69.0（クライアント: VS Code 2.20+、 JetBrains 4.3+、Eclipse 2.7.4+、Visual Studio 1.94.0.0+）でこれを修正し、 欠けていたサーバーごとの同意を追加し、兄弟分のシンボリックリンク チェック回避 CVE-2026-12958 も塞いだ。Amazon Q を更新しよう。 そのうえで、パッチの先, それが残したままにする部分を見てほしい。 リポジトリを開くことが、あなたの生きたクラウドセッションを、 リポジトリが選んだプロセスのなかに置きうるのだ。

同じリポジトリを Bromure Agentic Coding のなかで開く。

Bromure Agentic Coding は、あなたのコーディング エージェントを, Amazon Q を含め, プロファイルごとの Linux VM の なかで動かす。Apple の Virtualization フレームワーク上で、独自の カーネル、独自のファイルシステム、独自のネットワークスタックを持つ。 プロファイルとは作業のまとまった範囲だ。このクライアント、 このサービス、評価のためにクローンしたこのオープンソースモジュール。 あなたはリポジトリをそのプロファイルにクローンし、そこで開く。 脆弱な挙動は Wiz が記述したとおりに再現する。あなたは このワークスペースを信頼する をクリックし、Q は .amazonq/mcp.json を読み、ファイルが宣言したサーバーを起動する。 起動は発火し、リポジトリが選んだコードが実行される。

それはゲストのなかで実行される。MCP サーバーは VM のなかで立ち上がり、 VM の環境を引き継ぐが、VM の環境にはあなたのクラウドセッションは 入っていない。Bromure はゲストに スタブ を同梱する。aws、 gcloud、az、kubectl、git、そして Authorization ヘッダーや AWS_ACCESS_KEY_ID を読む何にとっても本物に見える偽の値だ。 あなたの Mac 上のプロキシが、サンドボックスを出る全接続の前に立ち、 スタブを認識して、リクエストが出ていくときに ワイヤー上で 本物の シークレットと差し替える。鍵を抱えていたサンドボックスが その仕組みをたどっている。本物の AWS キー、本物のクラウド CLI トークン、 本物の API シークレットは、VM が読めるファイル、環境変数、 メモリのページに一切触れない。

では、この境界を通して CVE の継承をたどってみよう。起動された サーバーは $AWS_ACCESS_KEY_ID を読み、スタブを見つける。~/.aws を 読み、スタブのプロファイルを見つける。クラウドトークンと API シークレットを求めて環境を読み、プレースホルダーを見つける。 サーバーは書かれたとおりに最後まで実行されるが、あなたのキーを そもそも抱えていなかった箱を引き継ぐ。CVE-2026-12957 を資格情報窃取の バグにしたのは 起動時の環境継承 であり、Bromure はそれを壊さない。 継承される環境を無価値なものにしておくのだ。

「このワークスペースを信頼する」は間違った質問だった。

この CVE がパッチノート以上の価値を持つのは、同意の隙間ゆえだ。 そしてその隙間は粒度の問題だ。信頼プロンプトは一つの大きな質問, このフォルダを信頼しますか , を投げかけ、一回のはいが、あなたが 意図した無害なこと（アシスタントに私のコードを読ませる）と、 付随していると知らなかった危険なこと（私のクラウドセッションを 抱えたバックグラウンドサーバーを起動する）の両方を覆わなければ ならなかった。それにうまく答えることはできない。誰にもできない。 なぜなら、その質問は互いに何の関係もない二つの許可を融合させ、 無害なほうだけをあなたに見せるからだ。

Bromure はその判断をあなたに上達させようとはしない。判断を経路から 外すのだ。プロファイル内の信頼クリックは、依然としてアシスタントに 仕事をさせるが、それでもなお、あなたの本物のクラウドセッションを 抱えたプロセスを起動することはできない。なぜなら、そのセッションは 引き継がれるべく VM のなかにないからだ。それはホスト上、ブローカーの 背後にあり、プロキシがワイヤー上で埋めてログに残すスタブ化された リクエストとしてのみ到達できる。許可の危険な半分は消えている。 あなたがそれを差し控えたのではない。与えるべきものがそこになかった のだ。なぜなら境界は、信頼プロンプトがそれを動かせない、エージェントの 下に位置するからだ。

もう一つの 危険な半分は、単にせんさく好きなだけでなく破壊に走る 起動済みサーバーであり、それは ガードレール に出くわす。Bromure は 接続だけでなく操作を読む。aws s3 ls は読み込み、aws s3 rm は 書き込み。git fetch は読み込み、git push は書き込みだ。 プロファイルのクラウド資格情報を 書き込み時に確認 に設定すれば、 コードが DELETE、Terminate*、または強制プッシュのような状態変更 呼び出しに手を伸ばした瞬間、Bromure はそれをワイヤー上で止め、 動詞、対象、プロファイルを明示するプロンプトをあなたの Mac に 浮かべる。読み込みは決してあなたを中断させない。一時停止するのは 変更だ, 「エージェントが本番データベースを削除した」が 事後検証ではなくあなたが 却下するダイアログになるのと同じやり方で。

トレースが見せるもの。

こういうことが起きた翌朝、どのチームも同じ質問をする。私はあの リポジトリを開いたか、そして何が実行されたのか 。通常のノートパソコン では、正直な答えは肩をすくめることだ。Q が起動した MCP サーバーは、 あなたのセッション内の子プロセスであり、何を読み、どこへ電話を かけたにせよ、それはあなたとして行われ、あなた自身の作業と区別する 記録は残らない。

Bromure のなかでは、エージェントは VM に収まり、外向きの全バイトは ホストプロキシを通るので、エージェント自身には見えなくても起動と その呼び出しは可視のままだ。ホストは、MCP サーバーが立ち上がったこと、 それが実行したコマンド、ブローカーに埋めるよう求めた資格情報、そして 試みた全接続を、エージェントがほかにしたすべてと同じセッション トレースに記録する。起動されたコードが手を伸ばして 編集できない、エージェントの下に書き込まれる。「このリポジトリの サーバーは私のアカウントに触れたか」は、数週間後に CloudTrail から 復元する当て推量であることをやめ、あなたが読む一行になる, ブローカーは スタブを手渡し、リクエストには名前があり、対象は記録された。企業に とってそれは、Amazon Q をパッチした と 開発者が開いた全リポジトリが 何をしたか示せる とのあいだの差であり、その監査態勢こそ、私たちの エンタープライズの取り組みが繰り返し立ち返る ところだ。

これがあなたを救わないところ。

次のワークスペースは、すでにどこかでクローンされている。

Red Hat のスコープの教訓は、 発行元は防御ではない、ということだった。Microsoft の リポジトリの教訓は、 リポジトリもまた防御ではなく、フォルダを開くだけでコードを実行するに 足りる、ということだった。Amazon Q は次の一行を加える, 信頼プロンプトも また防御ではない。それがあなたに突きつける質問, このフォルダを 信頼しますか , は、答えが重要な質問ではない。重要なのは このフォルダは私のクラウドセッションを抱えたサーバーを起動できて よいか だ。あなたは二番目の質問を見せられたことが一度もなく、 たとえ見せられていても、うまく答えられなかっただろう。

それは、プロンプトをもっと注意深く読むことでは直せない。プロンプトが 間違ったプロンプトだったからだ。直すには、「これはどのワークスペース か」があなたのクラウドキーがぶら下がる質問であることをやめるように 物事を配置する。なぜコーディングエージェントはサンドボックスでは ないのかが、その議論の より長い版だ。Bromure Agentic Coding は、 エージェントがプロファイルごとの VM のなかでリポジトリを開き、 本物の資格情報はブローカーの背後でホストにとどまり、エージェントが 行う全書き込みはプロンプトを通らねばならず、起動する全サーバーは 編集できないトレースに書き込まれる, そういう構成だ。汚染された mcp.json ができる最悪のことは、あなたのキーをそもそも抱えていなかった 箱を引き継ぐことだ。無料で、オープンソースで、本日出荷された。