MCPシステムを安全に：よくある11のリスクとその対策

MCPのリスクは大きく分けて、LLMの操作、データとアクセスのセキュリティ、インフラストラクチャの脆弱性という3つのカテゴリに分類されます。

MCPサーバーは多くの場合、幅広い社内システムへのアクセスを提供するため、潜在的なセキュリティリスクは高くなります。ただし、実際にリスクが顕在化する可能性は、セットアップによって大きく左右されます。

個人や企業がシステムを確実に保護するために講じられる対策は数多くあります。また、プロトコルは常に、接続されたMCPサーバーが公開しうる機能やデータに見合ったものであるべきです。

MCPとMCPセキュリティとは？

Model Context Protocol（MCP）は、LLMベースのアプリ（ホスト）を外部システムに接続するためにAnthropicが策定したオープン標準です。

MCPシステムには、ホスト、クライアント、サーバーという3つの中核コンポーネントがあります。ホストは多くの場合AIアシスタントで、クライアントを介して外部のMCPサーバーに接続します。その後、外部の機能（ツール）の実行、データ（リソース）の取得、またはLLMのコンテキストウィンドウに追加するプロンプトの取得をリクエストできます。

拡大

MCPセキュリティとは、MCPシステム内の接続とコンポーネントを保護するプロトコルを指します。MCPには固有の重要な課題がいくつかあります。たとえば、AIアプリがエージェント機能を備えていることが多い点や、メッセージに悪意のある指示が埋め込まれる可能性がある点などです。

プロンプトインジェクション、脆弱な認証、安全でないサードパーティ連携など、MCPに限らない既知の問題も課題となります。他のコンピューターシステムと同様に、MCPの保護には、信頼できるサーバーのみを使用するといった手続き上のプロトコルと、APIゲートウェイなどの技術的な制御の組み合わせが用いられます。

MCPの脅威はどの程度深刻なのか？

MCPは急速に普及したLLM技術であり、多くの組織や一般消費者向けアプリで利用されています。MCPサーバーはコードで書かれたプログラムであるため、他のアプリケーションと同様に脆弱性を抱えています。

ただし、組織が管理された環境でMCPを導入している場合、一般的には安全です。信頼できるサーバーと検証済みの権限でシステムを構築することと、審査されていない十数台のサーバーに自律型エージェントを接続することとの間には、大きな隔たりがあります。

脅威 #1：間接プロンプトインジェクション

攻撃者は、MCPサーバーが返すドキュメント、Webページ、またはツールの出力の中に、LLMを標的とした指示を仕込むことができます。ホストがこの内容をコンテキストウィンドウに追加すると、LLMがそれを正規の指示と誤認する可能性があります。

さらに、こうした指示は一見すると妥当に見えることがあります。たとえば、取得されたサポートチケットに、回答を生成する前に機密性の高い顧客記録をエクスポートするようLLMに指示する内容が含まれている場合があります。

間接プロンプトインジェクションへの対策

プロンプトインジェクションへの対処は、通常ホストレベルで行うべきです。外部コンテンツには信頼できないものとしてラベルを付け、機密情報のリクエストには、ヒューマンインザループ（人間の介在）による十分な情報に基づいた承認を必須とすべきです。悪意のあるドキュメントやデータを呼び出して、ホストとLLMがどう反応するかを確認するセキュリティテストも有効です。

脅威 #2：ツールポイズニングとラグプル

ツールポイズニング攻撃では、MCPツールの説明やスキーマに悪意のあるコードが追加されます。これにより、MCPが利用可能なツールを最初に公開するディスカバリーフェーズで、LLMが影響を受けるおそれがあります。

拡大

ラグプルは、承認済みのメタデータが変更される特殊なツールポイズニングです。この形態のツールポイズニングでは、悪意のあるツールを直接呼び出させるのではなく、信頼できるツールをモデルがどのように使用するかを変えてしまう可能性があります。

ツールポイズニングとラグプルへの対策

ホストは各ツールを使用する前にその定義全体を検査し、承認済みの信頼できるツールのリストと照合することで、変更を検出すべきです。パラメーターのチェックは、危険な機能が含まれる可能性を特定し、フラグを立てるのに役立ちます。

脅威 #3：過剰な権限

