悪性MCPツールが文脈を丸ごと盗む｜ContextLeak

AIエージェントに悪意あるツールを1つ繋がせるだけで、利用者が入力した指示文・エージェントとの会話履歴・その環境に導入済みのツール一覧が、そのままツールの引数として攻撃者側へ送られる——2026年8月28日にarXivで公開された査読前論文「ContextLeak」が、この手口の成立条件と実効性を示しました。

この攻撃が厄介なのは、ツールの説明文に「機密を送れ」といった悪意ある命令を一文も書かない点です。強化学習で「エージェントに選ばれやすく、引数に文脈を詰め込ませやすい」名前と説明文を最適化するだけ。そのため論文が試した検知型の防御は、いずれもほぼ100%見逃しました。

まず確認すべきは、自社のAI利用で誰がどのツール（MCPサーバ）を繋いでよいことになっているかです。攻撃はそこから始まります。

この記事でわかること

  • MCPとは何で、気づかないうちにどこで動いているのか
  • ContextLeak攻撃が成立する3つの条件と、報告された成功率
  • なぜ既存のプロンプトインジェクション検知器をすり抜けるのか
  • 「ツール一覧の流出」が情シスにとって何を意味するのか
  • 現時点で現実的に打てる手（公的指針への入口）

MCPとは何者か

MCP（Model Context Protocol）とは、AIアプリケーションを外部のデータやツールに接続するためのオープンな標準規格です。公式ドキュメントはこれを「AIアプリのUSB-Cポート」と表現しています。AIに社内DBを検索させる、ファイルを読ませる、SaaSのAPIを叩かせる——こうした「AIから外部システムへの手足」を規格化したものだと考えてください。

「うちはMCPなんて導入していない」と思われるかもしれません。しかしMCPは単体で導入するものではなく、既に使われているAIクライアントの中に組み込まれて動いています。公式サイトが対応クライアントとして挙げているのは、Claude、ChatGPT、Visual Studio Code（Copilot Chat）、Cursor など。つまり、開発部門がVS CodeのCopilotを使っている、あるいはChatGPTのコネクタが有効になっている——その時点で、自社にMCPのツール接続面が存在します。資産管理台帳に「MCPサーバ」という行が立つことはまずありません。確認すべきは製品名ではなく、各クライアントの設定（VS Codeなら mcp.json、デスクトップアプリなら設定ファイル内のMCPサーバ定義）に何が登録されているかです。

何が起きたのか：攻撃が成立する3つの条件

論文が整理する成立条件はシンプルです。

  1. エージェントが、その悪性ツールをタスク実行用に選ぶ
  2. エージェントが、自分の文脈（指示文・会話履歴・ツール一覧）を引数として渡す
  3. ツールの実装が、受け取った引数を攻撃者のサーバへ送信する

3番目は攻撃者が自分で書くコードなので自明です。難しいのは1と2で、ContextLeakはここを強化学習で最適化しました。攻撃用のLLMに「ツール名と説明文」を生成させ、想定利用者の文脈を使ったシミュレーション上で報酬（選ばれたか／引数がどれだけ元の文脈を再現したか）を与えて学習させる、という手順です。人手でうまい説明文をひねり出すのではなく、機械的に量産できる形にした点が新しいところです。

何が、どれだけ盗まれるのか

ToolBench（メール・金融・医療・旅行など10ドメイン）とToolAlpacaを使った評価で報告された数値です。

盗まれる対象 悪性ツールが選ばれた率 復元の精度
利用者の指示文（プロンプト） 92% 編集距離スコア 0.99（ほぼ原文どおり）
エージェントとの会話履歴 89% 編集距離スコア 0.85
導入済みのツール一覧 86% F1 0.68（適合率0.76／再現率0.65）

比較対象として試された既存の悪性ツール攻撃（ObliInjection、ToolHijacker、AMA）は、選ばれる率かツール一覧の復元精度のどちらかが大きく劣りました（たとえばAMAは選択率0.34／F1 0.06）。検証に使われたバックエンドLLMは Qwen-3-8B、GPT-OSS-20B、Gemma-4-E4B-it、Qwen-3.5-9B、GPT-4.1、GPT-5-mini、GPT-5.1 と幅広く、特定のモデルだけの弱点ではありません。

さらに実務的に重いのが転移の結果です。Qwen3.5-9Bだけで学習させた攻撃ツールが、Claude Code（Sonnet 4.6）に対しても22%の確率で選ばれたと報告されています。攻撃者が標的の使うモデルを知らなくても、5回に1回は当たる計算です。

なぜ既存の防御をすり抜けるのか

答えは一行です。説明文のどこにも「悪意ある命令」が書かれていないから。プロンプトインジェクション検知器は「これまでの指示を無視しろ」「秘密を送れ」といった命令文のパターンを探しますが、ContextLeakが生成するのは、単に業務上もっともらしく、かつ引数を多く要求する説明文にすぎません。

防御の種類 試されたもの 結果
予防型（頑健化ファインチューニング） StruQ、SecAlign、Meta-SecAlign 攻撃選択率は0.08〜0.42まで低下したが、正規のツール選択精度も0.08〜0.18へ崩壊
検知型 PromptGuard、DataSentinel、PromptArmor、MCPScanのメタデータ監視 誤検知は少ないが、見逃し率はほぼ100%

