あなたのエージェントには、検証していない仲介者がいる

研究者たちは、Taobao、Xianyu、Shopifyホストのストアフロントから28個の有料LLM APIルーターを購入し、さらにパブリックコミュニティから400個を収集しました。彼らは仕込んだ認証情報をリクエストに計測器として埋め込み、各ルーターがそのトラフィックをどう扱うか調査したのです。¹

そのうち17個のルーターが、リクエストに仕込まれたAWSカナリア認証情報に触れました。1個は囮として置かれた秘密鍵からETHを抜き取りました。チームがハニーポットとして用意したリークしたOpenAIキーは、論文要旨によれば、回収するまでに1億個のGPT-5.4トークンと「7つ以上のCodexセッション」を生成したのです。¹ 別の脆弱な設定の囮では、20億の課金トークン、440のCodexセッションにわたる99の認証情報、そして401セッションが既に自律的なYOLOモードで稼働していたことが判明しました。¹

LLM APIルーターは新たな攻撃対象領域です。誰も監査していません。

MCP信頼チェーンとは、AIエージェントとアップストリームモデルの間に位置する仲介者（APIルーター、プロキシ、ツールサーバーなど）の連鎖であり、それぞれがすべてのリクエストとレスポンスに対して完全な平文アクセス権を持っています。 エンドツーエンドでの暗号学的整合性を強制するプロバイダーは存在せず、つまりどの仲介者もデータを転送中に読み取り、改ざん、または持ち出すことができるのです。実地調査では、有料ルーター28個中17個が仕込まれたAWS認証情報に触れ、1個が秘密鍵からETHを抜き取っていたことが判明しており、検証されていない信頼チェーンのリンクが能動的な攻撃対象領域であることを示しています。

要約

サードパーティのLLM APIルーターはアプリケーション層のプロキシであり、エージェントとアップストリームモデルの間で送受信されるすべてのJSONペイロードに対して完全な平文アクセス権を持っています。クライアントとアップストリームの間で暗号学的整合性を強制するプロバイダーは存在しません。Liu、Shou、Wen、Chen、Fangによる新しいarxiv論文は、この攻撃対象領域に関する初の体系的研究を提示しており、実地データはおぞましいものでした。有料ルーター28個中1個、無料ルーター400個中8個がレスポンスに悪意のあるコードを能動的に注入しており、2個が適応型回避トリガーを展開、17個が仕込まれたAWSカナリア認証情報に触れ、1個が仕込まれた秘密鍵からETHを抜き取っていたのです。¹ 著者たちは2つのコア攻撃クラスに加えて2つの適応型回避バリアントを形式化し、次にMineと呼ばれる研究用プロキシを構築して、4つのパブリックエージェントフレームワークに対して「4つすべての攻撃クラス」（論文の表現）を実装し、3つのデプロイ可能なクライアント側防御策を評価しました。¹ もしエージェントが自分で構築していないルーターを使用しているなら、監査したことのない信頼境界が存在していることになります。

主なポイント

• エージェント運用者へ：クライアントとアップストリームモデルの間にあるLLM APIルーターはすべて、すべてのリクエストとレスポンスに対して平文アクセス権を持つアプリケーション層のプロキシです。暗号学的整合性を強制するプロバイダーは存在しません。マーケットプレイスで購入したルーターやパブリックコミュニティリストから入手したルーターがある場合、独立して検証するまでは敵対的な仲介者として扱ってください。
• ハーネス構築者へ：PreToolUseフックはツール実行前に動作しますが、悪意のあるルーターは生成後かつフックに到達する前にモデルのレスポンスを改ざんします。フックスタックにレスポンス側の検証を追加し、異常なレスポンス形状に対するfail-closedポリシーゲートも検討しましょう。
• YOLOモードを実行している人すべてへ：研究者のハニーポットでは401セッションが既に自律的なYOLOモードで稼働していました。¹ 自律セッションでツール呼び出しを改ざんするルーターは、あなたが読むレスポンスを改ざんするルーターよりもはるかに大きな影響範囲を持ちます。自分が制御していないルーターを通してYOLOモードを実行しないでください。