ユーザーがMCPサーバーや（ホストを介して）接続されたLLMに、タスクに必要な範囲を超える権限を付与することはよくあります。たとえば、読み取り専用で十分な場面で書き込み権限を与えたり、社内のファイルシステム（Google Driveなど）へのフルアクセスを与えたりするケースです。

こうした広範な権限の肥大化（パーミッションクリープ）は、悪意のあるツール呼び出しなど、他の脆弱性による被害範囲を拡大させるおそれがあります。企業内でユーザーがAIツールを使った日々の業務の中で権限を付与していくうちに、権限が「積み重なっていく」ことはよくあります（権限の蓄積）。

過剰な権限への対策

この問題に対する最も直接的な対策は、権限とOAuthスコープ（読み取り、書き込み、フルアクセスなど）を制限することです。特に機密性の高い操作についてはユーザーによる承認が重要ですが、権限はシステムレベル（オペレーティングシステム、MCPホスト、サーバー）でも制御すべきです。

脅威 #4：脆弱な認証と認可

認証は、MCPサーバーに接続するユーザーやアプリケーションのIDを検証します。認可は、それらがどのツールやリソースにアクセスできるかを規定します。

設定が不十分なMCPサーバーは、ユーザーを正しく認証したりアクセス制限を適用したりせずに、リクエストやトークンを受け入れてしまう場合があります。さらに、検証が脆弱な場合、盗まれた認証情報によって悪意のある攻撃者にアクセスを許してしまうおそれがあります。

脆弱な認証と認可への対策

リモートMCPサーバーでのOAuthベースの認証、有効期間の短いトークン、ロールベースのアクセス制御（RBAS）はいずれも、脆弱な認可のリスク軽減に役立つ対策です。ロールベースのアクセスは、サーバー自体にアクセス権がある場合でも、ユーザーが自身の権限を超えてデータやツールにアクセスすることを防げるため有用です。

脅威 #5：認証情報の漏洩と悪用

MCPサーバーは、外部サービスへの接続にAPIキーやOAuthアクセストークンなどの認証情報を日常的に使用します。これらが漏洩したり悪用されたりすると、攻撃者が機密データや機能にアクセスできるようになるおそれがあります。

その一例がトークンパススルーです。これは、アクセストークンが実際に受信側のサービス向けのものであるかを検証せずに、MCPサーバーがそのトークンを別のサービスへ転送してしまうものです。その結果、受信側のサービスの保護が不十分な場合、漏洩につながる可能性があります。

認証情報の漏洩と悪用への対策

有効期間が短くスコープを限定したトークンや認証情報のローテーションは、漏洩したデータが悪意のある攻撃者に利用される範囲を抑えるのに効果的です。APIキーや認証情報は、常にシークレットマネージャーを使用して安全に保管すべきです。

脅威 #6：混乱した代理（Confused Deputy）攻撃

混乱した代理攻撃は、攻撃者が信頼できるアプリケーションをだまし、その権限を使って正当なユーザーが許可していない操作を実行させることで発生します。この場合、MCPサーバーが「代理」にあたります。

拡大

攻撃者は、MCPサーバーの脆弱性（OAuth検証の不備など）を悪用し、ツール呼び出しやデータ取得といった悪意のある処理を実行します。

混乱した代理攻撃への対策

すべてのツール呼び出しが特定のユーザーに属するものであることを検証する認可の検証は、混乱した代理攻撃の抑止に役立ちます。さらに、データのエクスポートなどの機密性の高い操作には、明示的な認可を必須とすべきです。

脅威 #7：悪意のあるサーバーと侵害された依存関係

MCPサーバーには悪意のあるコードが含まれている場合があり（本質的には外部プログラムであるため）、サードパーティのライブラリなど、侵害された依存関係に依存している場合もあります。これはMCP特有の問題ではなく、ソフトウェアサプライチェーンの問題です。

その単純な例として、攻撃者が正規のものに見える連携機能を配布するケースが挙げられます。いったんセットアップされると、その連携機能は認証情報を盗んで再利用したり、機密データにアクセスしたり、許可されていない操作を実行したりできます。

悪意のあるサーバーと侵害された依存関係への対策

MCPサーバーは、信頼できる審査済みのソースからのみインストールしてください。可能であればコードを確認し、外部の依存関係は必ずチェックしてください。サーバーが定期的に更新され、パッチが適用されていることを確認してください。

脅威 #8：サーバーサイドリクエストフォージェリ（SSRF）

