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

研究者はTaobao、Xianyu、そしてShopifyでホストされるストアフロントから28個の有料LLM APIルーターを購入し、さらに公開コミュニティから400個を収集しました。仕掛けた認証情報を含むリクエストで計測を行い、各ルーターがそのトラフィックをどう扱うかを調査したのです。¹

そのうち17個のルーターが、リクエストに仕込まれたAWSのカナリア認証情報に触れていました。1個は、おとりとして配置された秘密鍵からETHを抜き取っていました。研究チームがハニーポットとして用意したOpenAIキーの漏洩は、撤収するまでに1億GPT-5.4トークンを消費し、アブストラクトによれば「7回を超えるCodexセッション」を生成していたのです。¹ 別途、脆弱に設定されたおとりからは、課金対象の20億トークン、440件のCodexセッションにまたがる99件の認証情報、そしてすでに自律的なYOLOモードで稼働中の401セッションが確認されました。¹

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

TL;DR

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

要点

• エージェント運用者へ： クライアントと上流モデルの間に挟まるすべてのLLM APIルーターは、リクエストと応答のすべてに平文でアクセスできるアプリケーション層のプロキシです。暗号学的な完全性は一切強制されていません。マーケットプレイスで購入したり、公開コミュニティのリストから引っ張ってきたルーターを使っているなら、信頼できると証明されるまでは敵対的な仲介者として扱うべきでしょう。
• ハーネス構築者へ： PreToolUseフックはツール実行前に動作しますが、悪意あるルーターは生成後かつフックに到達する前にモデル応答を書き換えます。フックスタックに応答側の検証を追加し、異常な応答形状に対してはフェイルクローズのポリシーゲートを設けることを検討してください。
• YOLOモードで稼働させている方全員へ： 研究者のハニーポットでは、401件のセッションがすでに自律的なYOLOモードで稼働していました。¹ 自律セッションにおいてツール呼び出しを書き換えるルーターは、あなたが読む応答を書き換えるルーターよりも遥かに大きな影響範囲を持ちます。自分が管理していないルーター経由でYOLOモードを動かしてはなりません。

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

この論文の文脈において、LLM APIルーターとは、クライアントと1つ以上の上流モデルプロバイダーの間に位置するサードパーティサービスのことです。ユーザーはOpenAI互換のAPIを使ってルーターにリクエストを送信します。ルーターはそのリクエストを選択した任意の上流 —— GPT-5、Claude、Gemini、オープンウェイトモデル、あるいはそれらすべてのプール —— にディスパッチし、同じ形で応答を返します。¹

ルーターが存在するのは、LLMエコシステムが雑然としているからです。人々はすべてのモデルで使える1つのAPIキーを求めます。価格裁定を望む声もあります —— トークンをまとめ買いして安く再販するのです。プロバイダーへの直接アクセスが制限されている地域向けの地理的な回避策も求められています。単一のクライアントで複数のモデルをテストしたいというニーズもあります。どれも正当な理由であり、健全なルーター市場はそのすべてに応えるものです。

問題は、ルーターがアプリケーション層のプロキシであることです。バイトを転送するだけではありません。リクエストJSONを読み取り、上流を選び、必要に応じてリクエストを書き換え、転送し、応答を読み取り、必要に応じて応答を書き換えて、返却する。そのパイプラインのすべての段階が、ルーターのインフラ上で平文として処理されているのです。¹

ここにはTLSに相当するものは存在しません。TLSはクライアントからルーターまで、そしてルーターから上流モデルまでのバイトを保護します。ルーター自身からペイロードを守ることは何一つしません。元のクライアントと最終的なモデル間で暗号学的な完全性を強制しているプロバイダーは存在しないのです —— モデルが受信したリクエストがクライアントの送信したものと同一であるという署名付きの保証はなく、クライアントが受信した応答がモデルの生成したものと同一であるという署名付きの保証もありません。¹

その不在こそが、攻撃対象領域です。

実地データ

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

判明した内容は次のとおりです。

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

カナリア認証情報はトリップワイヤであり、誰かが使おうとすると発火します。17個のルーターがそれらに「触れた」ということは、少なくとも17個のルーターが送信中のペイロードから認証情報を抽出し、AWSに対して使用を試みたということです。¹ アブストラクトには各ルーターの正確な手口までは書かれていませんが、トリップワイヤの設計上、触れた＝使ったを意味します。

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