ルーターとは、正確には何か？

本論文の文脈では、LLM APIルーターとは、クライアントと1つ以上のアップストリームモデルプロバイダーの間に位置するサードパーティサービスです。OpenAI互換のAPIを使用してルーターにリクエストを送信します。ルーターはそのリクエストを選択したアップストリーム（GPT-5、Claude、Gemini、オープンウェイトモデル、それらすべてのプールなど）にディスパッチし、同じ形式でレスポンスを返すのです。¹

ルーターが存在するのは、LLMエコシステムが混沌としているためです。あらゆるモデルに対して機能する1つのAPIキーが欲しい人々がいます。価格裁定を求める人々もいます（トークンを一括購入し、より安く再販する）。直接プロバイダーアクセスが制限されている地域のための地理的回避策を求める人々もいます。1つのクライアントで複数のモデルをテストしたい人々もいます。どれも正当な理由であり、健全なルーター市場はそのすべてに応えるものです。

問題は、ルーターがアプリケーション層のプロキシであることです。単にバイトを転送しているわけではありません。リクエストJSONを読み、アップストリームを選択し、オプションでリクエストを書き換え、転送し、レスポンスを読み、オプションでレスポンスを書き換え、返すのです。そのパイプラインのすべてのステップが、ルーターのインフラ上で平文で発生します。¹

ここにはTLS相当のものがありません。TLSはクライアントからルーターへ、そしてルーターからアップストリームモデルへのバイトを保護します。しかしルーターからペイロードを保護することはしないのです。元のクライアントと最終的なモデルの間で暗号学的整合性を強制するプロバイダーは存在しません。モデルが受信したリクエストがクライアントが送信したリクエストと同じであることを示す署名付きアサーションも、クライアントが受信したレスポンスがモデルが生成したレスポンスと同じであることを示す署名付きアサーションも存在しないのです。¹

その欠如こそが攻撃対象領域となります。

実地データ

研究者たちは3つのマーケットプレイス（Taobao、Xianyu、Shopifyホストのストアフロント）から28個の有料ルーターを購入し、パブリックコミュニティから400個の無料ルーターを収集しました。彼らは各ルーターを、仕込んだ認証情報、既知のペイロード、マーカー文字列を含む計測されたリクエストで一連のプローブを実行したのです。¹

発見されたのは次の通りです：

適応型回避の発見こそ、眠れなくさせるものです。適応型回避トリガーとは、ルーターがほとんどの時間は正常に振る舞い、特定の条件下（特定のリクエスト形状、特定のクライアントフィンガープリント、特定の頻度など）で攻撃行動に切り替わることを意味します。ランダムなリクエストをサンプリングしても検出できません。なぜなら、ルーターはサンプリングされていることを察知し、大人しく振る舞うからです。

カナリア認証情報はトリップワイヤーです。誰かが使おうとすると発火します。17個のルーターがそれらに「触れた」ということは、少なくとも17個のルーターが転送中のペイロードから認証情報を抽出し、AWSに対して使用を試みたことを意味するのです。¹ 要旨ではルーターごとの正確なメカニズムは詳述されていませんが、トリップワイヤーの設計上、触れる=使用となります。

研究者所有の秘密鍵からETHを抜き取った1個のルーターは、より強力な発見です。プロンプト内の秘密鍵は認証情報トリップワイヤーではなく、ルーターが実際にウォレットを空にした場合にのみ侵害の証拠を生み出す囮なのです。1個のルーターがそれを実行しました。¹

2つの汚染研究

研究者たちはさらに2つの研究を実施し、表向きは無害なルーターがサードパーティの露出を通じて同じ攻撃対象領域に引き込まれる可能性があることを示しました。

