そのゲートウェイは、どんなトークンでも受け入れた

9 月 2 日、CISA は 七件の脆弱性を追加しました。 Known Exploited Vulnerabilities カタログへの追加です。SonicWall SMA1000 の二件、 Sangoma Switchvox の SQL インジェクション、JFrog Artifactory の認証バイパス、 Kestra の OS コマンドインジェクション、Starlette の HTTP スマグリング、そして BerriAI の LiteLLM における不適切な認証。

この七件のうち三件は AI・ML インフラです。Forkast はこれを AI コンポーネントが追加の半数近くを占めた最初の KEV の一群 と呼びました。見出しにはなり、そのあと書類棚に片づけられる類いの節目です。 しかし、それがどのAI インフラなのかを見れば、この一群は片づけて終わりに するには惜しい。三件はいずれも真ん中に座っています。あなたのエージェントと、 それが触れるリソースとが直接話さずに済むよう、あなたが配備した部品です。 まずは LiteLLM の項目から。

フォールバックの分岐

LiteLLM は AI ゲートウェイです。エージェントとモデル提供者のあいだに立つ 一つのプロキシで、ほかの誰も持たなくて済むように提供者の鍵を預かり、予算と レート制限を課し、ログを書き、いまでは Model Context Protocol サーバーへも 枝分かれします。開発者がめいめい自分の MCP を配線する代わりに、チームの エージェントが一つの MCP エンドポイントを共有するためです。

7 月 8 日に公開され GitHub のアドバイザリで CVSS 8.8 を付けられた CVE-2026-59822 は、その MCP エンドポイントに棲んでいます。アドバイザリの 一文が、話のすべてを担っています。

フォールバック経路は、失敗した LiteLLM のキー検証を空の UserAPIKeyAuth() オブジェクトで置き換えることがあった。

MCP Streamable HTTP エンドポイントは OAuth2 パススルーに対応していました。 上流の MCP サーバー向けのトークンを、LiteLLM 自身のキーストアに照合するのでは なく、ゲートウェイを素通りさせるためです。これは筋の通った機能で、分岐を 必要とします。まず LiteLLM のキーを試し、届いたものがキーでなければ パススルー経路を取る、という分岐です。

その分岐には、失敗することで辿り着けます。どんな文字列でもよいので Authorization ヘッダに載せて送ると、その文字列はキーではないのでキー検証は 拒否し、ハンドラは空の UserAPIKeyAuth() を組み立てて、それを抱えたまま 先へ進みます。あなたのリクエストはいま、誰のものでもない認証済みの MCP セッションを握っています。そこからは、ゲートウェイに設定された MCP ツールを すべて列挙して呼び出すだけです。内部アプリケーション、データベース、 クラウドコンソール、開発システム、チームがつないでいたものは何でも。この欠陥は 1.84.0 より前のすべてのバージョンに影響します。連邦機関に対する CISA の 是正期限は 9 月 16 日で、今日すぐに更新できない人への LiteLLM の助言は、 手前のリバースプロキシで /mcp/ を遮断することです。

残る三件も、同じ関数で壊れた

この一群の残りを読むと、AI か否かという見出しよりも役に立つものが手に入ります。

Starlette、CVE-2026-48710、通称 BadHost。Starlette は FastAPI の下にある ASGI ツールキットで、Python の AI サービスの大きな割合が、LiteLLM も含めて その上に建っています。細工した Host ヘッダがリクエストのホスト部分にパスを 注入し、それが URL の再構成のされ方をずらし、その結果、パスに基づく認証 ミドルウェアがあるルートを評価している一方でアプリケーションは別のルートを 提供します。CISA の項目は結果をこう述べます。認証が再構成された URL のパスに 依存している場合の、認証バイパスである、と。CVSS は 6.5 で、この一群で最も 低く、そして帰結について最も語らない点数です。LiteLLM は同じ形に対する 自前の付随修正を 1.84.0 で出荷し、それを「細工した Host ヘッダによって、プロキシの認証門が 実際に提供したのとは別のルートを評価しうる」と説明したうえで、プロキシを 外部に晒していた運用者にはキーの入れ替えと管理ログの監査を求めました。

JFrog Artifactory、CVE-2026-82329、CVSS 9.8。既定の設定における不適切な 認証で、未認証の攻撃者が管理者トークンを偽造できる「幽霊」ジョインキーです。 watchTowr は公開から四日後の 9 月 1 日に、攻撃者が管理者資格情報を鋳造し ユーザーを列挙する実環境での悪用を記録しました。これは成果物リポジトリ、 つまり組織全体の npm install と pip install に応答するホストです。

Kestra、CVE-2026-49869。未認証のリモート攻撃者から到達できる OS コマンド インジェクションで、資格情報を一切持たずに任意のワークフローを作成し実行 できます。オーケストレーターはオーケストレーターの仕事をします。ただし、 一度もログインしていない誰かのために。

