前回の記事では、AIエージェントと外部世界を繋ぐ画期的なプロトコル「Model Context Protocol (MCP)」が、その設計思想に起因する「致命的な三要素」によって、プロンプトインジェクションやツール汚染といった新たなセキュリティリスクの温床となっていることを記事にしました。
今回の記事では、セキュリティリスクを理解した上で、どういった対策があるのかをまとめたいと思います。MCPというツールを使いこなすため安全性を確保していく方法を整理できればと思っています。
- MCPサーバーの基本的な防御
- 被害を最小限に抑えるための方法
- プラットフォームレベルの防衛
MCPサーバーの基本的な防御
MCPサーバー限った話ではありませんが、セキュリティにおける基本的な防御とは、ネットワーク制御、認証・認可、そして権限管理です。
ネットワーク制御
特別な理由がない限りにおいては、MCPサーバは、信頼されたプライベートサブネットのみを待ち受けるようにし、外部インターネットからの直接のアクセスは避けるべきです。
対策
前回の記事で紹介した「NeighborJack」脆弱性 は、開発環境における安易な設定が原因で発生します。テスト目的であっても、不用意に
0.0.0.0（すべてのネットワークインターフェース）へバインドすることは絶対に避けるべきです。ホストOSのファイアウォールや、クラウド環境のセキュリティグループ（AWS）やネットワークセキュリティグループ（Azure） を活用し、MCPサーバーとの通信を許可するIPアドレスやポートを厳密に制限することが望ましい対策になります。
認証・認可
MCPの基本仕様では、クライアントとサーバー間の認証が任意（optional）とされています。これは、セキュリティの観点からは重大な設計上の懸念点です。認証のないMCPサーバーは、言わば鍵のかかっていない道具箱と同じであり、ネットワーク的にアクセスできる者なら誰でも、そこに格納された強力なツールを無断で使用できてしまうような過剰な共有や過剰な権限付与につながる可能性があります。
対策
HTTPベースの通信を行うMCPサーバーでは認証を必須と考えるべきです。具体的には、以下のような堅牢な認証・認可メカニズムを実装が考えられます。
トークンベース認証
OAuth 2.1やJWT (JSON Web Token) を用いて、リクエストごとにクライアントの身元と権限を確認する。
相互TLS(mTLS)
特にサーバー間通信など、高度なセキュリティが求められる場面では、クライアントとサーバー双方が電子証明書を提示し合うmTLSを導入し、通信相手が本物であることを暗号学的に保証する。
最小権限の原則（PoLP）
「最小権限の原則（Principle of Least Privilege）」はユーザーやプロセスには、その役割を果たすために必要最小限の権限のみを与えるべきだという考え方です 。MCPサーバーやそのツールが過剰な権限を持っていると、万が一侵害された際の被害（爆風範囲）が不必要に拡大してしまいます。
ファイルアクセス
ツールが特定のファイルを読み込むだけであれば、そのファイルへの読み取り権限のみを与え、他のディレクトリへのアクセスや書き込み権限は与えないようにします。
ネットワークアクセス
特定のAPIと通信するだけのツールであれば、それ以外の外部ホストへのアウトバウンド通信はファイアウォールでブロックし、通信を許可しないようにします。
コマンド実行
OSコマンドを実行するツールは特に危険です。実行可能なコマンドをホワイトリスト形式で厳密に制限し、引数のサニタイズ（無害化）を徹底します。
サンドボックス化と分離
基本的な防御を仮に突破されたことを想定した場合に対応しておくことが、被害を最小限に抑えるための対策です。
サンドボックスとは？
サンドボックスとは、プログラムの実行環境をホストシステムから隔離された「安全な箱庭」に閉じ込める技術です。たとえMCPツールが悪意のあるコードを実行しようとしても、その影響はサンドボックス内に限定され、ホストOSや他のアプリケーション、重要なデータには及びません。
実装方法
現代的な環境では、以下のような技術を用いて効果的なサンドボックスを構築が可能になります。
コンテナ技術の活用
Dockerなどのコンテナ技術は、ファイルシステム、ネットワーク、プロセス空間を隔離した環境を容易に構築できるため、MCPツールのサンドボックス化に最適です。ツールごとに専用の軽量コンテナを用意し、最小限のライブラリと設定のみで実行できるよう構築します。
OSレベルのアクセス制御
Linux環境であれば、SELinuxやAppArmorといった強制アクセス制御（MAC）メカニズムを活用し、ツールプロセスが許可されていないシステムコール（OSの機能呼び出し）を発行したり、不正なファイルにアクセスしたりするのをカーネルレベルで防ぐことが可能です。
権限の分離
各ツールを実行するための専用の低権限ユーザーアカウントを作成し、そのユーザーでプロセスを起動するように設定します。rootで実行することは絶対に避けるべきです。
人間の判断を介在させる
技術的な防御壁を構築する一方で、最終的な判断を人間に委ねる仕組みと、何が起きているかを常に可視化する仕組みも不可欠です。
ヒューマン・イン・ザ・ループ（Human-in-the-Loop）
ファイルの削除やデータの更新、外部への情報送信といった、機密性が高い、あるいは不可逆的な操作をAIエージェントが実行しようとする際には、ユーザーの明確な承認を求めるような仕組みを取ることが望ましいです。
承認を求める仕組みのポイント
承認を求めるダイアログは、ただ「実行しますか？ [はい/いいえ]」では不十分です。ユーザーが情報に基づいた判断を下せるよう、「どのツールが」「どのようなパラメータで」「具体的に何を実行しようとしているのか」を、可能な限り透明性の高い形で提示することが極めて重要です。
監査とログ：『何が、いつ、誰によって行われたのか』を記録する
インシデントは起こりうるもの、という前提に立ち、万が一の際に何が起きたのかを正確に追跡・分析できる体制を整えることが重要です。そのために、MCPツールの実行、API呼び出し、データアクセス、ユーザーの承認操作などを詳細に記録する必要があります。
SIEM連携
SplunkやDataDogといったSIEM (Security Information and Event Management) 製品や中央ログ基盤にリアルタイムで集約することが強く推奨されます。これにより、複数のシステムにまたがる不審な挙動（例: あるユーザーが深夜に複数のシステムから大量のデータをダウンロードしようとしている）を相関的に分析し、自動でアラートを発するようなプロアクティブな脅威検知が可能になります。
全体像で考える - サプライチェーンとプラットフォームレベルの防衛
個々のサーバーのセキュリティを固めるだけでは不十分です。自身が利用するツールそのものの信頼性や、それらが動作するOSプラットフォーム全体のセキュリティにも目を向ける必要があります
サプライチェーンセキュリティ：信頼できないツールを使わない
「ツール汚染」のようなサプライチェーン攻撃を防ぐには、自身のシステムに組み込むコンポーネントを厳しく吟味する必要があります。そのため、利用するMCPサーバーは、その出所が明確で信頼できるものに限定すべきです。公式リポジトリや、信頼できるベンダーが提供するサーバーのみを利用し、出所不明なサーバーの利用は極力避けるようにします。その上で、以下のような対策を考えます。
コード署名
開発者は、自身がリリースするMCPサーバーやツールにデジタル署名を行い、その出所と完全性を保証すべきです。利用者はその署名を検証することで、改ざんされていないことを確認ができます。
バージョン固定とハッシュ検証
利用するツールのバージョンを明示的に固定し、意図しないアップデート（ラグプル攻撃など）によるリスクを回避します。さらに、ツールのハッシュ値（チェックサム）を検証し、取得したファイルが期待通りのものであることを確認します 。
脆弱性スキャン: SCA (Software Composition Analysis)
SCA (Software Composition Analysis) ツールを導入し、利用しているMCPサーバーおよびその依存ライブラリに既知の脆弱性（CVE）が含まれていないか、開発パイプラインの中で継続的にスキャンします 。
プラットフォームによる防御
MCPが普及するにつれ、MicrosoftのようなOSプラットフォームベンダーも、OSレベルでのセキュリティ強化に乗り出しています。これらの機能を活用することで、より根本的なレベルでの安全性を確保できます。
以下はWindows 11の取り組み例になります。
プロキシ経由の通信
すべてのMCPクライアントとサーバー間の通信を、OSが提供する信頼されたプロキシを経由させることで、アクセス許可ポリシーやユーザー同意を一元的に管理・強制します。
ランタイム分離
MCPサーバーをAppContainerのようなOSレベルのサンドボックス内で実行することを要求し、宣言された権限以外での動作を厳しく制限します。
開発者への必須要件
プラットフォーム上で動作するMCPサーバーに対し、コード署名や、必要とする権限の事前申告（マニフェストでの宣言）を義務付けます。
まとめ
Model Context Protocolは、AIの未来を切り拓く、計り知れないポテンシャルを秘めたプロトコルです。しかし、その力は、責任ある実装と運用が伴って初めて安全に活用できます。これからは「セキュリティ・バイ・デザイン」のアプローチがすべての開発者と管理者に求められていくと感じています。今回は、MCPの防御策について自分なりに調べてまとめてきました。最後に、これらの対策を実践的なチェックリストとしてまとめました。もしこの記事、チェックリストが、MCPを利用される方の参考になっていれば幸いです。
| セキュリティ領域 | チェック項目 | 具体的なアクション/確認事項 |
|---|---|---|
| ① ネットワーク | サーバーの公開範囲を制限しているか？ | サーバーをlocalhostまたはプライベートネットワークにのみバインドする。0.0.0.0は原則禁止。 |
| ① ネットワーク | ファイアウォールは適切に設定されているか？ | 必要なポートのみを開放し、不要なインバウンド/アウトバウンド通信をブロックする。 |
| ② 認証・認可 | サーバーへのアクセスは認証されているか？ | OAuth 2.1, JWT, mTLSなどを実装し、全てのAPIアクセスを認証する。 |
| ② 認証・認可 | 最小権限の原則は守られているか？ | 各ツール、各ユーザーに必要最小限のデータアクセス権と実行権限のみを付与する。 |
| ③ アプリケーション | サンドボックス内でツールを実行しているか？ | コンテナ技術やOSの機能（AppArmor等）を使い、ツールの実行環境をホストから隔離する。 |
| ③ アプリケーション | 重要な操作にはユーザーの承認を求めているか？ | ファイルの削除やデータ更新など、機微な操作の前に必ずユーザーの同意を得るUIを実装する。 |
| ④ サプライチェーン | 信頼できるMCPサーバーのみを使用しているか？ | 公式リポジトリや信頼できるベンダーが提供するサーバーのみを利用する。野良サーバーは使わない。 |
| ④ サプライチェーン | ソフトウェアの依存関係は安全か？ | コード署名の検証、バージョン固定、SCAツールによる継続的な脆弱性スキャンを実施する。 |
| ⑤ 監視・運用 | 包括的なログを取得・監視しているか？ | 全てのツール実行を記録し、SIEM等の中央ログ基盤に集約して異常を検知する体制を構築する。 |
| ⑤ 監視・運用 | OSとプラットフォームは最新か？ | OSやミドルウェアのセキュリティパッチを定期的に適用し、プラットフォームレベルの防衛機能を活用する。 |
