中国のLLMルーター経由ログ約6TBに企業認証情報か　研究者が主張

Chaofan Shou氏（Fuzzland共同創業者）は、中国の有力LLMルーターから「Fable」のモデル呼び出しデータ約6TBを購入したとし、その中に機密性の高い認証情報が含まれていたと投稿した。同氏は、データ内の情報により、中国・CIS（独立国家共同体）地域の政府関連組織7件と、中国の主要企業19社に関連するシステムへアクセスできる可能性があると主張している。例としてHuawei、Xiaomi、NIO、MiniMaxの名を挙げた。11

ただし、これは研究者による未検証の主張である。挙げられた組織が侵害を受けたこと、あるいは実際にアクセスされたことを示す公的・独立した確認ではない。

ログに含まれていたとされるもの

Shou氏の説明と関連報道によれば、データには中継サービスへ送られた以下のような情報が含まれていたという。

• SSH秘密鍵
• VPN設定
• Alibaba Cloud（Aliyun）の認証情報
• GitLabトークン 113

これらは、有効なままで適切な対象にひも付き、かつ権限が強ければ、大きな影響を及ぼし得る。一方、公開情報からは、取得時点で認証情報が有効だったか、既に失効・ローテーション済みだったか、実際にどの権限を持っていたかは分からない。

なぜLLMルーターが認証情報の集積点になり得るのか

LLMルーター（リレー、プロキシ）は、アプリケーションやAIエージェントと、モデル提供元との間でリクエストを中継するサービスだ。構成によっては、プロンプト、エージェントのコンテキスト、ツール呼び出しの引数、モデルの応答を含むJSONペイロードを平文で扱う。

Shou氏らが共著した研究論文 Your Agent Is Mine は、こうしたルーターを、通信中のJSONを平文で見られるアプリケーション層のプロキシとして位置付ける。また、クライアントと上流モデルの間で暗号学的な完全性が強制されていない点を、供給網の攻撃面として指摘している。27

たとえば開発者が、AIコーディングエージェントに障害解析やデプロイ自動化をさせるため、秘密鍵、.envファイル、クラウドキー、VPNプロファイル、運用設定を会話やツール引数に渡すことがある。外部の中継サービスを経由していれば、その秘密情報も中継先に渡る可能性がある。

危険性は、ルーター事業者が意図的に情報を収集する場合だけではない。過剰なログ保存、不十分なアクセス制御、ルーター自体への侵害、保存ログの第三者への流出・再配布によっても、プロンプト履歴が再利用可能な認証情報の保管庫になり得る。

「閲覧」だけでなく「改変」のリスクも

今回の約6TBという主張は、特定のルーターによる不正を証明するものではない。しかし、外部仲介者が持つ構造的なリスクとは整合する。

Your Agent Is Mine では、LLMエージェントの供給網で悪意ある仲介者が行う攻撃を調査し、通信を見られるルーターがデータを収集するだけでなく、エージェントが実行する前のモデル応答やツール呼び出しの内容を変更し得ることを論じている。27

エージェントを業務に組み込む組織では、特に次の区別が重要になる。

• 受動的な漏えい：プロンプト、実行トレース、ツール引数に入った秘密情報が、ルーターのログに残る。
• 能動的な改変：仲介者が応答やツール呼び出しを書き換え、エージェントの次の操作に影響を与える可能性がある。
• 認証情報の悪用：エージェントの文脈に含まれる認証情報が露出したり、その使い方を誘導・操作されたりする可能性がある。

この研究は第三者LLMルーティングの攻撃面を示すものだが、後にShou氏が述べた約6TBのデータセットについて、出所、完全性、内容を独立に立証するものではない。27

現時点で確認されていないこと

公開されている情報だけでは、少なくとも以下は独立に確認されていない。

• 約6TBのデータセットが真正で完全であり、主張されたルーター由来であること
• 中継サービス運営者の身元、意図的にデータを販売したのか、外部からデータを盗まれたのか
• データの収集時期、保存期間、取り扱い方法
• 認証情報が有効だったか、対象組織に正しく帰属するか、主張されたアクセスに十分な権限を持っていたか
• Shou氏が認証情報を使用したか、システムにアクセスしたか、侵入が成功したか
• Huawei、Xiaomi、NIO、MiniMax、政府関連組織、またはルーター運営者からの公式確認・公式見解 113

従って「関連する」との表現は、データセット内に含まれていたと主張されているという意味にとどめるべきであり、企業や政府組織の侵害確認を意味しない。

外部LLMプロキシを使う組織が取るべき対策

個別の主張が最終的に裏付けられるかどうかにかかわらず、エージェント通信を受け取る外部の仲介サービスは、特権的な信頼境界として評価する必要がある。

1. プロンプトやエージェント文脈に秘密情報を入れない

秘密鍵、VPN設定、クラウドアクセスキー、アクセストークン、.envファイル、本番設定をプロンプトへ貼り付けない。送信前に秘密情報らしい文字列を検出し、ブロックまたはマスキングする仕組みをクライアント側や社内ゲートウェイに置く。

2. 長期固定の認証情報を、短命・最小権限の認証へ置き換える

ツールには、必要な時点でシークレットマネージャーやワークロードID基盤から取得する、用途限定・短期失効の認証情報を与える。エージェントのトレースやルーターログが露出しても、被害範囲を抑えやすい。

3. プロキシ経由の露出が疑われたらローテーションする

開発者、コーディング支援、AIエージェントが利用しているルーターやプロキシを棚卸しする。信頼できない、または実態不明の仲介者を通過した可能性があるSSH鍵、VPN認証情報、GitLabトークン、クラウドキーは更新し、SSH、VPN、GitLab、クラウドの監査ログに不審な操作がないか確認する。

4. 直結または自社管理ゲートウェイを優先する

可能ならモデル提供元へ直接接続するか、自組織が管理する内部ゲートウェイを使う。第三者のルーター、特に中国向けの中継を利用する必要がある場合は、運営主体、データ保存地域、再委託先、セキュリティ対策、インシデント通知条項、ログ保存・学習利用・販売・二次利用に関する約束を確認する。

5. エージェントが実行できる操作を絞る

機密性の高い操作には明示的な承認を求め、使用可能なツールと接続先を許可リスト化する。モデル識別子、応答形式、ツールスキーマ、外部向けツール呼び出しの予期しない変更を監視することも、仲介者による応答経路の改変リスクを下げる一助になる。27

6. エージェントログを本番の秘密情報と同等に扱う

可能な限り内容ログを無効化する。保存が必要なら、保存前に秘密情報をマスキングし、暗号化、厳格なアクセス制御、短く文書化された保存期間、無制限なエクスポートの防止を徹底する。ツール引数やエージェントの実行トレースも、ソースコードや本番認証情報と同じ水準で保護すべきだ。

まとめ

Shou氏の約6TBデータに関する説明は、現段階では未検証だが、軽視できない主張である。より重要なのは構造上の教訓だ。プロンプト、認証情報、ツール入力、応答を読めるLLMルーターは、単なる透明な通信経路ではない。

AIエージェントを導入する組織は、外部リレーを一つ追加するごとに信頼すべき計算基盤が広がると考え、プロンプト衛生、認証情報管理、ログ管理、実行制御を設計する必要がある。1127