四つの製品、四つの異なるコードベース、そしてそれぞれの中の同じ壊れた関数。 このリクエストがここに居てよいかを決める、あの関数です。空の認証オブジェクト。 再構成されたパス。既定のジョインキー。Kestra の場合は、実行を担うルートに チェックがそもそも無いこと。

攻撃者たちが次にやったことは退屈で、その退屈さこそ量をこなす作業の証拠です。 The Hacker News は 観測された挙動をまとめました。 リバースシェル、XMRig マイナー、資格情報の列挙、そして API キーと LLM 提供者の 資格情報の窃取。Microsoft はこう要約しています。

観測された目的は一貫していた。いずれの事例でもテレメトリは、資格情報の収集、 持続的なアクセス手段、そしてリソースの収益化を示していた。実行経路は製品ごとに 異なっていたにもかかわらず、である。

ゲートウェイは正しい発想だった。これはその請求書だ

AI ゲートウェイはこの二年で最良の発想の一つで、たいていのチームは もっともな理由でそこに辿り着きました。

ゲートウェイ以前は、開発者めいめいのコーディングエージェントが提供者の鍵を 環境変数に抱え、めいめいが自分のトークンで自分の MCP サーバーを配線し、 それら全体が何にいくら使い、何に触れたのかを誰も答えられませんでした。 真ん中にゲートウェイを置けば、それが一挙に片づきます。一か所が提供者の鍵と MCP の設定を持ち、ログを書く。鍵の入れ替えは一回の操作になり、去っていく 社員の遮断も同じです。業界がここに収束したのには理由があります。

請求書の中身はこうです。あなたは、全員の権限を預かることそのものを目的とする ネットワークサービスを建てました。そしてそれは、あなたが誰かを一つの関数で 決めます。関数には分岐があり、そのうちの一つは、最初に試したことが うまくいかなかった場合を処理します。

LiteLLM がこの形を発明したわけではありません。どのゲートウェイにも玄関があり、 どの玄関にも認証関数があり、二つの資格情報方式に対応する認証関数には、 最初の方式が失敗したときに取る経路があります。その扉の奥にある到達範囲は 意図されたものです。それを集めることこそが製品なのですから。だからゲートウェイが 面倒に巻き込まれたとき、それが抱えるものはすでに同じ部屋の中にあります。

この種の事故から引き出されがちな結論は「開発者ごとの鍵に戻ろう」ですが、 それはどの尺度で測っても悪化します。集約は続けてください。議論する値打ちが あるのは、その集約されたものがどこに座るか、そして仕事をするために 見知らぬ相手からのリクエストに応答しなければならないのか、という問いです。

Bromure は同じ仕事をどこに置くか

Bromure Agentic Coding は、コーディングエージェントを一つずつ、あなた自身の Mac 上のハードウェア仮想化された Linux VM で動かします。そしてすべての セキュリティ制御は、その境界のホスト側に座ります。制御の顔ぶれはゲートウェイが 提供するものと同じです。資格情報を預かる、MCP サーバーを仲介する、エージェントが あなたのインフラに何をしたかを分類する、記録を残す。どのネットワーク上の何も、 それを執行する部品には届きません。

玄関がありません。 ゲストの HTTPS はネットワークへ出ていきません。virtio ソケット、vsock ポート 8443 を通ってホストのプロキシへトンネルし、マニュアルは トポロジについて率直です。VM にはネットワークへの他の経路がない。プロキシは、 あなたの LAN も社内ネットワークもインターネットも宛先にできる待ち受けポートを 一つも持ちません。プロキシは誰が呼んでいるのかを決して尋ねません。その ソケットの向こう端には一つのものしか居らず、それが何であるかはハイパーバイザが 決めているからです。Authorization ヘッダもキーストアも方式のネゴシエーションも なく、したがって最初の方式が失敗したときに取る分岐もありません。

MCP の bearer トークンは、エージェントに届く前からすでに偽物です。 ワークスペースに設定された HTTP トランスポートの MCP サーバーについて、本物の bearer トークンは Mac 上で暗号化されたまま残ります。エージェントの設定には brm-mcp_… という差し替え値が入ります。設定画面はその欄にVM には決して 送られません — プロキシが差し替えますと表示し、ホストのプロキシが本物の値を 回線上で差し込みます。適用範囲はそのサーバーのホストへの完全一致または サブドメイン一致に限られ、他のどこへも及びません。プロキシはさらに、サーバーの OAuth と OIDC のディスカバリ経路に 404 を返します。VM では決して完了できない ブラウザ手続きを試みる代わりに、Claude Code がそのサーバーを認証済みとして 扱うためです。LiteLLM のフォールバックは、まさにこの同じパススルーの表面に 立っていました。こちらでは、ワークスペースは取り落とす資格情報を持ちません。