研究1：リークしたOpenAIキー。 研究者たちは、開発者のミスで露出したかのように、動作するOpenAI APIキーをリークさせました。観察期間中、そのリークした1個のキーは、要旨によれば、それを拾ったルーターを通じて1億個のGPT-5.4トークンと「7つ以上のCodexセッション」を生成したのです。¹ 誰か（または複数人）がそのキーを見つけ、それを使ってコミュニティルーターを通じてリクエストをルーティングし、1億トークン分の計算を使い果たしました。ルーターは盗まれたキーのロンダリング層だったのです。

研究2：脆弱な設定の囮。 研究者たちは脆弱な設定の囮エンドポイントを立ち上げました。囮は20億の課金トークン、440のCodexセッションにわたる99の認証情報、そして決定的に401セッションが既に自律的なYOLOモードで稼働していたことを生み出しました。¹

401の自律セッションが、すでに1つの囮セットを通じてルーティングされていたのです。これらのセッションはすべて、悪意のある仲介者がツール呼び出しを注入し、秘密情報を持ち出し、またはモデルの出力を改ざんできる生きた攻撃対象領域であり、エージェントはループに人間がいない状態で、返ってきたものを何でも実行してしまいます。401という数字は、1つの研究用囮が捕捉したものです。制御されていない仲介者を通じてルーティングしている運用中の母集団は、必然的にもっと大きくなります。

2つのコア攻撃クラスと2つの適応型バリアント

論文は2つのコア攻撃クラスと2つの適応型回避バリアントを形式化しています。要旨は分類について明示的で、AC-1とAC-2がコアクラスであり、AC-1.aとAC-1.bがAC-1のバリアントです。研究用プロキシMineは、4つのパブリックエージェントフレームワークに対して「4つすべての攻撃クラス」（要旨の表現）を実装しています。¹

AC-1：ペイロード注入（コアクラス）。 ルーターはレスポンスを改ざんし、クライアントエージェントが動作する追加の指示、ツール呼び出し、またはコンテンツを注入します。エージェントはモデルからの出力を読んでいると思い込んでいますが、実際にはルーターの所有者からの出力を読んでいるのです。

AC-2：秘密情報の持ち出し（コアクラス）。 ルーターは転送中のリクエストとレスポンスから秘密情報（APIキー、トークン、秘密鍵、認証情報のように見えるものすべて）を読み取り、攻撃者のインフラに送信します。

AC-1.a：依存関係を標的とした注入（AC-1の適応型バリアント）。 リクエストが特定の依存関係またはコンテキストに一致する場合にのみ注入が発動します。特定のライブラリに関するリクエストの場合のみ、特定の関数が参照される場合のみ、特定のファイルパスがプロンプトに現れる場合のみ発動するのです。選択的なトリガーにより、ランダムテストでは攻撃が見えなくなります。

AC-1.b：条件付き配信（AC-1の適応型バリアント）。 ルーターは特定の条件下（時間帯、リクエスト頻度、クライアントフィンガープリント）でのみ悪意のあるペイロードを配信します。同じ検出回避ロジックです。

これらの攻撃クラスはすべて、クライアントにもアップストリームモデルにも見えません。両端ともルーターを信頼しているからです。クライアントには正常なレスポンス形状が見えます。モデルには正常なリクエスト形状が見えます。ルーターは中間で何でも自由に行うことができ、どちらの側も改ざんを検出する暗号学的手段を持たないのです。¹

構成パターン、1つ下の層で

私は同じ構造的バグについて繰り返し書いてきました。個別に承認されたコンポーネントが構成されて承認されていない動作になるというものです。Trivy-to-LiteLLMはパッケージ層での構成でした。サイレント送信はツール記述層での構成でした。MCPツール汚染はプロトコル層での構成でした。axiosメンテナー侵害は人間のメンテナー層での構成でした。

ルーター攻撃はネットワーク層での構成です。クライアントはルーターを呼び出す権限があります。ルーターはアップストリームモデルを呼び出す権限があります。アップストリームモデルは応答する権限があります。ホップはすべて承認されています。それらの承認されたホップの構成が、誰も暗号学的に封印しようとしなかった信頼境界を越えるため、ペイロード注入と秘密情報の持ち出しが大規模に発生するのです。¹

