トップ10 MCP脆弱性：AI統合の隠れたリスク

モデルコンテキストプロトコル（MCP）は、AIアシスタントがさまざまなデータソース、ツール、サービスと接続・通信し、より良い行動、推奨、意思決定を行うための手段として急速に人気を集めています。このプロトコルは通信を標準化し、エージェント型AIの強固な基盤を築きます。

APIと同様に、MCPサーバーは通常データストアやサービスの前面に配置され、エージェントが必要な情報を必要なときに簡単に取得できるようにし、カスタマイズされた統合の手間を省きます。企業は自社のデータを自社のAIプロセスや外部ユーザーに公開するためにMCPサーバーを利用できますし、PayPal、Zapier、Shopifyなどの人気サービスに接続するための既製のMCPサーバーも利用できます。

しかし、AI戦略の一環としてMCPサーバーの利用を計画している企業は、それに伴うリスクを認識しておく必要があります。注意すべきリスクや潜在的な脆弱性は数多く存在します。ここでは、MCPを利用する際に組織が直面しうる最も一般的な10の問題を紹介します。

テナント間データ漏洩

クロスサイトスクリプティング攻撃と同様に、テナント間データ漏洩は、あるユーザーグループが別のユーザーグループ（社内チーム、ビジネスパートナー、顧客など）のデータにアクセスできてしまう問題です。

この脆弱性が、技術に精通した企業のMCPサーバー実装で既に発見されているという事実は、MCPサーバーを構築するすべての企業にとって警告となります。

この問題を発見したUpGuardの研究者によれば、解決策はMCPサーバーが厳格なテナント分離と最小権限アクセスを強制することです。

AIを利用した持続型攻撃

攻撃者が従業員、ビジネスパートナー、顧客になりすまして人間のサポート担当者にリクエストを送ります。しかし、そのリクエストにはAIだけが読み取れる隠れたプロンプトインジェクションが含まれています。人間の従業員がそのリクエストをAIアシスタントに渡すと、MCPサーバーへのリンクによって、AIは機密データやビジネスプロセスに接続するツールにアクセスできるようになります。このアクセスが悪意ある目的で利用される可能性があります。

これは理論上の脅威ではなく、実際に起こりうる現実的な脅威であり、技術に精通した企業でも影響を受ける可能性があります。

これを防ぐ一つの方法は、企業がAIのアクションに最小権限を強制し、アナリストがリアルタイムで疑わしい内容をプロンプトチェックし、MCPの活動ログを維持することです。

初めてMCPサーバーをセットアップするのは難しいことがあります。幸いなことに、すぐに使えるものが多数存在します。MCPサーバーのディレクトリには現在15,000以上が掲載されています。

しかし、Google検索で最初に見つかったMCPサーバーをダウンロードしたとしても、そのサーバーが本来の機能を果たす保証はありません。

4月には、Invariant Labsが、悪意あるMCPサーバーがMCPサーバーの説明欄に悪意のある指示を追加することで、暗号化やセキュリティ対策を回避し、他のシステムから情報を抽出できることを実証しました。

しかし、悪意のある指示が含まれる可能性があるのは説明欄だけではありません。攻撃対象領域はMCPサーバーが生成するすべての情報、例えば関数名、パラメータ、パラメータのデフォルト値、必須フィールドや型などにも及びます。MCPサーバーはエラーメッセージやフォローアッププロンプトなど他のメッセージも生成しますが、これらにもAIエージェントが従う悪意のある指示が含まれる可能性があります。

ダウンロードしたMCPサーバーが悪意あるものかどうかをどう見分けるか？まず、出所を確認しましょう。それは信頼できる組織から提供されていますか？次に、要求される権限を確認しましょう。もし猫の面白画像を提供するだけのサーバーであれば、ファイルシステムへのアクセス権限は不要なはずです。