サーバーサイドリクエストフォージェリ（SSRF）とは、攻撃者がMCPサーバーをだまして、ユーザーが意図していない内部アドレスにネットワークリクエストを送信させる攻撃です。

これは、MCPサーバーがURLから情報を取得するツールを公開している場合に発生する可能性があります。攻撃者がURLパラメーターに影響を与えられる場合、内部APIやクラウドサービスなど、任意のネットワークアドレスに変更できます。その結果、機密データが取得され、アクセス可能な状態になるおそれがあります

サーバーサイドリクエストフォージェリ（SSRF）への対策

MCPサーバーは常にURLを検証し、制限された内部ネットワークアドレスへのアクセスをブロックし、外部へのネットワークアクセスを防止すべきです。リダイレクトについても同じプロトコルに従う必要があります。

脅威 #9：セッションハイジャック

セッションハイジャックとは、攻撃者がMCPクライアントとサーバー間のアクティブな接続を乗っ取ることです。

たとえば、攻撃者はセキュリティ対策が不十分なMCPアプリケーション（ホストやサーバーなど）からセッションIDを盗む可能性があります。MCPサーバーがこのIDを受け入れてしまうと、攻撃者はユーザーの正当な権限でツールを呼び出せるおそれがあります。

対策

セッションハイジャックのリスクは、MCPシステム内のすべてのアプリケーションで厳格な本人確認を行うことで低減できます。また、セッションIDが特定されるのを防ぐには、MCPクライアントとリモートサーバー間の暗号化も不可欠です。

脅威 #10：ミックスアップ攻撃

ミックスアップ攻撃では、攻撃者がMCPクライアントをだまし、クライアントとMCPサーバーの間に位置する悪意のある認可サーバーに認可コードを送信させます。認可サーバーとは、要求されたアクセスが認可されていることを確認したうえで、OAuthアクセストークンを発行するアプリケーションです。

拡大

MCPホストが、それぞれ異なる認可サーバーを使用する複数のサービスに接続している場合、攻撃者はそのうちの1つを（悪意のあるサービスを登録するなどして）制御し、正規のサーバーが発行した認可コードをクライアントに悪意のあるサーバーへ送信させることができる可能性があります。このミックスアップにより、攻撃者が認可されたアプリケーションになりすまし、保護されたサービスにアクセスできてしまうおそれがあります。

ミックスアップ攻撃への対策

MCPクライアントは、OAuthプロセス全体を通じて認可サーバーの身元を検証すべきです。具体的には、サーバーの発行者識別子（iss）を想定される身元と照合し、一致しない場合は拒否する必要があります。

脅威 #11：ローカルMCPサーバーの侵害

多くのMCPサーバーは、ユーザーのローカルマシン上で動作します。ユーザーはサードパーティからサーバーをインストールすることもあれば、自分で構築することもあります。攻撃者がこのローカルMCPサーバーを侵害できれば、ローカルシステムの広範囲にアクセスできるおそれがあります。

攻撃者がアクセスを得る方法はさまざまです。正規の連携機能を装った悪意のあるサーバーを配布する、MCPホストの設定を改変して悪意のあるコマンドを発行させる、あるいはセキュリティ制御が不十分な環境で動作しているMCPサーバーにアクセスする、といった方法があります。最後の例としては、ブラウザをだましてlocalhostのサービスにリクエストを送信させるDNSリバインディングなどが挙げられます。

ローカルMCPサーバーの侵害への対策

ローカルMCPサーバーを使用する際は、サンドボックス化と厳格な同意プロトコルが重要です。MCPサーバーは必ず信頼できる提供元からのみインストールし、オペレーティングシステムの権限によって、アクセスできるディレクトリを制限すべきです。

MCPの脆弱性の多くは、古い脅威が新しい装いをまとったもの

MCPの脆弱性は、既知のリスクや攻撃手法が新たな形で応用されることで生じる場合が多くあります。MCPは、LLM、MCPサーバー、外部サービス間のやり取りを通じて、攻撃者がこうした脆弱性を悪用する新たな手段をもたらします。

もちろん、MCP特有の脅威も存在します。しかし、厳格な認可の適用、信頼できる提供元の利用、プロンプトインジェクションへの対策といった標準的なセキュリティプロトコルが、あらゆるMCP実装の保護に大きく役立つことを覚えておくとよいでしょう。