これは単一の層では修正できません。構成の層で修正する必要があります。つまり、クライアントはレスポンス形状、ツール呼び出し、コンテンツがすべてアップストリームモデルが生成しうるものと一致することを独立に検証するまで、ルーターを敵対的なものとして扱わなければならないのです。

論文が評価する3つの防御策

論文は攻撃クラスに対する3つのクライアント側防御策を評価しています。¹

1. Fail-closedポリシーゲート。 クライアントはレスポンス形状、許可されたツール呼び出し、許可されたURL、許可されたコマンドに関するポリシーを強制します。ポリシー外のものはfail-closedとなり、クライアントはリクエストを許可する代わりに拒否します。

2. レスポンス側の異常検知。 クライアントはレスポンス形状の異常、異常なトークンパターン、または既知の攻撃マーカー（未知のホストへのURL、疑わしい認証情報パターン、異常なツール呼び出し構造）を含む出力を監視します。

3. 追加のみの透明性ログ。 クライアントはすべてのリクエストとレスポンスを、後から誰も改ざんできない追加のみのログに書き込みます。ログは攻撃を防ぐものではありませんが、法的に追跡可能にするものです。

これらはどれも銀の弾丸ではありません。私の見解では、fail-closedポリシーゲートが3つの中で最も強力です。攻撃を検出しようとするのではなく、明示的な許可リスト外のものすべてを拒否するからです。しかし要旨は防御策をランク付けしていないため、これは論文の発見ではなく私の意見として扱ってください。異常検知は正常に見える攻撃を見逃しますし、適応型回避バリアント（AC-1.aとAC-1.b）は特にテスト条件下で正常な動作を模倣します。ポリシーゲートはポリシーの品質次第であり、「モデルのレスポンスはどのように見えるべきか」に関する完全なポリシーを書くのは困難です。

実際に何をすべきか

自分で構築していないルーターを通じてLLM APIを呼び出すエージェントを実行している場合：

1. 運用者を信頼できない限り、マーケットプレイスで購入したルーターやパブリックコミュニティから入手したルーターの使用を停止してください。 ここでの「信頼」とは、「マーケットプレイスで良いレビューがある」ということではなく、外部的な根拠（既知のチーム、署名された契約、執行可能な法的管轄区域など）を持っていることを意味します。

2. ハーネスにfail-closedポリシーゲートを追加してください。 Claude Codeでは、明示的な許可リスト外のツール呼び出しを拒否するPreToolUseフックと、次のモデルターンに渡す前にレスポンス形状を検証するPostToolUseフックを意味します。フックスタックがfail-closedポリシー層となります。

3. 自分が制御していないルーターを通じてYOLOモードを実行しないでください。 ハニーポット内の401の自律セッションが前例です。ルーターが敵対的で、セッションが自律的なら、ルーターがあなたのマシンを操作していることになります。

4. すべてをログに記録してください。 追加のみの透明性ログがインシデントの再構築を可能にします。すべてのリクエスト、すべてのレスポンス、すべてのツール呼び出しを、ルーターが到達できない場所に保存してください。

5. エージェントインフラを運用している場合は、暗号学的整合性を強制してください。 クライアントを運用し、アップストリームを運用しているなら、クライアントでリクエストに署名し、アップストリームで署名を検証してください。それが唯一の本当の修正策です。ルーターは引き続き平文を見ることができますが、署名を無効にせずに何かを改ざんすることはできなくなります。

不快な示唆

ルーター攻撃対象領域は、エージェントエコシステムがセキュリティよりも速くインフラを出荷している明確な例です。あらゆるモデルに対して1つのAPIキーを求める人々がいます。価格裁定を求める人々もいます。地域アクセスを求める人々もいます。ルーターはそのすべてを提供します。市場はそれに報酬を与えます。セキュリティ監査は行われていません。