最後に、可能であればソースコードを確認しましょう。これは難しいかもしれませんが、既にこれに取り組んでいるベンダーも存在します。例えばBackSlash Securityは、公開されている7,000のMCPサーバーを分析し、セキュリティリスクや疑わしい、あるいは明らかに悪意ある挙動の事例を発見しています。

そして、MCPサーバーをインストール時に一度だけ精査するだけでは不十分です。ソフトウェアサプライチェーンには、パッケージがダウンロードされ、利用され、信頼された後に、悪意のあるコードでアップデートされるという有名な攻撃ベクトルがあります。

Invariant Labsによれば、これは「ラグプル」攻撃と呼ばれ、MCPサーバーでも発生し得ます。MCPサーバーが悪意のある機能でアップデートされ、悪事を働いた後、再度アップデートされて誰にも気づかれません。「このような侵害は被害者に気づかれず、攻撃者だけがその事実を知っている可能性があります」とCyberArkの研究者Nil Ashkenaziは述べています。

信頼されたプラットフォーム経由の有害なエージェントフロー

AIエージェントは、MCPサーバーを信頼するシステムを通じて、パブリックプラットフォームにプロンプトインジェクションを追加することで、データ漏洩や悪意のあるコード実行を強要される可能性があります。

研究者たちは、Github MCPサーバーでこれがどのように機能するかを実演しました。この攻撃では、攻撃者がパブリックリポジトリに新しいイシューを作成し、そこにプロンプトインジェクションを含めます。企業はバグ報告を集めるためにパブリックリポジトリを持っていることがあり、AIエージェントはGitHubのMCPサーバーを使ってパブリックリポジトリのオープンイシューを確認するなどの定例作業を行います。するとAIエージェントはプロンプトインジェクションを読み取ります。例えば、そのAIが同じGitHub MCPサーバー経由でアクセスできるプライベートリポジトリの機密データを収集するよう指示される場合です。GitHubサーバー自体は直接侵害されていませんが、攻撃の媒介として利用されます。

Invariantの研究者はAnthropicのClaude Desktopを使ってこの攻撃ベクトルを実証しましたが、デフォルトでは個々のツール呼び出しごとにユーザーの確認が必要です。「しかし、多くのユーザーはエージェント利用時に『常に許可』の確認ポリシーを選択しています」と研究者は記しています。

トークン窃取とアカウント乗っ取り

Pillar Securityのレポートによれば、攻撃者がMCPサーバーに保存されたOAuthトークンを取得できた場合、その盗まれたトークンを使って独自のMCPサーバーインスタンスを作成できてしまいます。OAuthトークンは、MCPサーバーの設定ファイルやコードファイルに暗号化されずに保存されている場合、バックドアやソーシャルエンジニアリングなどの手段で攻撃者に奪われる可能性があります。

例えばGmailの場合、攻撃者は被害者のGmail履歴全体にアクセスしたり、被害者になりすました新しいメールを送信したり、メールを削除したり、機密情報を検索したり、今後の通信を監視するための転送ルールを設定したりできます。

「従来のアカウント侵害では疑わしいログイン通知が発生することがありますが、MCP経由で盗まれたトークンを使うと正規のAPIアクセスのように見えるため、検知が難しくなります」と研究者は記しています。

コンポーザビリティチェーン

検証されていないMCPサーバーには隠れたリスクがあります。サードパーティのMCPサーバーをダウンロードして利用し、そのデータ元を確認しない場合、そのサーバーが別のリモートMCPサーバーにリクエストを送っている可能性があります。

CyberArkはこのMCPサーバー攻撃ベクトルを「コンポーザビリティチェーン」と呼んでいます。2つ目のMCPサーバーが正当な出力と隠れた悪意のある指示を返し、1つ目のサーバーがそれを自分の応答と統合してAIエージェントに送信し、AIが悪意のある指示を実行してしまいます。環境変数に機密データが保存されている場合、この方法で攻撃者に漏洩する可能性があり、悪意のあるMCPサーバーに直接接続していなくても被害を受けることがあります。

