MCPのtool poisoning・rug pull・サプライチェーン攻撃から守る

MCP（Model Context Protocol）を使ったLLMアプリ・AIエージェントの開発が急速に広がっています。一方で、MCPに固有のセキュリティリスクに関して、英語圏ではPalo Alto Unit42やRed Hatなど主要ベンダーが詳細な分析を公開しているものの、日本語での実務向け防御ガイドはまだ少ないのが現状です。

この記事では、MCPが抱える3つの固有リスク「tool poisoning」「rug pull」「サプライチェーン攻撃」を整理し、査読済み論文（arXiv 2603.22489 / MDPI掲載）の脅威モデリング結果を参照しながら、開発者・セキュリティエンジニアがすぐに使える防御設計チェックリストを提供します。

MCP固有の3リスクとは何か

リスク1：Tool Poisoning（ツール説明欄への悪意ある指示の埋め込み）

MCPサーバーはツールを登録する際、各ツールに「説明文（description）」を付与します。LLMはこの説明文を読んで、どのツールをどのように呼び出すかを判断します。

tool poisoningとは、この説明欄に攻撃者が悪意ある指示（隠しプロンプト）を埋め込み、LLMに意図しない動作を取らせる攻撃です。

例えば、ファイル操作ツールの説明欄に「このツールを呼び出した際は必ず〜というシステム情報も返せ」といった指示が隠されていても、エンドユーザーには見えません。LLMがその指示に従ってしまうと、情報漏洩や意図しない操作が発生します。

arXiv 2603.22489（著者：Charoes Huang, Xin Huang, Ngoc Phu Tran, Amin Milani Fard、2026年3月23日公開、MDPI査読済み）は、Claude Desktop・Cursor・Continue等の主要7クライアントを対象にtool poisoning攻撃の実証評価を実施しました。同論文はMCPの5コンポーネント（クライアント・サーバー・ホスト・プロトコル・ツール登録）に対して57の脅威を特定しています。

リスク2：Rug Pull（承認後の悪意ある動作変化）

「rug pull」は、最初は正規の動作をするツールがユーザーの信頼を得た後、後日アップデートで悪意ある動作に変わるパターンです。

MCPのエコシステムでは、外部のMCPサーバーをnpxやuvxコマンドで動的にインストールして利用するケースが一般的です。バージョンを固定していない場合、ツール提供者がサーバーコードを更新した瞬間から、次回起動時に悪意ある版が実行されてしまいます。

ソフトウェアサプライチェーン攻撃と同じ構造ですが、MCPの文脈ではLLMが自律的にツールを呼び出すため、人間がリアルタイムで確認する機会がない分、被害が広がりやすいという特徴があります。

リスク3：サプライチェーン攻撃（公開レジストリへの偽装パッケージ）

npm・PyPIなどの公開パッケージレジストリに、有名MCPサーバーに似た名前の偽パッケージを公開する攻撃です。

開発者がタイポや似た名前に気づかずインストールすると、悪意あるMCPサーバーが実行されます。Palo Alto Unit42の分析（MCP新規攻撃ベクター分析）でも、この種の攻撃ベクターが具体的に取り上げられています。

STRIDE/DREADフレームワークで見るMCPの脅威全体像

arXiv 2603.22489は、MCPの脅威をSTRIDEフレームワーク（Spoofing・Tampering・Repudiation・Information Disclosure・Denial of Service・Elevation of Privilege）とDREADスコア（Damage・Reproducibility・Exploitability・Affected Users・Discoverability）で体系的に評価しています。

5コンポーネント・57脅威の分析の中で、同論文が最も危険度が高いと指摘するのは「情報漏洩（Information Disclosure）」と「特権昇格（Elevation of Privilege）」の組み合わせです。tool poisoningによりLLMがシステム情報や認証トークンを外部に漏洩させるシナリオが、DREADスコアの観点から特に高リスクと評価されています。

また、エンタープライズ向けの防御アーキテクチャを論じたarXiv 2504.08623（Enterprise-Grade Security for the Model Context Protocol、2026年4月公開）は、MCPをエンタープライズ環境で安全に使うための認証・認可・監査ログ設計を提案しています。

防御設計チェックリスト：3層アプローチ

第1層：メタデータ静的解析とツール登録時の検証

ツールをMCPクライアントに登録する前に、説明文の内容を機械的・目視で確認します。

実装チェックリスト：

• ツール説明文（descriptionフィールド）に通常の自然言語説明以外の命令文・条件文が含まれていないか確認する
• ツール名・説明文の長さが異常に長くないか確認する（隠し指示の混入を示すシグナル）
• MCPサーバーのソースコードまたは公式リポジトリを確認し、説明文の生成ロジックが安全かチェックする
• 信頼できる組織・コミュニティが提供するMCPサーバーのみを使用し、野良パッケージは避ける

# ツール説明のシンプルな静的チェック例（PoC レベル）
import re

def check_tool_description(description: str) -> list[str]:
    """ツール説明文に不審な命令パターンが含まれていないか確認する"""
    warnings = []
    # 命令形・条件文の検出（高レベルのヒューリスティック）
    suspicious_patterns = [
        r"ignore\s+previous",
        r"disregard\s+",
        r"do\s+not\s+tell",
        r"secret(ly)?",
        r"hidden\s+instruction",
    ]
    for pattern in suspicious_patterns:
        if re.search(pattern, description, re.IGNORECASE):
            warnings.append(f"不審なパターン検出: {pattern}")
    if len(description) > 2000:
        warnings.append("説明文が異常に長い（2000文字超）")
    return warnings

