MCP tool poisoning 論文は「正規 server だから安全」という雑な前提を壊す
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- MCP の危険は server 側認証だけでは足りず、tool description や parameter metadata 自体が攻撃面になるという論文である。
- abstract で確認できる範囲では、著者らは STRIDE と DREAD を使って 5 つの主要 component を threat modeling し、tool poisoning を最も重大な client-side vulnerability だと位置づけている。
- そのうえで 7 つの主要 MCP client が tool poisoning にどう耐えるかを比較し、多くで static validation と parameter visibility が不十分だと報告している。
- 実務上の読後行動は単純で、`trusted server` なら prompt や metadata も trusted だと扱う設計をやめることだ。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この論文は、MCP security の重心を server-side control から client-side validation へ少し戻しています。abstract によれば、著者らは 5 component を STRIDE と DREAD で threat modeling し、その中で tool poisoning を最も impactful な client-side vulnerability と見ています。つまり『接続先を認証した』で終わらず、『その先から来る metadata をどう検査し、どう見せるか』が主題になります。 さらに 7 major MCP clients の比較で static validation と parameter visibility が弱いと述べています。tool metadata は model と user の判断を誘導する未信頼入力だ、という前提へ戻させる paper です。
なぜ重要か
日本の実装では `trusted server` という言葉が強すぎて、server 由来の prompt や tool description まで trusted 扱いしがちです。しかし実際には、説明文や parameter schema は model と user の判断を誘導する入力です。この論文は、その雑な信頼連鎖を切る材料になります。 approval 設計にも効きます。確認画面が『この tool を実行しますか』だけなら弱く、どの引数が外部送信や破壊的変更につながるかを user に見せなければ意味が薄いと分かるからです。
技術的ポイント
- abstract では 5 component を対象に STRIDE と DREAD で threat modeling したとある。host/client、LLM、MCP server、external data store、authorization server が対象だ。
- tool poisoning は malicious instruction が tool metadata に埋め込まれる攻撃として説明されている。prompt 本文だけでなく metadata も未信頼入力になる。
- 著者らは 7 major MCP clients を比較し、多くで insufficient static validation と parameter visibility を確認したと述べている。
- proposed defense は multi-layered で、static metadata analysis、model decision path tracking、behavioral anomaly detection、user transparency mechanism を含むと abstract にある。
- 論文の焦点は client-side vulnerability にある。server 側認証や OAuth を整えても、host 側 UI と検査が弱ければ穴が残る。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| tool poisoning | ツール汚染 / ツール毒入れ | tool metadata に悪意ある指示を混ぜる攻撃。server 認証だけでは防げない。 |
| static validation | 静的検証 | 実行前に定義や metadata を機械的に検査すること。approval UI の前段で効く。 |
| parameter visibility | 引数の可視性 | user が危険な引数を見抜けるだけの表示。tool 名だけの承認画面では弱い。 |
| transparency mechanism | ||
| STRIDE | STRIDE 脅威分類 | 脅威を 6 類型で整理する古典的手法。component ごとの穴を体系立てて見る時に使う。 |
| DREAD | DREAD 評価法 | 被害や再現性などで危険度をみる枠組み。脅威を優先順位づける時の補助線になる。 |
試すなら
- 自分の MCP client で、tool name、description、parameter schema が approval 前にどこまで見えるか確認する。
- server 認証済みでも metadata を未信頼入力として扱い、危険語や外部送信指示を静的検査にかける。
- approval UI で『この tool を実行する』だけでなく、どの引数がどこへ送られるかを見せる。
- 本文を読むなら、7 client 比較の対象と評価条件を確認し、自分の client 実装へ安易に一般化しない。
注意点
- この note は abstract と arXiv metadata を中心にしており、各 client の個別挙動までは本文確認なしに断定していない。
- tool poisoning は重要だが、MCP security の全てではない。auth、rate limit、runtime policy、audit も別問題として残る。
- `major client` の範囲や比較条件は今後更新されうるため、論文 1 本で恒久結論にしないほうが安全だ。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。