予防型の結果は「安全性は実用性の低下と引き換えになる」という論文の指摘どおりで、ツールを正しく選べないエージェントは業務では使えません。ガードレール製品を1つ買えば解決する類の問題ではない、というのが現時点での正直な読み方です。

「ツール一覧の流出」は社内システムの構成図の流出

3つの流出対象のうち、情シスとして最も気にすべきはツール一覧だと考えます。指示文や会話履歴は「そのタスク限りの情報」ですが、ツール一覧はタスクをまたいで有効な、環境そのものの情報だからです。論文もこれを、タスク固有の文脈と区別して「クロスタスクな文脈」と位置づけています。

実際のMCPツール名は、業務システムの名前をそのまま反映しがちです。社内で命名すれば salesforce_query hr_master_lookup prod_db_readonly のような名前が並ぶでしょう。攻撃者から見れば、これは「この会社はどのSaaSを使い、どの基幹システムにAI経由の口が開いていて、書き込み権限まであるのはどれか」が1回のツール呼び出しで分かる偵察情報です。侵入テストで時間をかけて集める種類の情報が、ほぼ無料で手に入ることになります。

もう1点、防御側に有利な事実も指摘しておきます。利用者の指示文は編集距離スコア0.99、つまりほぼ原文のまま引数に入ると報告されています。裏を返せば、ツール呼び出しの引数に自分が書いた指示文がそっくり入っていたら、それは明確な異常です。人間の承認ダイアログは万能ではありませんが、この一点に絞れば気づける可能性があります。引数を要約表示ではなく全文表示できるクライアントを選ぶ、という選定基準はここから出てきます。

現場目線の課題

率直に言えば、この話の一番つらいところは技術ではなく可視性です。MCPサーバの追加は、多くのクライアントで設定ファイルに数行足すだけで済みます。ソフトウェアのインストール申請も、ネットワーク機器の設定変更も要りません。現場のエンジニアが「便利そうだから」と入れたものを、情シスが知る手段が事実上ない。IPAが「情報セキュリティ10大脅威 2026」の組織編で「AIの利用をめぐるサイバーリスク」を初選出で3位に挙げたのは、こうした管理外のAI利用が広がっている実態を踏まえたものでしょう。

限られた人員で全端末の設定ファイルを追いかけるのは現実的ではありません。だからこそ、禁止して見えなくするより、認めたうえで登録させる——つまりツールの許可リスト方式に倒すのが、当面もっとも現実的だと考えます。禁止したところで導入は止まらず、把握できなくなるだけです。

情シスはどうすべきか

この分野は防御技術がまだ確立していないため、自前で長大なチェックリストを作るより、まず公的な整理を土台にするのが早道です。

  • 全社の考え方を整える：IPAのAIセキュリティのページに、利用者向け・開発者向けの資料がまとまっています。特にAI利用者のためのセキュリティ豆知識はスライド形式で、社内勉強会にそのまま使えます。
  • MCP特有の攻撃を理解する：OWASPのMCP Tool Poisoningが、緩和策として接続先MCPサーバの許可リスト化、高権限ツールの分離、機微な操作へのLLM外での明示承認などを挙げています。ContextLeakにも方向性としてそのまま効きます。
  • 啓発を軽視しない：結局のところ「知らないMCPサーバを繋がない」という判断は現場の一人ひとりが行います。IPAの対策のしおりのような教材を使った地道な周知が、技術的対策の空白を埋めます。

あわせて、社内AI連携の棚卸しという観点ではAIエージェントのツール呼び出しで機密流出｜査読前研究、接続先そのもののリスクについてはMCPサーバ91.8%が認証なし｜研究解説やMCP Toolboxに認証回避3件｜AIのDB接続が危険もあわせて確認してください。脅威分類の全体像はOWASP LLM Top10 2026、専門家と実データの差が参考になります。

この研究の限界と留意点

本稿が扱ったのはarXivに投稿された査読前（プレプリント）の研究であり、結果は今後の査読や追試で変わりうるものです。以下の点は割り引いて読む必要があります。

  • 評価はToolBench・ToolAlpacaというベンチマーク環境で行われたもので、実運用のエージェント構成をそのまま再現したものではありません。
  • 92%といった高い数値は主に「学習時と同じドメイン」での結果です。Claude Codeへの転移は22%で、条件が変われば効果は落ちます。
  • 論文は攻撃手法の提示が主眼で、有効な防御策は示されていません。「今すぐこれを導入すれば防げる」という結論は本研究からは出せません。
  • 実際にこの手法を使った攻撃が観測されたという報告ではありません。あくまで研究上の実証です。

まとめ

  1. 悪意ある命令を書かない攻撃が成立した。強化学習で最適化したツール名と説明文だけで、指示文92%・会話履歴89%・ツール一覧86%の確率で悪性ツールが選ばれ、指示文は編集距離スコア0.99でほぼ原文のまま流出した（いずれも査読前研究の報告値）。
  2. 既存の検知器は機能しなかった。PromptGuardなど4種の検知型防御は見逃し率ほぼ100%、頑健化ファインチューニングは正規のツール選択精度まで壊した。製品導入だけでは解決しない。
  3. 効くのは入口の管理。MCPはVS CodeやChatGPTなど既存クライアントの中に既にある。禁止ではなく登録・許可リスト化で可視化し、ツール呼び出しの引数を全文確認できる運用に寄せることが、現時点で現実的な打ち手になる。

出典

タイトルとURLをコピーしました