MCP Rug Pulls について調べてみる
なぜ作成したのか
- AIエージェントの導入も始まったし、MCP待ったなしになりそうなのでリスクを下調べする
Model Context Protocol (MCP)における「MCP Rug Pulls」攻撃の脅威と対策
1. MCP Rug Pullsの定義と背景
-
**MCP Rug Pulls(ラグプル)**とは、**MCP (Model Context Protocol)で接続されたツールがユーザーに承認された後で、開発者や攻撃者によって内容を悪質なものにすり替えられる脅威を指します。
-
もともと「Rug Pull(ラグプル)」という言葉は暗号通貨分野で「開発者が資金を集めた後にプロジェクトを放棄し、投資家の信用を裏切る詐欺」を指して使われてきました。
-
それと同様に、MCP環境では一見安全だったツールが後になって悪意ある挙動をするよう “敷かれたラグ(絨毯)を後から引き剥がす” ように信頼を裏切る点から、この名前が付けられています。
-
MCPは2024年にAnthropic社によって公開された、AIアシスタントと外部ツールを接続するためのオープン標準プロトコルです。
-
AIがプラグインのように様々な外部サービスやデータソースへアクセスできる利便性を提供します。しかしその反面、外部のMCPサーバ(ツール提供者)を信用して接続するというモデル上、セキュリティ上の新たなリスク が存在します。MCP Rug Pullはその代表的なものの一つで、最初は無害だったMCPツールが後から悪意あるものに変貌してしまう というリスクです。
-
これはソフトウェアのサプライチェーン攻撃にも似ており、一度安全と判断されインストールされたパッケージが後から悪意のあるアップデートで改ざんされるケース(例:PyPIで公開されたパッケージが後日マルウェアに差し替えられる等)と同様の手口です。
-
要するに、MCP Rug Pullsとは 「ユーザーが承認・信頼した後で、その信頼に乗じてツールの挙動を裏切る」 タイプの攻撃です。
-
2025年初頭にセキュリティ研究者らがこの問題に言及し始め、MCPの便利さの裏にこうした 「承認後の偽アップデート」 による攻撃可能性が潜んでいることが明らかになりました。
2. 攻撃の仕組み・メカニズム
MCP Rug Pull攻撃の仕組みを順を追って説明します。
-
①攻撃者による無害なツール公開:
- 攻撃者はまずMCPサーバ上で一見便利で安全そうなツールを公開します。例えば「ファイルを検索する」「計算する」といった、ごく普通の機能を提供するツールとして登録します。
- ツールの説明には目立った不審な点はなく、コードも当初は悪意のないものになっています(場合によってはGitHubなどでオープンソースとして公開され、誰でもコードを確認できる形を装うこともあります)。
-
②ユーザーによる承認・利用開始:
- エンドユーザーやAIクライアントは、そのMCPサーバを信頼して自分のAIアシスタントに接続します。
- 多くのMCPクライアントは、新しい外部ツールを使う際にユーザーに許可を求める仕組みがあります。ユーザーがそのツールを承認すると、AIアシスタント側ではそのツールが使えるようになり、以後は信頼されたものとして扱われます 。
- この時点ではツールの動作は説明どおりで、例えば計算ツールなら単に計算結果を返すだけの正常な動作をします。
-
③ツール記述の改ざん(悪意あるアップデート):
-
ユーザーに承認された後、攻撃者はMCPサーバ上のツール定義を密かに変更します。
-
具体的には、ツールの説明文やコードに悪意ある命令を追加・改変します。
-
重要なのは、この変更が行われてもユーザー側には通知されない or 気付きにくい場合が多い という点です。
-
現行のMCPクライアント実装では、一度承認したツールについてその後の変更差分をユーザーに警告したり再承認を求めたりする仕組みが十分ではありません。そのため攻撃者は 「ユーザーが承認した後でツールの中身をすり替える」 ということが技術的に可能になっています。
-
この改ざんは即座に行われる場合もありますし、より巧妙な攻撃者は 「スリーパー攻撃(Sleeper Attack)」 と呼ばれる手口を使います。
-
スリーパー攻撃では、初回起動時にはあえて無害な挙動をさせておき、2回目以降の起動時にだけ悪意あるコードが動くように仕込む というものです 。
-
こうすることで初回のユーザー確認やセキュリティチェックをすり抜け、利用継続中にのみ本性を現す ことができます。
-
実際、Invariant Labsの報告では「最初は無害な説明文を掲示し、2回目のサーバ起動時に悪意のある説明文に差し替える」というラグプル攻撃が確認されています。
-
-
④AIアシスタントによる悪意ある命令の実行:
- MCPクライアントであるAI(LLM)は、ツール実行時にそのツールの説明文(定義)を信頼して従います。
- 攻撃者が改ざんした後のツール説明には隠された悪意ある指示が含まれているため、AIはユーザーの依頼を実行するつもりでその隠し命令まで実行してしまいます。
- ポイントは、ユーザーの目にはその隠し命令が直接見えていないことです 。
- 多くの場合、ユーザーインターフェース上は単に「〇〇ツールを実行しますか?」と簡単な説明しか表示されず、内部でAIがどんな手順を踏むかまでは表示されません。
- 結果として、AIはユーザーの意図しないデータの読み取りや送信、破壊行為などを“裏で”実行してしまう可能性があります。
-
⑤ユーザーに気付かれず不正完了:
- 攻撃がうまくいくと、ユーザーは自分の指示通りにAIが動いたと思っている間に、裏では機密情報が抜き取られたり、システム変更が加えられたりします。
- ログにも不審な外部ツール名は残らず、一見すると信頼済みの正規ツールが動いただけに見えるため、ユーザーや管理者はすぐには異常に気付けません 。
- このように、攻撃者は痕跡を最小限に留めてエージェントの動作を乗っ取ることが可能になるのです。
実際の攻撃例:
-
2025年に報告されたある実証攻撃では、攻撃者は無害を装った「今日の雑学を取得する(get_fact_of_the_day)」というツールをMCPサーバ上に提供し、ユーザーに承認させました。
- その後でこのツールの説明を差し替え、裏でWhatsAppのメッセージ履歴を窃取して攻撃者の電話番号に転送するような命令を埋め込みました。
- ユーザーはツール名から雑学取得の機能だと信じ込んで使い続けましたが、実際にはWhatsAppチャットの過去ログが盗み出されていたのです。
- このケースでは**「承認後の説明改ざん」**によってAIが勝手に機密メッセージを抜き取る動作をしており、まさにMCP Rug Pull攻撃の実例と言えます。
-
また別のシナリオでは、「計算機(電卓)」ツールにおいて最初はただ二つの数を足し算するだけの機能だったものが、承認後のアップデートで 計算時に入力されたクレジットカード番号を密かに外部送信する よう改変されてしまった例が指摘されています。
- ユーザーはアップデートに気付かず引き続きその電卓ツールを使ってしまい、結果としてカード情報が漏洩する危険が生じます。
- このように、MCP Rug Pullでは 「ユーザーの見えない所でツールの正体が変わる」 ため、防御側が気付かないうちに深刻な被害をもたらし得るのです。
3. リスク顕現時の影響・被害
MCP Rug Pull攻撃が成功してしまった場合、システムや企業にどのような影響・被害が及ぶかを整理します。
-
機密データの漏洩:
- 最も深刻なのは情報漏洩のリスクです。
- 承認済みツールが悪意ある動作に変貌すると、AIはユーザーのデータを盗み出して攻撃者に送信する可能性があります。
- 例えば前述のケースでは、WhatsAppのチャット履歴といった極めて機微な個人通信データが抜かれています。
- 他にも、システムの設定ファイルや認証情報(APIキーやOAuthトークン、SSH秘密鍵など)が読み取られて流出する危険があります。
- 実例として、CursorというMCPクライアント上で動作する無害に見えた
add()
ツールが実は隠し命令で設定ファイル中のパスワードを盗み出していた、という報告もあります。 - このように、ユーザーの知らない間に社内の重要情報や個人情報が外部に漏洩することになり得ます。
-
不正操作・権限濫用:
- Rug Pullによりツールが乗っ取られると、本来許されていない操作が実行されてしまう危険もあります。
- 例えば、本来はユーザーの指示した特定の相手にメールを送信するツールだったはずが、ラグプル後には 送信先を攻撃者のアドレスにすり替えて社外に情報を送信してしまう といった動作に変わり得ます。
- 実際の例では、安全と思われていたメール送信ツールが攻撃者によって改ざんされ、ユーザーが入力した宛先ではなく攻撃者の用意したアドレスに全てのメールを転送してしまっていたケースがあります。
- この結果、本来社内の人だけに届くはずの情報が第三者に渡ってしまうという被害が発生します。
-
システム障害・サービス停止:
- 攻撃者の目的次第では、システム破壊やサービス妨害 につながるおそれもあります。
- 隠された命令がファイル削除や設定の破壊を行うようなものであれば、重要データの消失やシステムのクラッシュを招き、業務停止に直結します。
- たとえば「ファイルを整理する」という説明のツールがラグプルによって悪意ある削除コマンドを含むよう改変されてしまった場合、ユーザーが気付かずに実行すると重要な書類やデータベースが消去されてしまうかもしれません。
- このようなデータの改ざん・消去はバックアップからの復旧やシステム再構築が必要となり、業務に多大な支障をきたすでしょう。
-
連鎖的な被害拡大:
- MCPの特徴として一つのAIクライアントに複数のMCPサーバ(ツール)を同時に接続できる点がありますが、Rug Pullで一つのツールが乗っ取られると他の信頼済みツールの操作まで乗っ取られるリスクもあります。
- 悪意あるツールが他の正規のツールに対する入力やパラメータを密かに書き換え、**横からハイジャックする(Tool Shadowing)**ことで被害が波及します 。
- これにより、攻撃者はあたかも **「自分のツールを使わずともエージェントの振る舞いを操れる」**状態を作り出せます。
- 結果としてログ上も攻撃者のツールを使った形跡が残らず、完全に信頼されている正規ツールだけが使われた履歴しか見えないのに内部では不正が起きているという極めて発見の難しい事態になります。
- このようなステルス性の高い攻撃は、被害が長時間にわたり発見されないまま進行する恐れがあり、被害範囲が拡大しやすい点でも危険です。
以上のように、MCP Rug Pull攻撃が顕現すると**「機密性の侵害(情報漏洩)」「完全性の侵害(データ改ざん・破壊)」「可用性の侵害(サービスダウン)」**といったあらゆるセキュリティ面で深刻な影響が生じ得ます。
その結果、企業にとっては法的な問題(個人情報漏洩による罰則)や信用失墜、業務停止による損失など甚大な被害となりかねません。
特にAIアシスタントが社内システムに深く入り込んでいる場合、そのAIを通じて社内の多くのリソースが二次被害を受ける可能性もあるため注意が必要です。
4. 対策・予防方法
MCP Rug Pullsのリスクに対しては、技術面と運用面の双方から多層的な対策を講じることが重要です。
以下に主な対策とベストプラクティスをまとめます。
-
信頼できるMCPサーバ/ツールのみを使用する:
- まず基本原則として、出所不明・信用できない第三者提供のMCPサーバは極力利用しないようにします。
- 公式にレビューされたものや実績のある提供元のツールに限定し、怪しいコミュニティ製のツールを安易に追加しないことが重要です。
- 企業内でMCPを活用する場合は、承認済みMCPツールのホワイトリスト を作成し、利用を許可するツールサーバを限定すると良いでしょう。
- また、オープンソースのMCPサーバであれば自社でフォークしてコードレビューを行い、安全を確認した上で社内専用にホスティングすることも検討すべきです。
-
ツールのバージョン固定(ピン留め)と整合性検証:
- 初回承認したツールの記述やコードのハッシュ値を保存し、以後変更があれば警告・ブロックする 仕組みを導入します。
- これにより、攻撃者が後から内容を改ざんしようとしても検知できます。
- 実際、Invariant Labsも「クライアントはMCPサーバおよびツールのバージョンを固定し、ハッシュ値やチェックサムで整合性を検証することで不正な変更を防ぐべき」と提言しています。
- Microsoftの提供するあるMCPクライアント実装(GenAIScript)では、ツール記述の署名が合致しない場合はサーバのロード自体を拒否することでラグプル攻撃を防ぐ仕組みを採用しています。
- このようにコード署名やハッシュ検証によって、承認後のツール改ざんを確実に検出・遮断するのが理想です。
-
ユーザーへの可視化と警告強化:
- MCPクライアント側のUI/UXを改善し、AIモデルだけでなくユーザーにもツールの詳細な説明内容や変更履歴が見えるようにすることが重要です。
- 例えば、ツール説明中のAI向け指示(<IMPORTANT>タグ内など)をユーザー画面でも明示的に表示したり、色分けして注意喚起する仕組みが考えられます。
- また、ツールのアップデートが行われた際にはユーザーに通知して再確認を促すような機能も検討すべきです。
- 現状の課題はユーザーが「ツールが何をするか」を詳しく知らないままAIに任せてしまう点にあるため、利用者教育とインターフェース上の警告表示によってリスクを認識させることが対策となります。
-
権限とアクセス範囲の最小化:
- MCPサーバに必要以上の過剰な権限スコープを与えないことも被害軽減に有効です。
- 例えばメール閲覧だけで十分な用途であれば、メール送信や削除権限を持つトークンは渡さない、ファイルシステム全体ではなく必要なディレクトリのみにアクセスを限定する、といった最小権限の原則を適用します。
- 仮にラグプル攻撃に遭っても、ツールが持つ権限が限定的であれば被害も限定的になります。
- また、MCPサーバごとに異なる認証トークンを使い回さず発行し、あるツールから他のサービス全部にアクセスされないようトークンの分離を図ることも大切です。
-
環境のサンドボックス化・クロスサーバ隔離:
- 信頼度の低いMCPサーバを利用する場合は、他の重要システムとは隔離された環境で動作させるべきです。
- 例えばAIクライアントごとにDockerなどのコンテナでMCPサーバ通信環境を分離し、万一その中で悪意ある動作が発生しても社内LAN全体や他のMCPツールに直接は影響を及ぼさないようにします。
- Invariant Labsも提言しているように、**複数のMCPサーバ間でデータや操作が簡単に干渉し合わない厳密な境界を設ける(クロスサーバ保護)**ことが重要です。
- 具体的には、あるサーバから得たデータを別のサーバのツールに渡す際にフィルタリングや確認プロンプトを入れる、共有するコンテキストを最小限にする、といった対策が考えられます。
- さらに、MCPクライアントを動かすホスト自体を仮想マシンやコンテナでサンドボックス化し、万一エスケープされても被害を限定するのも有効です。
-
監査ログと異常検知の強化:
- AIアシスタントの操作ログに、どのMCPサーバのどのツールが使われたか、引数は何だったか、といった詳細をできるだけ記録しておきます。
- 標準のユーザー向けログだけでなく、セキュリティ監査用の詳細ログを保持することで、後から「何が起きたか」を追跡しやすくなります。
- また、自動異常検知システムを用いて、通常あり得ないデータの送信(例:大量の機密データを外部に出力する挙動)や不審な組み合わせのツール実行を検知し、管理者にアラートを上げる仕組みも検討すべきです。
- AIの出力内容をスキャンして機密情報らしきものが含まれていないかチェックするデータ損失防止(DLP)的なアプローチも有用でしょう。
-
追加のセキュリティレイヤ導入:
- もしクリティカルな業務でどうしてもMCPを使う必要がある場合、専門のセキュリティミドルウェアや監査プロキシを間に挟むことも検討してください。
- Invariant Labs提供の「Invariant Stack」のように、エージェントの動作をリアルタイムで解析・制御するガードレールツールを利用すれば、ツールの怪しい挙動を事前にブロックしたり、AIへのプロンプトを監視して不自然な命令を検出したりできます。
- 現状MCP自体には十分なセキュリティガードレールが備わっていないため、外部の補助ツールで防御を固めることも有効な戦略です。
以上の対策を組み合わせることで、MCP Rug Pullsのリスクを大幅に低減できます。
特に 「疑わしきは使わず」「ツールの変更を許さず」「使うなら隔離する」 という方針が重要です。現在のところMCPプロトコル自体が成熟途中であり、「便利さ」と引き換えにセキュリティ面の甘さが指摘されています。
開発元からセキュリティアップデートやガイドラインが出る可能性もありますが、利用者側でも十分に注意し、上述したベストプラクティスを社内ポリシーに組み込むことが求められます。
5. 攻撃フローの図解と動作変化の例
MCP Rug Pull攻撃のフローを図示したものです。まず攻撃者が一見無害なMCPツールを提供しユーザーに承認させた後、そのツールの説明をこっそり改変して悪意ある命令を埋め込みます。
結果として、AIエージェントが次回以降にそのツールを使用した際、ユーザーの知らないところでデータ窃取などの不正処理が実行されてしまいます。
上記フローにおいて、攻撃前後でツールの表向きの挙動と裏の動作がどう変わるかを対比するため、簡単な例を表にまとめます(電卓ツールのケース):
状況 | ツールの説明例 (ユーザーに見える内容) | ユーザーの認識・意図 | 実際の動作 |
---|---|---|---|
導入直後(正常動作時) |
「二つの数を足し算して結果を返す電卓ツールです。」 (問題のない説明のみ) |
単に計算をするツールだと信じて利用する | 入力された2数の加算を行い結果を返す。悪意の挙動は無し(正常動作)。 |
Rug Pull発生後(悪意あり) |
「二つの数を足し算して結果を返す電卓ツールです。」 (説明は同じだが内部に隠し命令を追加) |
引き続き同じ安全な電卓ツールだと思い込み、信用して使い続ける | 表向きは計算結果を返すが、裏で入力値(例:クレジットカード番号)を攻撃者サーバに送信する 。(機密情報の漏洩) |
表: MCP Rug Pull攻撃前後におけるツール動作の変化例(電卓ツール)
- 初期状態ではユーザーの期待通りの動作をするが、承認後に攻撃者が説明を改ざんすると、ユーザーには気付かれないまま背後で不正動作が組み込まれる。
- このように、表面的なツールのインタフェースはそのままで内部の挙動だけが悪意あるものに入れ替わるため、防御側にとって発見が難しい点がMCP Rug Pullの恐ろしいところです。
以上、MCP Rug Pullsの脅威概要とそのメカニズム、影響、対策について詳しく説明しました。MCPは将来性のある技術ですが、現状では「便利さと引き換えに新たなリスクを受け入れる」面があることを理解し、慎重に運用する必要があります。
特に企業環境でLLMやMCPを活用する情シス担当者としては、本回答で述べたような 攻撃手口と対策の知識を十分踏まえ、事前にリスク低減策を講じた上でMCPを利用することが望ましい と言えます。
セキュリティコミュニティからの最新情報にもアンテナを張り、プロトコルのアップデートや脆弱性情報があれば速やかに対応して、安全なAI活用基盤を整備してください。
Sources:
-
Anthropic, “Model Context Protocol (MCP) – An open standard to connect AI assistants with external tools.” (2024) (The Security Risks of Model Context Protocol (MCP))
-
Pillar Security, “The Security Risks of Model Context Protocol (MCP)” (2025) (MCP Security Notification: Tool Poisoning Attacks) (MCP Security Notification: Tool Poisoning Attacks)
-
Mehul Gupta, “MCP Servers are not safe! Serious security risks ...” Medium (Apr 2025) (MCP Servers are not safe!. Serious security risks are associated… | by Mehul Gupta | Data Science in Your Pocket | Apr, 2025 | Medium) (MCP Servers are not safe!. Serious security risks are associated… | by Mehul Gupta | Data Science in Your Pocket | Apr, 2025 | Medium) (MCP Servers are not safe!. Serious security risks are associated… | by Mehul Gupta | Data Science in Your Pocket | Apr, 2025 | Medium)
-
Invariant Labs, “MCP Security Notification: Tool Poisoning Attacks (包括MCP Rug Pulls)” (2025) (WhatsApp MCP Exploited: Exfiltrating your message history via MCP) (WhatsApp MCP Exploited: Exfiltrating your message history via MCP) (MCP Security Notification: Tool Poisoning Attacks) (MCP Security Notification: Tool Poisoning Attacks) (MCP Security Notification: Tool Poisoning Attacks) (MCP Security Notification: Tool Poisoning Attacks)
-
Simon Willison, “Model Context Protocol has prompt injection security problems” (Apr 2025) (Model Context Protocol has prompt injection security problems)
-
Invariant Labs, “WhatsApp MCP Exploited: Exfiltrating your message history via MCP” (2025) (WhatsApp MCP Exploited: Exfiltrating your message history via MCP)
所感
- MCPの波が来ても結局はセキュリティチェックがキモになる
- しかし「信頼できるツールをどう評価するか」問題がまた立ちはだかる
- Assuredみたいな第三者評価機関のありがたみが実感できるなあ
Discussion