2つの汚染研究

研究者は、表面上は無害なルーターであっても、サードパーティ経由の曝露を通じて同じ攻撃対象領域に引き込まれ得ることを示すため、2つの追加研究を実施しました。

研究1：漏洩したOpenAIキー。 研究者は、開発者のミスで露出したかのように、動作するOpenAI APIキーを漏洩させました。観測期間中、その漏洩した単一のキーは —— アブストラクトによれば —— それを拾ったルーター経由で1億GPT-5.4トークンと「7回を超えるCodexセッション」を生成したのです。¹ 誰か —— あるいは多くの誰か —— がそのキーを発見し、コミュニティルーター経由でそれを使ってリクエストをルーティングし、1億トークン分の計算資源を使い果たしたわけです。ルーターは、盗まれたキーのためのロンダリング層として機能していました。

研究2：脆弱に設定されたおとり。 研究者は脆弱に設定されたおとりのエンドポイントを立ち上げました。そのおとりから得られたのは、課金対象の20億トークン、440件のCodexセッションにまたがる99件の認証情報、そして —— ここが決定的な一行です —— すでに自律的なYOLOモードで稼働中の401セッションでした。¹

401件の自律セッションが、単一のおとり群を経由してすでにルーティングされていたのです。そのどれもが、悪意ある仲介者がツール呼び出しを注入したり、秘密を漏洩させたり、モデルの出力を書き換えたりできる生きた攻撃対象領域であり、エージェントは人間のループを介さずに返ってきたものをそのまま実行していました。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の適応型バリアント）。 悪意あるペイロードは特定の条件下（時刻、リクエスト頻度、クライアントフィンガープリント）で配送されます。同じ検出回避のロジックです。

これらの攻撃クラスはいずれも、クライアントにも上流モデルにも見えません。なぜなら、両端ともルーターを信頼しているからです。クライアントには正常な応答形状が見えます。モデルには正常なリクエスト形状が見えます。ルーターは中間で好きなことができ、どちらの側にも改ざんを検出する暗号学的手段はないのです。¹

コンポジションのパターン、一層下へ

同じ構造的バグについて何度も書き続けています。個別には承認されたコンポーネントが、組み合わさると承認されていない挙動を生むというものです。TrivyからLLM LiteLLMへはパッケージ層でのコンポジションでした。サイレント流出はツール記述層でのコンポジションでした。MCPツール汚染はプロトコル層でのコンポジションでした。axiosメンテナーの侵害は人間メンテナー層でのコンポジションでした。

ルーター攻撃は、ネットワーク層でのコンポジションです。クライアントはルーターを呼び出す権限を持っています。ルーターは上流モデルを呼び出す権限を持っています。上流モデルは応答する権限を持っています。ホップごとに見ればすべて承認済みなのです。承認されたそれらのホップが組み合わさると、大規模なペイロード注入と秘密情報の抜き取りが発生します。なぜなら、そのコンポジションが、誰も暗号学的に封印しようとしなかった信頼境界を跨いでいるからです。¹

これは単一の層では修正できません。コンポジション層で修正するしかなく、それはつまり、応答形状、ツール呼び出し、コンテンツのすべてが、上流モデルが妥当に生成し得るものと一致していることを独立に検証するまで、クライアントがルーターを敵対的なものとして扱わなければならない、ということです。

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

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

1. フェイルクローズのポリシーゲート。 クライアントは応答形状、許可されたツール呼び出し、許可されたURL、許可されたコマンドに対するポリシーを強制します。ポリシー外のものはすべてフェイルクローズ —— 許可ではなく拒否 —— となります。

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

3. 追記専用の透明性ログ。 クライアントはすべてのリクエストと応答を、遡及的に書き換えることのできない追記専用のログに書き込みます。これは攻撃を防ぐものではありませんが、フォレンジックによる追跡を可能にします。