MCP攻撃対象領域には50件の文書化された脆弱性があります。サプライチェーン攻撃対象領域には、1週間で5つのエコシステムを横断したTeamPCPキャンペーンがあります。サイレント送信攻撃対象領域にはClinejectionとMCPToxベンチマークがあります。そして今、ルーター攻撃対象領域が加わりました。428個のルーターが研究され、9個が悪意のあるコードを能動的に注入し、17個が仕込まれた認証情報に触れ、1個がETHを抜き取り、401の自律セッションがすでに敵対的なインフラ上で稼働していました。¹

パターンは毎回同じです。エージェントスタックの新しい層を構築する。開発者は監査される前に新しい層を採用する。攻撃者が現れる。研究者が現れる。コミュニティは発見を文書化する。注意を払っていた運用者はデプロイメントにパッチを当てる。注意を払っていなかった運用者は苦い方法で気付く。

ルーター攻撃対象領域は「研究者が今まさに文書化したばかり」の段階にあります。デプロイメントにパッチを当てる時間があります。使ってください。

FAQ

この文脈におけるLLM APIルーターとは何ですか？

クライアントとアップストリームモデルプロバイダーの間に位置し、OpenAI互換のAPIを公開し、リクエストを1つ以上のアップストリームモデルにディスパッチするサードパーティサービスのことです。すべてのリクエストとレスポンスに平文アクセス権を持つアプリケーション層のプロキシとなります。¹

これはCDNや通常のHTTPプロキシとどう違うのですか？

CDNはアプリケーションペイロードを読み取らずにバイトを転送します。LLM APIルーターはJSONを読み、アップストリームを選択し、オプションでリクエストを書き換え、転送し、レスポンスを読み、オプションでレスポンスを書き換えます。単なるトランスポートではなく、データに対してアプリケーションレベルの処理を行っているのです。¹

TLSは悪意のあるルーターから私を守ってくれますか？

いいえ。TLSはクライアントからルーターへ、そしてルーターからアップストリームモデルへのバイトを保護します。ルーターはTLSを終端し、平文を読み、反対側で再暗号化します。TLSはルーターからペイロードを保護することはしないのです。¹

レスポンスを能動的に注入しているルーターをどう検出できますか？

ルーターが適応型回避を使用している場合、信頼性をもって検出することはできません。論文のAC-1.aとAC-1.b攻撃クラスは、運用条件下でのみ発動することで検出回避を特に狙っています。¹ 最善策は、事後に攻撃を検出しようとするのではなく、明示的な許可リスト外のものすべてを拒否するfail-closedポリシーゲートです。

api.anthropic.comに対してClaude Codeを直接実行しています。影響はありますか？

本論文で説明されているルーター攻撃クラスによる影響はありません。なぜなら仲介者なしでAnthropicを直接呼び出しているからです。攻撃対象領域は特にサードパーティルーターに限定されます。何らかの理由（企業ゲートウェイ、レート制限回避、モデルアグリゲーターなど）でプロキシを通じてClaude Codeをルーティングしている場合、そのプロキシを監査すべきです。

OpenRouter、LiteLLM、または他の有名なアグリゲーターはどうですか？

論文は特定のマーケットプレイス（Taobao、Xianyu、Shopifyホストのストアフロント）から購入した28個の有料ルーターと、パブリックコミュニティリストから収集した400個の無料ルーターを研究しています。¹ 名指しされた製品の具体的なリストは公開していません。論文の要点は構造的なものです。信頼のための別の根拠がない限り、どのルーターも信頼できない仲介者となります。有名なアグリゲーターが自動的に安全というわけではなく、単により目立つだけで、これは別の性質なのです。

研究者が見つけた401の自律セッションについて、何をすべきですか？

それらのセッションは、研究者の囮を通じてトラフィックをルーティングした他の運用者のものです。自分で構築していないルーターを通じて自律エージェントセッションを実行している場合、最初のステップは停止することです。2番目のステップは、そのルーターを通過したすべての認証情報をローテーションすることです。3番目のステップは、異常なツール呼び出しや出力についてセッションログを監査することです。

参考文献