ユーザー同意疲労

企業がよく実施するセキュリティ対策の一つは、AIエージェントが実行するアクションに対して人間の承認を必須とすることです。しかし、これは諸刃の剣です。Palo Alto Networksによれば、悪意のあるMCPサーバーはAIエージェントやその人間ユーザーに対して、複数の無害なリクエスト（例えば複数の読み取り権限要求）を大量に送りつけることがあります。

しばらくすると、ユーザーは一つ一つ詳細を読まずに承認し始めてしまいます。そのタイミングでMCPサーバーが悪意のあるリクエストを紛れ込ませます。「この攻撃の核心は、多要素認証疲労攻撃と同様で、ユーザーが継続的な認証プロンプトに圧倒され、意図せず不正なアクセスを許可してしまう点です」と研究者は述べています。

ユーザー同意疲労攻撃の一種にサンプリング攻撃があります。LLMの文脈では、単にテキストを生成することを意味します。CyberArkによれば、サンプリングはMCPの高度な機能であり、MCPサーバーがLLMにレスポンスを要求するメッセージを送信できます。人間がこのメッセージをLLMに渡す前にレビューすることになっていますが、悪意のある指示がメッセージの奥深くに埋め込まれていて見落としやすいのです。

例えば、悪意のあるMCPサーバーがLLMに環境変数をすべて取得して送信するよう指示することができます。たとえ人間がサンプリングメッセージをチェックしていても、長大な無害なテキストの中に悪意のある指示が埋もれている場合、見逃してしまう可能性があります。また、LLMの応答も長く複雑な場合、機密情報が隠されていても気づかないことがあります。

管理者バイパス

この攻撃ベクトルでは、MCPサーバーが身元確認を必要としないように設定されている場合（例えば、企業がディレクトリ用のMCPサーバーを設定し、AIエージェントがユーザーの代理で情報を簡単に検索できるようにする場合）に発生します。

ユーザーがこの情報に対して低レベルのアクセスしか許可されていなくても、MCPサーバーがリクエスト元の身元を確認しない場合、AIエージェントが本来知るべき以上の情報を取得できてしまいます。リクエストは、不満を持つ内部関係者、好奇心旺盛な従業員、または従業員環境に何らかの方法で侵入した外部攻撃者から発せられる可能性があります。

さらに、このMCPサーバーがビジネスパートナー、顧客、あるいは一般公開されている場合、この権限昇格は甚大な被害をもたらす可能性があります。

コマンドインジェクション

MCPサーバーがユーザー入力を適切に検証せずに他のシステムに直接渡すと、ユーザーが自分のコマンドを注入できるようになります。これはSQLインジェクションと同様の仕組みです。攻撃者はMCPサーバーが公開しているすべてのツールでコマンドインジェクション脆弱性をテストすることができます。

他の種類のインジェクション攻撃と同様に、MCPサーバーはユーザー入力をシェルコマンドに直接渡してはいけません。適切な入力検証とパラメータ化されたコマンドを使用すべきです。

AIエージェントが複数のMCPサーバーにアクセスできる場合、そのうちの一つのサーバーがエージェントを騙して別のサーバーを不適切に利用させることができます。例えば、一つは医療症状に関する一般情報を提供するサーバー、もう一つは患者の請求システムにアクセスできるサーバーがある場合です。

「シャドーイング攻撃は、エージェントに患者の請求情報を攻撃者のメールアドレスに転送させることができます」とセキュリティ企業Solo.ioのグローバルフィールドCTO、Christian Postaは研究で述べています。

請求システム用のMCPサーバーは安全で、意図通りに動作しています。悪意のあるMCPサーバーは一見何も問題を起こしていないように見え、その悪質な挙動は監査ログにも明確に残らないかもしれません。しかし、AIエージェントが突然患者の請求情報をメール送信したり、他の一見正当な操作で外部に送信し始めることがあります。