いずれも銀の弾丸ではありません。私の読みとしては、3つのうちフェイルクローズのポリシーゲートが最も強力です。なぜなら攻撃の検出に依存せず、明示的な許可リストの外にあるものをすべて拒否するからです —— ただしアブストラクトは防御策にランク付けをしていないので、これは私の意見であって論文の結論ではないものとして扱ってください。異常検知は正常に見える攻撃を見落としますし、適応型回避バリアント（AC-1.aとAC-1.b）はテスト条件下で正常に見えるよう特別に設計されているのです。ポリシーゲートはポリシーの出来次第でしかなく、「モデル応答はどうあるべきか」の完全なポリシーを書くのは困難です。

実際に何をすべきか

自分で構築したのではないルーター経由でLLM APIを呼び出すエージェントを運用しているなら、次のことを行ってください。

1. 運用者を信頼できない限り、購入したルーターや公開コミュニティから取得したルーターの使用を止めましょう。 ここでの「信頼」とは、何らかの外部的な根拠 —— 既知のチーム、署名済みの契約、法的に行使可能な管轄 —— があることを意味し、「マーケットプレイスで良いレビューがついている」ことではありません。

2. フェイルクローズのポリシーゲートをハーネスに追加しましょう。 Claude Codeでは、これは明示的な許可リストの外にあるツール呼び出しを拒否するPreToolUseフックと、次のモデルターンに渡す前に応答形状を検証するPostToolUseフックを意味します。フックスタックこそがフェイルクローズのポリシー層となるのです。

3. 自分が管理していないルーター経由でYOLOモードを動かしてはなりません。 ハニーポットの401件の自律セッションが前例です。ルーターが敵対的であり、あなたのセッションが自律的なら、ルーターがあなたのマシンを動かしていることになります。

4. すべてをログに残しましょう。 追記専用の透明性ログこそ、インシデントを再構成するための手段です。すべてのリクエスト。すべての応答。すべてのツール呼び出し。ルーターの手の届かないどこかに保存してください。

5. エージェントインフラを運用しているなら、暗号学的な完全性を強制しましょう。 クライアントと上流の両方を運用しているなら、クライアント側でリクエストに署名し、上流側で署名を検証してください。それこそが唯一の真の修正策です。ルーターは依然として平文を見ることはできますが、署名を無効化せずに何も書き換えることはできなくなります。

居心地の悪い含意

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

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

パターンは毎回同じです。エージェントスタックの新しい層を構築する。その新しい層は、監査される前に採用される。攻撃者が現れる。研究者が現れる。コミュニティが発見内容をまとめる。注意を払っていた運用者は自分のデプロイメントにパッチを当てる。注意を払っていなかった運用者は、痛い目を見てから気づくのです。

ルーターの攻撃対象領域は、「ちょうど研究者がまとめ上げた」段階にあります。あなたのデプロイメントにパッチを当てる余地があります。それを使ってください。

FAQ

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

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

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

CDNはアプリケーションペイロードを読まずにバイトを転送します。LLM APIルーターはJSONを読み取り、上流を選び、必要に応じてリクエストを書き換え、転送し、応答を読み取り、必要に応じて応答を書き換えます。単なる転送ではなく、データに対するアプリケーションレベルの処理を行っているのです。¹

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

いいえ。TLSはクライアントからルーターまで、そしてルーターから上流モデルまでのバイトを保護します。ルーターはTLSを終端し、平文を読み取り、反対側で再暗号化します。TLSはペイロードをルーター自身から守ることは何もしません。¹

応答を積極的に注入しているルーターをどうやって検出できますか？

ルーターが適応型回避を使っているなら、確実な検出はできません。論文のAC-1.aとAC-1.b攻撃クラスは、運用条件下でのみ発火することで検出回避を明示的に狙っています。¹ 最善の策は、攻撃を事後的に検出しようとするのではなく、明示的な許可リストの外にあるものを拒否するフェイルクローズのポリシーゲートです。

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

この論文で述べられているルーター攻撃クラスについては、影響を受けません。仲介者を介さずにAnthropicを直接呼び出しているからです。攻撃対象領域は特にサードパーティのルーターです。何らかの理由 —— 企業ゲートウェイ、レート制限の回避、モデルアグリゲーター —— でClaude Codeをプロキシ経由で動かしているなら、そのプロキシを監査すべきでしょう。

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

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

研究者が見つけた401件の自律セッションについて、どうすればよいですか？

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

参考文献