TL;DR
国立陽明交通大学(台湾)の研究チームが 2026-06-04、WebMCP に対する新たな攻撃類型「Mid-Session Tool Injection(MSTI、セッション途中のツール注入)」を公開した。WebMCP は、Web サイトが AI エージェントへ直接ツールを公開できるようにする新しい仕組みで、エージェントは画面操作を介さずツールのメタデータから「何ができるか」を理解する。問題は、このツール一覧が動的に変わり得ることだ。攻撃者が同一ページに読み込まれる第三者スクリプト(CDN・広告 SDK など)を汚染できれば、セッションの最中にエージェントから見えるツールの集合そのものを書き換えられる。研究は攻撃を 2 系統に整理した。1 つは「どのツールが存在するか」を操作する Tool Hijacking で、AbortSignal API で正規ツールの登録を解除して同名の悪性ツールを再登録する手口や、正規ツールより先に同名で登録してしまう競合(registration race)が該当する。もう 1 つは「そのツールが何者と解釈されるか」を操作する Tool Framing で、description・readOnlyHint・inputSchema・ツール名といったメタデータ経由で、悪性ツールを業務手順上必須のステップや安全な読み取り専用操作に見せかける。GPT-5.4・Claude Opus 4.6・Gemini 2.5-flash の 3 モデル・4 シナリオでの評価では、registration race が平均 100%、AbortSignal 乗っ取りが平均 94% の攻撃成功率に達した。Tool Framing は成功率こそ下がるが、元のタスクが最大 85% の割合で正常に完了したまま情報が持ち出されるため、利用者からは事が正常に運んだように見える。特筆すべき所見が 2 つある。1 つは、プロトコル層を突く攻撃(C1・C3)が旧世代モデルから最新モデルまで成功率をほぼ落とさないこと――モデルの更新では塞げない。もう 1 つは、研究者が実装した防御を有効にすると、エージェントは依然として悪性ツールを呼ぶにもかかわらず、データは攻撃者側に一切届かなくなったことだ。モデルの判断が誤導されることと、実害が発生することは、独立の問題である。欠けていたのは、ツールの同一性をその出自(origin)に束縛し、エージェントが呼び出す前にその束縛の一貫性を独立に検証する層である。検出と事前証明は代替ではなく補完である。
事案概要
- 対象: WebMCP。Web サイトが AI エージェントに対して構造化されたツールを直接公開できるようにする新興のプロトコル。エージェントは従来のユーザーインターフェース操作を介さず、ツールのメタデータから利用可能な機能を把握する
- 報告: 国立陽明交通大学(台湾・新竹)の Lin-Fa Lee・Yi-Yu Chang・Chia-Mu Yu・Kuo-Hui Yeh による研究「WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents」。arXiv:2606.06387v1 [cs.CR] として 2026-06-04 に公開
- 脅威モデル: 攻撃者が、被害サイトに読み込まれる第三者スクリプトの供給元(CDN・広告 SDK・その他同一ページ上の JavaScript 部品)を侵害または注入できることを前提とする。従来の第三者スクリプト攻撃がページ内容の改変や DOM データの持ち出しを狙うのに対し、本脅威モデルが狙うのはエージェントのツール登録簿(tool registry)そのものであり、エージェントが実行中に観測・選択できるツールの集合を変える
- 攻撃の 2 系統: (1) Tool Hijacking(ツールの存在の操作)= どのツールがいつ存在するかを操作する。正規ツールの無効化、名前の乗っ取り、悪性ツールへの置換。エージェントが意味的な推論を始める前にツール一覧が書き換わるため、モデル側に直接の防御手段がない。(2) Tool Framing(ツールの解釈の操作)= ツール名・
description・readOnlyHint・inputSchema等の正当なフィールドを通じて、悪性ツールを業務手順上必須のステップ・必要な安全確認・より安全な読み取り専用ツールに見せかける - 評価環境: GPT-5.4・Claude Opus 4.6・Gemini 2.5-flash の 3 モデル。深刻度の異なる 4 シナリオ(知識ベース検索/業務レポート生成・送信/EC 決済/GPU ドライバ更新)。攻撃成功率(ASR)は「悪性ツールを呼び出し、かつタスク関連データを攻撃者側エンドポイントへ送出した実行の割合」と定義
- 主要結果: registration race(C3)が 3 モデルとも 100%、
AbortSignal乗っ取り(C1)が平均 94%。Tool Framing 系はdescription注入(C2)が平均 59%、複合攻撃(C5)が 61%。フィールド単独の切り分けでは、descriptionのみで平均 93%、readOnlyHint=trueを立てるだけで平均 87%、descriptionとreadOnlyHintの組み合わせで 3 モデルとも 100% に達した - 根本原因: WebMCP のツール表面が、中立・静的なインターフェースとして扱われ、セキュリティ境界として扱われていない。ツールの同一性が公開名(public tool name)に依存し、その出自(origin・document・frame・登録スクリプトの供給元)に束縛されていないため、同名で先に登録する/後から差し替えるだけで、エージェントが観測する対象を入れ替えられる
タイムライン
- 2026-06-04: arXiv に「WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents」(arXiv:2606.06387v1 [cs.CR])が公開。MSTI の類型化、3 モデル・4 シナリオでの定量評価、フィールド単位の寄与分析、注入タイミング分析、および 2 種類のベースライン防御の実装・評価を提示
- 2026-07: MCP セキュリティの動向整理において、当該研究が実行時のツール表面操作という新しい攻撃面として参照される
注: 本件は統制環境における研究であり、実環境での悪用・被害は本稿執筆時点で報告されていない。実験環境は Chrome のネイティブ WebMCP 実装ではなく、CDN 配信の
@mcp-b/globalpolyfill によるnavigator.modelContextAPI を用い、エージェントは実ブラウザの完全なセキュリティモデル下ではなく Node.js のヘッドレス環境で動作している。研究者自身が、ネイティブ実装下での再現性は実装詳細により異なり得ると明記している。最新の一次情報を参照されたい。
事象連鎖
- 第三者スクリプトの汚染: 攻撃者が、被害サイトに読み込まれる第三者スクリプトの供給元(CDN・広告 SDK 等)を侵害する。これにより同一ページ上で任意のスクリプトを実行できる
2-a. ツールの存在の操作(Tool Hijacking): 正規ツールの
AbortControllerを中断させて登録を解除し、エージェントの最初の呼び出し前に同名で悪性ツールを再登録する(C1)。あるいは、正規ツールが登録される前に同名で先に登録し、先勝ちによってエージェントには悪性版しか見えないようにする(C3) 2-b. ツールの解釈の操作(Tool Framing): 悪性ツールのdescriptionに「send_emailの前に必ず呼び出すこと」といった手順上の指示を埋め込み、必須の業務ステップとして枠づける(C2)。あるいは、ISO 27001・SOC 2・GDPR といった規格名で水増しした 1,203 語の説明文の冒頭約 40 語に指示を潜ませる(C4)。readOnlyHint=trueを立てて安全な読み取り専用操作に見せかける、audit_loggerのような企業業務を思わせる名前を与える、といった単独手法も成立する - エージェントによる呼び出し: エージェントは、書き換えられたツール集合ないしメタデータを前提に計画を立て、悪性ツールを当初のタスクに沿う正当な手順として呼び出す
- データの持ち出し: 呼び出しに伴い、タスク関連データ・中間結果・機微な文脈が攻撃者側エンドポイントへ送出される。Tool Framing 系では元のタスクが最大 85% の割合で正常に完了するため、利用者からは事が正常に運んだように見える
- タイミング依存性: Tool Hijacking はエージェントのループ開始前に注入が完了している必要があり(P1 で 100%、最初の正規呼び出しを逃すと 0%)、Tool Framing は機微な文脈が入る前ほど有効(S1 で 82%、最終行動直前では 28%)である
構造的論点
本事案は Pillar 03(権限)の agent-infrastructure カテゴリに属する。中心的な失敗 primitive は、エージェントが依拠するツール登録簿が、ツールの同一性をその出自に束縛せず、公開名という改変可能な識別子の上に成り立っていた点にある。同名で先に登録する、あるいは後から差し替えるだけで、エージェントが観測・選択する対象を入れ替えられる。secondary に、メタデータ経由で悪性ツールの役割解釈が誘導される点で ai-decision-integrity、ツールの出自と所有権の検証が欠けている点で identity-auth を併記する。
本事案は Brief No.099(Agentjacking、偽のエラー報告を「解決手順」と信じてエージェントが攻撃者のコマンドを実行した)、Brief No.048(TrapDoor、AI 向け指示ファイルに見えない命令が仕込まれた)、Brief No.024(不可視 Unicode による指示インジェクション)と、エージェントが取り込んだ内容の発行元を確かめずに行動へ移す点で連なる。Brief No.025(MCP の標準設計が RCE の経路になった)・Brief No.027(LibreChat、ユーザー指定の MCP URL から秘密情報が漏れた)・Brief No.094(Cursor DuneSlide)とは、エージェント基盤の設計そのものが攻撃面になる構造を共有する。
本事案に固有なのは、攻撃の対象がプロンプトの内容でもツールの出力でもなく、エージェントが認識する実行環境の状態そのものである点だ。従来の間接プロンプトインジェクション研究は、利用可能なツール群が実行開始前に固定されていることを前提に、「エージェントが情報をどう解釈するか」を攻撃した。MSTI が変えるのは「エージェントがそもそもどのツールを観測・選択できるか」である。研究者はこの差を、既存の MCP 攻撃研究(登録時のメタデータ汚染を扱う MCPTox)や防御研究(利用前後にツールの挙動を検査する MCPShield、実行時のネットワーク通信を観測する ShieldNet)との対比で明示し、後者は「同一ページのスクリプトがタスク実行中に WebMCP のツールを変え得る」という根本問題に直接は届かないとする。共通する primitive は同じである。すなわち、エージェントが呼び出す対象の同一性が、その出自を検証する層と切り離されている。
検出と証明の落差
研究者による攻撃類型の公開、3 モデル・4 シナリオでの定量評価、フィールド単位の寄与分析、注入タイミングの特定、そして設計指針の提示という検出・可視化の系列は、リスクの周知と対策検討に不可欠であり、本 Brief がその役割を否定するものではない。ツール挙動の検査(MCPShield 型)や実行時のネットワーク通信の観測(ShieldNet 型)といった既存の防御研究も、被害の把握と縮小に寄与する。検出は確かに役割を果たす。
一方で、検出は「エージェントがいま呼び出そうとしているツールが、計画時に観測した正規のツールと同一のものか、セッション途中で差し替えられた別物か」を、その呼び出しが行われる時点で独立に立証する材料にはならない。悪性ツールは正規ツールと同じ公開名を持ち、正当なメタデータフィールドを使って提示される。形式的に区別する術は、内容の見た目やモデルの意味的判断に頼る検出側にはない。研究の結果はこれを二重に裏づけている。第一に、プロトコル層を突く攻撃(AbortSignal 乗っ取り・registration race)は、旧世代モデル(GPT-4o・Claude 3.5 Sonnet)から最新モデルまで成功率をほぼ落とさない――モデルの更新では塞げない。第二に、readOnlyHint=true を立てるだけで平均 87% の成功率が出るという事実は、エージェントがメタデータ上の「安全である」という自己申告を、独立の裏づけなしに受け入れていることを示す。監査で「このツール呼び出しは、正規に出自が確認されたツールによるものか」を立証する材料として、「登録簿に載っていた」「読み取り専用と宣言されていた」という事実だけでは、ツールの同一性と出自の独立した証跡にならない。これは検出層の射程外にある、構造的に独立した層の落差である。
本研究が示した最も重要な所見は、この落差が実装可能な形で埋まることの実証である。研究者は 2 種類のベースライン防御――登録時に出自を束縛し、同名かつ異なる出自からの後続登録を拒否する(Tool Hijacking 対策)、および第三者出自からのツール呼び出しを遮り受け取れる引数を制限する(Tool Framing 対策)――を実装し、攻撃成功率を 36〜100% から いずれも 0% に低下させた。しかもタスク完了率はベースラインと同等に保たれた。決定的なのはその内実である。防御を有効にしても、エージェントは依然としてほとんどの試行で悪性ツールを呼び出していた。にもかかわらず、データは攻撃者側に一切届かなかった。研究者はこれを「LLM が誤導されるかどうかと、データが実際に漏れるかどうかは独立の問題である」と述べている。
事前証明(pre-action attestation)は、エージェントがツールを呼び出す経路に、同一性と認可の証明を 1 段挟むことでこの落差を埋める。呼び出しの前に「このツールは計画時に観測したものと同一の不変な識別子を持ち、その出自・所有者・スキーマ・注釈・能力が計画時から一貫しているか」「この呼び出しは、宣言された能力とデータ授受の範囲において認可されているか」を、公開名やメタデータ上の自己申告とは切り離して検証し、証明が伴わなければ呼び出しないしデータの受け渡しを事前に block する。研究の設計指針が挙げる 4 方向――ツール同一性の出自への束縛、ライフサイクル状態の一貫性検証、能力とデータ流の境界宣言、登録・呼び出しの追跡可能な来歴ログ――は、いずれもこの層の具体化である。事前証明は検出に対する代替ではなく 補完 であり、両層の組み合わせでエージェントのツール表面の trust boundary が確立される。
対応経緯と業界動向
- 研究者の設計指針: WebMCP のツール表面は中立・静的なインターフェースではなくセキュリティ境界として扱うべきとし、4 方向の設計指針を提示した。(A) ツール同一性と所有権 = 登録時に不変な内部
tool_idを生成し、出自・document・frame・登録スクリプトの供給元に束縛する。エージェントは公開名ではなくtool_idに基づいて検証する。(B) ライフサイクルと状態の一貫性 = 登録解除・AbortSignal・置換・メタデータ更新は既存の計画を無効化ないし再検証させる。呼び出し前にtool_id・所有者・スキーマ・注釈・能力が計画時と一貫しているか確認する。(C) 能力とデータ流の境界 = ツールに能力・データアクセス範囲・送信先の宣言を求め、第三者ツールには既定で機微データを渡さない。(D) 利用者認可による統制 = 登録・解除・置換・メタデータ変更・呼び出しを来歴ログに記録し、決済・インストール・データ送出といった高リスク行動には UI を介した明示的同意を求める - ベースライン防御の実証: 上記 (A) と (C) に対応する 2 種類の防御を実装し、攻撃成功率を 36〜100% から 0% へ低下させた。タスク完了率はベースラインと同等。研究者は、Tool Hijacking はアクセス制御で扱うべきプロトコル層の問題、Tool Framing はデータ流・制御流の制限を要する意味層の問題であり、両者は防御上明確に非重複の対応関係を持つと整理している
- モデル更新の限界: 旧世代モデルと最新モデルの比較で、プロトコル層を突く攻撃は成功率をほぼ落とさなかった。研究者は、WebMCP のツール登録機構を悪用する攻撃の緩和はモデルのバージョン更新だけでは達成し難いとする。一方、ツールの説明文を主たる攻撃経路とする場合の有効性は、モデルの意味理解能力と相関した
- 研究の限界(研究者による明示): 実験は Chrome のネイティブ WebMCP 実装ではなく polyfill を用い、実ブラウザの完全なセキュリティモデル下ではない。利用者が Tool Framing 攻撃に気づけるかの被験者調査は未実施。防御評価は 4 方向のうち 2 方向のみ。Tool Hijacking のタスク完了率の低さはペイロード設計の帰結であり、正規ツールの仕様を知る現実の攻撃者が正常な成功応答を返せば、完了率は大きく上がり、利用者からはいっそう気づきにくくなり得る
エージェントが呼び出すツールの同一性と出自を、呼び出しの時点で独立検証する層の不在は、特定プロトコルの実装上の不備ではなく、動的に変化するツール表面にエージェントを依拠させる設計全般の運用課題として残っている。
Lemma による分析
本事象で露呈した検出と証明の落差(エージェントが呼び出す対象の同一性が、その出自を検証する層と切り離されている)に対して、Lemma は、エージェントがツールを呼び出し、データを渡す前に、同一性と認可を独立検証可能な暗号証明として要求する設計を提示している。
- ツール同一性の出自バインド: ツールを不変な識別子と出自(origin・document・登録元)に紐付けて検証し、同名で先行登録された/後から差し替えられた別物を、正規に登録されたものから区別する。公開名やメタデータ上の自己申告(
readOnlyHint=true等)ではなく、登録の真正性で判定する - 行動前の認可証明(proof-as-auth): 呼び出しの前に「このツールは計画時と同一で、この呼び出しはこのスコープで認可されている」ことを署名付きで証明する。「ツール一覧に載っていた」ことを呼び出しの終点にしない
- データ流のスコープ化: ツールに渡すデータの範囲を、宣言され認可された必要最小限に絞る。エージェントの判断が誤導された場合でも、機微な文脈が宣言外の送信先へ渡らないようにする
- 登録・呼び出しの来歴ログ: 登録・解除・置換・メタデータ変更・呼び出しを改ざん耐性のある証跡として残し、事後の監査で「どのツールが、どの出自から、いつ現れて呼ばれたか」を独立検証可能にする
- 選択的開示: 「この呼び出しが認可スキーマを満たす」ことだけを最小開示し、機微な文脈は宣言外の宛先に出さない
研究が実証したとおり、これらの層は「モデルが騙されないようにする」ものではない。防御を有効にしてもエージェントは悪性ツールを呼び続けたが、データは攻撃者側に届かなかった。判断の誤導を確率的に減らす検出層と、実害の成立を決定論的に排除する証明層は、別々の仕事をしている。検出(事後の挙動検査・通信監視・手口の可視化)は発覚後の是正に、事前証明(呼び出し前の同一性・認可検証)はエージェント操作の独立検証に、それぞれ相補的に働く。
Sources
- arXiv(研究・一次): Lin-Fa Lee, Yi-Yu Chang, Chia-Mu Yu, Kuo-Hui Yeh, “WebMCP Tool Surface Poisoning: Runtime Manipulation Attacks on LLM Agents”, arXiv:2606.06387v1 [cs.CR](2026-06-04)— https://arxiv.org/abs/2606.06387
- W3C Web Machine Learning(WebMCP 仕様): “WebMCP” — https://webmachinelearning.github.io/webmcp/
- Adversa AI(MCP セキュリティ動向): “Top MCP security resources & CVEs July 2026”(2026-07)— https://adversa.ai/blog/top-mcp-security-resources-july-2026/
Brief 配布について
本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。
(c) 2026 FRAME00, INC. — Built for decisions that matter.