すべての操作が、それぞれの判断を受けます。 ゲートウェイは扉で決着を つけます。通ってしまえば、奥にあるものはすべてあなたのものです。Bromure の Guardrails はプロキシの内側でエージェントの呼び出しを分類し、Kubernetes、AWS、 git フォージ、コンテナレジストリ、データベースにまたがって、サービスごとの 書き込みポリシーを適用します。新しいワークスペースの既定は書き込み前に確認 なので、読み取りは流れ、変更はすべてホスト側のダイアログで止まり、そこには 実際の操作が文字どおり表示されます。厳密な SQL、あるいは メソッド /パス。 読み取り専用はあらゆる変更を遮断します。使用前に確認は資格情報そのものに 門を設け、許可は分単位で測られます。偽造されたセッションであっても kubectl delete で何かを押し通すことはできません。二つ目の判断はあなたの Mac 上で下され、一つ目がどう転んだかとは無関係だからです。

既定の拒否が、双方向で到達可能性に答えます。 ワークスペースの外向き ファイアウォールは、一致しなかったトラフィックの既定値を持つ順序付きルール表 です。それを拒否にすれば、VM は列挙したホストにだけ、どのプロトコルでも 到達し、それ以外へは届きません。ゲストの外側にある二つの部品がそれを執行します。 仮想スイッチが宛先 IP と DNS から読み取ったホスト名でフローを照合し、プロキシが TLS のサーバー名でもう一度照合します。編集は再起動なしで進行中のセッションにも 届きます。逆方向では、NAT モードが VM をあなたの物理 LAN の外に保ち、意図して サービスを公開しない限り、外部の何もそこへ接続を開きません。晒された ゲートウェイをさらっていったスキャナは、Mac からは何の返事も得られません。

侵害されたゲートウェイが返してくるものは、すべて信頼できない入力です。 この部分は CVE より長生きします。ゲートウェイが他人のものになった時点で、 モデルの出力も、ツールの結果も、エラー文字列も、すべて攻撃者から届くように なります。しかもスタックで最も権限の高い回線、つまりエージェントがそれに基づいて 行動するようにできている回線を通って。Bromure のソースコード検出器は、 エージェントの外向き AI トラフィックの tool_result 区間を、ローカルの PromptGuard モデルで、端末上で、モデルがそれに基づいて動く前に採点し、記録・ 確認・遮断のいずれかを行えます。遮断は HTTP 451 を返し、モデルはその内容を 決して見ません。

持ち出しの脚は閉じる方向で失敗します。 ワークスペース内のすべての資格情報は、 正当な宛先を一つだけ持つ決定論的な偽物です。プロキシは外向きのリクエストを すべて走査し、鋳造されたのとは違う宛先へ向かう偽物を探します。見つけたときは 一バイトも転送せずにリクエストを拒み、VM を一時停止し、警報を上げます。それは Security Timeline に赤い資格情報の仲介の行として記録されます。手の届く 範囲にあったのは偽物だけなので、本物の資格情報を入れ替える必要はありません。

秘密は預かれ、確かめるな

こんな一週間のあとでは、Bromure 自身のアーキテクチャ覚書にある一行が 読み直す値打ちを持ちます。

境界を回避しても攻撃者は何も得られない。境界は秘密が確認される場所では なく、秘密が存在する唯一の場所だからだ。

ゲートウェイは、資格情報が確認される場所です。リクエストが届き、関数がそれを 検め、その関数の判定だけが、呼び出した側と鍵とのあいだに立ちます。確認には 境界事例と退避経路があります。確認は CVE と KEV の項目と連邦の期日を稼ぎ、 そして二か月後、同じ関数の別の分岐でもう一つ稼ぎます。

回線の境界は、資格情報がある場所です。検められるために届くものが何もないので、 判定が誤りようもありません。本物のトークンは Mac 上で暗号化されたまま座り、 ワークスペースはどこでも何の値打ちもない brm- の差し替え値を持ち、置き換えは ハイパーバイザだけが書き込めるソケットの上で起こります。

私たちはこの変奏を六週間で三度書きました。 エージェントが書き換えられるホスト名を信じた外向きプロキシ、 bash とは違うやり方で bash を読んだコマンドガード、 そして 回避の行き着く先がどれもプロセス内の本物の資格情報だった三つのコーディングエージェント。 どの回でも、破れた部品は何かを評価するという仕事を誠実にこなしていました。 そこが変わらない点です。評価は不在よりも弱い原始要素なのに、私たちは不在なら ただで済ませる仕事を、評価に渡し続けています。

エージェントの権限を集約したのは正しい判断でした。その集約したものを、誰も リクエストを送れない場所に置いてください。 Bromure Agentic Coding をインストールして、それぞれの エージェントに玄関のない境界を与えましょう。