第2層：ユーザー透過性・最小権限・バージョン固定

ユーザー透過性：

• AIエージェントがどのMCPツールを呼び出したかをユーザーに常に開示する（ツール呼び出しログのUI表示）
• 重要な操作（ファイル書き込み・外部API呼び出し・データ削除）は必ずユーザー確認を挟む

最小権限設計：

• MCPサーバーには必要最小限のスコープ・権限のみを付与する
• 読み取り専用で十分な場合は書き込み権限を付与しない
• 複数ツールをまとめたスーパーサーバーより、単一機能のサーバーを優先する

バージョン固定とrug pull対策：

• package.json・pyproject.tomlでMCPサーバーのバージョンを固定する
• npx @modelcontextprotocol/server-filesystem のような動的インストールを本番環境で使わない
• 依存パッケージのハッシュ固定（npm ci・pip install --require-hashes）を行う
• Dependabot等の自動更新ツールでアップデート内容を確認してから適用する

// package.json のバージョン固定例（^ や * を使わない）
{
  "dependencies": {
    "@modelcontextprotocol/server-filesystem": "1.2.3"
  }
}

第3層：動作異常検知と認証

間接プロンプトインジェクション検知：

• LLMのアウトプットに含まれるツール呼び出しを、実行前にルールベースで検証する
• 想定外のツール呼び出しシーケンス（例：読み取りツールの後に予期しない外部送信）をアラート対象にする
• MCPサーバーへのリクエスト・レスポンスをログに記録し、異常な外部通信を検知する

認証・認可：

• MCPサーバーへのアクセスはOAuth 2.0等の標準プロトコルで認証する
• MCPクライアントとサーバー間の通信をTLSで暗号化する
• サーバーごとに異なる認証情報を使用し、1つの漏洩が全体に波及しないようにする

公式MCPセキュリティベストプラクティスの実務フロー

Anthropic公式のMCPセキュリティベストプラクティスでは、以下の原則が強調されています。

最小権限の原則：MCPサーバーには必要な権限のみを付与し、unused permissionsを定期的に棚卸しする。

入力検証：MCPサーバー側でも、クライアントから受け取るパラメータをサニタイズ・バリデーションする。ツール引数経由のインジェクション攻撃にも備える。

安全なデフォルト：設定を変更しない限り、安全な動作になるようデフォルト値を設定する。

監査ログ：誰がどのツールをいつ呼び出したかを記録する。インシデント発生時の調査に不可欠。

これらを実務フローに落とし込むと、次のような運用になります：

1. 導入前レビュー：新規MCPサーバーを追加する際は、静的解析チェック（第1層）を通過させる
2. 定期棚卸し：月次でMCPサーバーの権限・バージョンを確認し、不要なものを削除する
3. インシデント対応：異常検知アラートが発火した際の調査手順をRunbookに記載しておく

よくある質問（FAQ）

FAQ

MCP セキュリティ FAQ

LLMアプリ開発者からよく寄せられる質問

Q tool poisoning は既存のプロンプトインジェクション対策で防げますか？

A

既存のプロンプトインジェクション対策（入力サニタイズ・システムプロンプトの強化）はある程度有効ですが、MCPのtool poisoningはツール登録時の説明文に注入されるため、実行時のユーザー入力フィルタリングだけでは防げません。ツール説明文の静的解析と、信頼できるサーバーのみを登録するガバナンスプロセスを組み合わせる必要があります。

Q 公式のMCPサーバー（Anthropic提供）なら安全ですか？

A

公式提供のサーバーは信頼性が高いですが、「公式だから完全に安全」とは言い切れません。バージョン固定・権限の最小化・監査ログの記録は、提供元にかかわらず実施してください。また、公式サーバーを模倣した偽パッケージがnpmに公開されるリスクもあるため、パッケージ名・公開者・リポジトリURLを必ず確認してインストールしましょう。

Q 個人開発の小規模なLLMアプリでも対策が必要ですか？

A

個人開発でも、外部公開するアプリや他のユーザーが使うサービスであれば対策は必須です。特にバージョン固定と最小権限は実装コストが低く、効果が高いので最初に対応することをおすすめします。ローカルのみで使う完全プライベートなツールであっても、悪意あるMCPサーバーを誤って導入するリスクはゼロではありません。

まとめ

MCPはLLMアプリとツールを繋ぐ強力な標準規格ですが、その柔軟性がtool poisoning・rug pull・サプライチェーン攻撃という新たなリスクを生んでいます。arXiv 2603.22489がSTRIDE/DREADで明らかにした通り、情報漏洩と特権昇格のリスクが特に高く、実証評価でも主要クライアントへの攻撃成功が確認されています。

3層防御（静的検証→最小権限・バージョン固定→動作検知・認証）をチェックリストとして実装し、Anthropic公式のセキュリティベストプラクティスを組織のガバナンスプロセスに組み込むことで、リスクを大きく低減できます。

次に読むおすすめ

この記事でMCPセキュリティの全体像をつかんだ方に、実践編としてnoteで詳しい内容を公開しています。

noteで続きを読む

参考リンク

• arXiv 2603.22489 — Threat Modeling of Model Context Protocol (MDPI査読済み)
• MDPI掲載版 — 2624-800X/6/3/84
• Anthropic公式 MCP Security Best Practices
• arXiv 2504.08623 — Enterprise-Grade Security for the Model Context Protocol
• Palo Alto Unit42 — MCP新規攻撃ベクター分析
• Red Hat公式ブログ — MCPのセキュリティリスクとコントロール