Model Context Protocol（MCP）は、AIエージェントをエンタープライズデータやツールに接続するための共通標準として急速に普及しています。アドホックなツールごとの統合に代わり、エージェントが外部サーバーを呼び出し、コンテキストを取得し、アクションを実行できる共有インターフェースを提供します。しかし、エージェントが通信するすべてのMCPサーバーは新しい信頼境界です。正当なメールサービスを偽装した悪意のあるnpmパッケージや、公式MCP SDKで開示された脆弱性など、最近のセキュリティインシデントは、チームがMCPサーバーをプラグアンドプレイとして扱った場合に何が起こるかを示しています。
MCPセキュリティとは、各サーバーをデフォルトで信頼されていないものとして扱い、ソースを審査し、ツールアクセスをスコープし、実行を隔離し、アクションをログに記録し、明示的なポリシーでデプロイメントを管理することです。本番環境におけるエージェント型AIで取り上げたパイロットから本番への道のりを進むチームにとって、MCPセキュリティは、エージェントがそこに到達した際にエンタープライズデータに安全にアクセスできるかどうかを決定するレイヤーです。
主なポイント
- MCPはすべての外部サーバーを新しい信頼境界に変えます。デフォルトでオープンなMCP統合は、エージェントの意図したスコープを超えてエンタープライズデータを露出させる可能性があります。
- 2026年の主要リスクには、ツールポイズニング、MCPサーバーの応答を通じたプロンプトインジェクション、rug-pullおよびサプライチェーン攻撃、過度に広いツールスコープ、OAuthやトークン検証の失敗が含まれます。
- MCPセキュリティのベストプラクティスは、サーバーの審査とバージョン固定、最小権限のツールスコープ、実行のサンドボックス化、包括的な監査ログ、機密アクションに対するhuman-in-the-loop承認を対象とします。
- エンタープライズガバナンスがギャップを埋めます。文書化されたポリシー、データ分類、およびISO/IEC 27001:2022やSOC 2との整合を支援する管理—but それ自体ではコンプライアンスを確立しません。
- 認証済みのリモートMCPサーバーは、ネットワークセグメンテーション、スコープされた認証、エグレス制御、集中ログと組み合わせることで管理しやすくなることが多いです。リモートが自動的に安全なわけではありません。これらの管理が整っている場合にのみ安全になります。
Model Context Protocol（MCP）とは何か？
Model Context Protocolは、LLMアプリケーションが外部データソースやツールに接続する方法を標準化するオープンプロトコルです。公式Model Context Protocol仕様によると、MCPは3つの役割を定義しています。ホスト（エージェントを管理するアプリケーション）、クライアント（ホスト内でサーバーに接続するエンティティ）、サーバー（ツール、リソース、プロンプトを公開するプログラム）です。MCPはAnthropicによるModel Context Protocolの発表で説明されている通り、Anthropicが当初導入したオープンプロトコルです。単一のベンダーが独占的に所有するものではありません。
チームがアドホックなツール統合を超えて移行する理由
MCP以前は、データベース、CRM、ファイルストアにエージェントを接続するにはツールごとにカスタム統合を記述する必要がありました。MCPはこれを共有プロトコルに置き換え、MCP互換のクライアントが任意のサーバーを呼び出せるようにします。より高速な統合、再利用可能なサーバー、モデルの移植性という利点は実在しますが、同じ容易さが攻撃対象を拡大します。開発者が数秒でMCPサーバーをインストールできる場合、問いは「これを構築できるか？」から「このサーバーにデータを信頼すべきか？」に移行します。
MCPがデフォルトでセキュアするもの—そしてセキュアしないもの
MCPはクライアントとサーバー間の通信を標準化します。統合全体をセキュアにするわけではありません。以下はホストとクライアントの責任のままです：サーバーの信頼、認証、同意、出力の検証、および実行管理（サンドボックス化、レート制限、隔離）。仕様では、ツールの説明と注釈は信頼できるサーバーからのものではない限り信頼できないものとして扱うべきだと記載されています。MCPは接続の標準的な方法を提供しますが、接続先が安全であることを保証するものではありません。
今なぜMCPセキュリティが重要なのか
MCPサーバーは多くの場合、データベース、ファイルシステム、メールプロバイダー、ビジネスAPIの認証情報を保持しています。サーバーが侵害されたり、過剰な権限が付与されたり、悪意のある場合、データ漏洩の対象はそれらの認証情報が到達できるすべての範囲に拡大します。
| 側面 | アドホック統合 | MCPベース統合 |
|---|---|---|
| 信頼境界 | ツールごとに1つのカスタム統合 | サーバーごとに1つの標準境界、エージェント間で再利用 |
| 権限スコープ | 統合ごとに定義、多くはレビュー対象 | サーバーのデフォルトから継承されることが多く、過剰スコープになりやすい |
| 監査可能性 | 統合ごとのカスタムログ | 標準化された呼び出し、ただしログは設定が必要 |
| サプライチェーンリスク | 選択された依存関係に限定 | インストール可能なサーバーはすべて潜在的な依存関係に |
MCPは新しいサーバーの追加を極めて容易にし、それぞれが境界を拡張します。多くのパイロットはデフォルト設定でローカルサーバーを実行します—認証なし、監査ログなし、スコープされた認証情報なし—これはデモには適していますが、エージェントが実際の顧客データにアクセスする場合は不適切です。
文書化されたMCPセキュリティインシデント、脆弱性、攻撃パターン
すべてのMCPセキュリティ懸念が同じではありません。一部は確認された実際のインシデントです。他は既知の悪用前に修正された開示済み脆弱性です。さらに他は研究デモンストレーションです。このセクションは3つを区別します。
確認されたインシデント：悪意のあるpostmark-mcp npmパッケージ
2025年9月、postmark-mcpという悪意のあるサードパーティnpmパッケージが、メール配信サービスのPostmarkを偽装しました。これは公式のPostmarkパッケージではありませんでした—Postmarkはこのインシデント前にnpmで公式MCPサーバーを公開していませんでした。Postmarkの公式セキュリティ通知によると、このパッケージは15バージョンにわたって信頼を構築した後、バージョン1.0.16でバックドアを追加し、送信メールを密かに外部サーバーにBCC送信しました。Koi Securityの悪意のあるパッケージ分析は約1,500の週間ダウンロードを報告しました。Koi Securityに帰属する隠されたBCC送信先はgiftshop.clubドメインのアドレスでした。
これは実際の悪意のあるパッケージおよびソフトウェアサプライチェーンインシデントであり、Postmarkの公式プラットフォームの侵害ではありませんでした。Postmarkの正当なAPIとサービスは侵害されず、影響を受けたままです。このインシデントはサプライチェーンリスク、過剰権限リスク、サーバー審査の失敗、バージョン変更リスクを示しています。パターンはrug-pullに似ています。「rug pull」はここではパターンの説明として使用されており、Postmark自身の分類ではありません。
開示された脆弱性：CVE-2025-66414およびCVE-2025-66416
公式MCP SDKの2つの開示された脆弱性は、実装レベルのリスクを浮き彫りにします。これらは開示された実装の脆弱性であり、確認された実際の侵害ではなく、野生での悪用の公開証拠はありません。
CVE-2025-66414 — TypeScript SDK。 1.24.0より前のMCP TypeScript SDKは、HTTPベースのサーバーに対してDNS rebinding保護がデフォルトで有効になっていませんでした。サーバーがStreamableHTTPServerTransportまたはSSEServerTransportを使用して認証なしでlocalhost上で実行され、enableDnsRebindingProtectionが有効でない場合、悪意のあるWebサイトがsame-origin policyをバイパスし、公開されたツールやリソースを呼び出す可能性がありました。stdioトランスポートには影響しません。1.24.0で修正されました。CVE-2025-66414のGitHubアドバイザリおよびCVE-2025-66414のNVDレコードを参照してください。
CVE-2025-66416 — Python SDK。 1.23.0より前のMCP Python SDK（PyPIのmcp）は、HTTPベースのサーバーに対してDNS rebinding保護がデフォルトで有効になっていませんでした。サーバーがFastMCPとstreamable HTTPまたはSSEを使用して認証なしでlocalhost上で実行され、TransportSecuritySettingsが設定されていない場合、悪意のあるWebサイトがsame-origin policyをバイパスし、公開されたツールやリソースを呼び出す可能性がありました。stdioトランスポートには影響しません。1.23.0で修正されました。CVE-2025-66416のGitHubアドバイザリおよびCVE-2025-66416のNVDレコードを参照してください。
両方のアドバイザリは、認証なしでローカルにHTTPベースのMCPサーバーを実行することは推奨されないと述べています。影響を受ける構成は特定のものです：stdioトランスポートと認証済みサーバーは影響を受けませんでした。
研究デモンストレーションと理論的攻撃パターン
セキュリティ研究者はMCPがどのように悪用されうるかを示す攻撃パターンをデモンストレーションしています。これらは概念実証であり、確認された実際のインシデントではありません。文書化されたMCP攻撃パターンは、悪意のある指示がモデルには見えるがユーザーには明らかでないツールの説明に埋め込まれ、エージェントがユーザーが承認していないアクションを実行する可能性を示しています。また、最初は良性だったサーバーが後になって返されたデータを通じて間接的なプロンプトインジェクションを導入し、モデルを直接悪用することなくエージェントの動作を操作する方法も示しています。
2026年の主要MCPセキュリティリスク
ツールポイズニングと悪意のあるMCPサーバー
ツールポイズニングは、サーバーがモデルが読むがユーザーには見えないツールの説明やメタデータに悪意のある指示を埋め込む場合に発生します。エージェントはそれらの指示に従い、ユーザーの意図外のアクションを実行する可能性があります。postmark-mcpインシデントは正当なプロジェクトを偽装した悪意のあるサーバーの確認された事例です。
MCPサーバーの応答を通じたプロンプトインジェクション
MCPサーバーはデータ—ファイルの内容、データベースの行、APIの応答—を返します。そのデータに指示が含まれている場合、エージェントはそれらをコマンドとして扱う可能性があります。エージェントはサーバーをデータソースとして信頼するため、ホストが検証と隔離を行わない限り、返されたコンテンツはインジェクション対象になります。より詳しい扱いについては、エージェント型AIのためのLLMセキュリティを参照してください。
Rug-pullとサードパーティのサプライチェーンリスク
rug-pullは、最初は安全だったサーバーが更新後に動作を変更する場合に発生します。サプライチェーンリスクは依存関係、推移的パッケージ、保守されていないサーバーにまで及びます。エージェントはツールを自動的かつ頻繁に呼び出すため、侵害されたサーバーの影響範囲は典型的なライブラリ依存関係よりも大きくなります。
過度に広いツールスコープと認証情報の露出
サーバーには必要以上に広い権限が付与されることがよくあります。認証情報が侵害されたり過剰な権限が付与されたサーバーを通過する場合、露出はそれらの認証情報が到達できるすべての範囲に及びます。最小権限は、サーバーが問題を起こした際の被害を制限する管理策です。
OAuth、トークン検証、認証の失敗
HTTPベースのリモートサーバーのMCP認証は、MCP認証ガイダンスで説明されている通り、OAuth 2.1の規則に従います。認証はMCPサーバーが公開する機密リソースと操作を保護します。OAuthは自動的なセキュリティ保証ではありません：実装はトークンのオーディエンス、発行者、有効期限、スコープを検証する必要があります。トークンは短命で安全に保管されるべきです。本番フローはHTTPSを使用すべきです。認証情報、認証ヘッダー、トークン、認証コードはログに書き込まれてはなりません。包括的なスコープは避け、ツールごとに最小権限のスコープを付与すべきです。MCPは開発者に代わってOAuthを安全に実装するわけではありません。トークンパススルー、confused-deputyリスク、SSRF、スコープ最小化に関するより広範なガイダンスについては、MCPセキュリティのベストプラクティスを参照してください。
MCPセキュリティのベストプラクティス
すべてのMCPサーバーを審査して固定する
すべてのMCPサーバーを信頼されていないソフトウェアとして扱います：発行者が公式であることを確認し、要求される権限をレビューし、ソースまたは信頼できる監査を読み、特定のバージョンに固定し、信頼する組織からのサーバーを優先します。postmark-mcpインシデントが警鐘となる事例です。
ツールスコープに最小権限を適用する
各サーバーに必要最小限のアクセスを付与します。読み取りと書き込みのスコープを分離します。共有管理者トークンの代わりにスコープされた認証情報を使用します。サーバーが侵害された場合、被害は付与された狭いスコープに限定されます。
MCPサーバーの実行をサンドボックス化して隔離する
MCPサーバーを隔離された環境—コンテナ、VM、または個別のネットワークセグメント—で実行し、ホスト上で直接実行しないでください。サーバー間でファイルシステムや認証情報を共有しないでください。サンドボックス化は影響範囲を「サーバーがすべてに到達できる」から「サーバーが明示的に許可されたものにのみ到達できる」に縮小します。
監査ログとエージェントの可観測性
認証されたID、付与されたスコープ、ツール呼び出し、サニタイズされた入出力、ポリシー決定、承認イベント、エラー、最終的なアクション結果をログに記録します。認証情報、トークン、機密個人情報はログに記録されてはなりません。ログは、チームがイベントを再構築し、コンプライアンスを証明し、インシデントになる前に異常を検出するためのものです。
機密アクションに対するhuman-in-the-loop
現実世界の影響を持つアクション—本番データベースへの書き込み、外部メールの送信、有料APIの呼び出し、顧客レコードの変更—には人間の承認を要求します。しきい値はデータ分類に基づくべきです—公開データは承認不要の場合がありますが、機密データと制限データには明示的な承認が必要です。
AIエージェントのエンタープライズガバナンスフレームワーク
ポリシー、所有権、承認ワークフロー
ガバナンスは文書化されたポリシーから始まります：新しいMCPサーバーを誰が承認できるか、どのようなレビューが必要か、各エージェントデプロイメントを誰が所有するか。明示的な所有権がない場合、開発者はアドホックにサーバーをインストールし、セキュリティチームはインシデント後にのみ発見します。提案、レビュー、承認、デプロイというシンプルなワークフローが、本番前にほとんどのサプライチェーンリスクを阻止します。
データ分類とデータ常駐管理
データを公開、内部、機密、制限に分類し、エージェントとそのサーバーがどの分類にアクセスできるかを決定します。必要に応じて常駐管理を適用します：EUまたは米国の規制の対象となるデータは、適切な地域外のサーバーを通じて流れてはなりません。
MCPの利用をISO/IEC 27001:2022およびSOC 2に整合させる
MCPセキュリティ管理はISO/IEC 27001:2022およびSOC 2との整合を支援できますが、これらの管理を実装するだけではコンプライアンスは確立されません。サーバー審査はサプライヤーリスク管理に、最小権限はアクセス制御に、監査ログは監視に、human-in-the-loopは変更管理に対応します。完全なコンプライアンスには、より広範なマネジメントシステム、リスク評価、内部監査、外部認証が必要です。
安全なAI統合アーキテクチャパターン
ローカルvsリモートMCPサーバー
ローカルサーバーは同じホスト上で実行されます—開発にはシンプルですが、ファイルシステムとネットワークを共有し、影響範囲を広げます。リモートサーバーは個別に実行され、認証でき、監査が容易です。リモートが自動的に安全なわけではありません：オープンインターネット上の認証なしのリモートサーバーは、適切に設定されたローカルサーバーよりも悪い状態です。認証済みのリモートサーバーは、ネットワークセグメンテーション、スコープされた認証、エグレス制御、集中ログと組み合わせることで管理しやすくなることが多いです。
OAuthと認証済みMCP接続
HTTPベースのリモートサーバーのMCP認証はOAuth 2.1の規則に従います。スコープされた、短命の、ローテーションされる、安全に保管されたトークンを使用します。すべてのリクエストでトークンのオーディエンス、発行者、有効期限、スコープを検証します。認証情報、認証ヘッダー、トークン、認証コードをログに書き込まないでください。包括的なスコープは避け、ツールごとに最小権限のスコープを付与してください。本番フローはHTTPSを使用すべきです。MCPはOAuthを安全に実装してくれません—プロトコルレベルの要件と、トークンパススルー、confused-deputyリスク、スコープ最小化に関するより広範なガイダンスについては、MCP認証ガイダンスおよびMCPセキュリティのベストプラクティスを参照してください。
ネットワークセグメンテーションとエグレス制御
MCPサーバーをエグレスが制御されたプライベートサブネットに配置します。送信トラフィックをIPアドレスとドメインの許可リストに制限します。これにより、サーバーが侵害された場合の持ち出し経路が制限されます—これはHDWEBSOFTがIP許可リスト付きのNAT Gatewayを通じた送信メールに使用しているのと同じ原則です。安全なAI統合に関するより広範なコンテキストについては、当社のAI開発サービスおよびサイバーセキュリティサービスを参照してください。
セキュリティファーストのMCPデプロイメントワークフロー
防御可能なMCPデプロイメントは再現可能なワークフローに従います：サーバーを監査する（ソースの確認、権限のレビュー、コードの読解）、権限をスコープする（ツールごとの最小権限、スコープされた認証情報）、実行を隔離する（コンテナまたは個別のネットワークセグメント）、動作を観察する（ID、スコープ、ツール呼び出し、サニタイズされたI/O、ポリシー決定、承認、エラー、結果をログに記録）、および人間の監視を適用する（データ分類に基づく機密アクションの承認）。
HDWEBSOFTはAIエージェントとエンタープライズデータを含むクライアントエンゲージメントにおいてこのワークフローを適用しています。ISO 9001およびISO/IEC 27001認証のソフトウェア開発パートナーとして、HDWEBSOFTはセキュリティを最終チェックリストではなくリリースゲートとして扱います。目的はチームを遅らせることではなく、エージェントが本番に到達した際にMCPレイヤーが障害点にならないことを確認することです。
結論
MCPはAIエージェントをエンタープライズデータに接続するための正しい方向性です。共有プロトコルはカスタム統合のもつれよりも優れています。しかしMCPセキュリティは自動的ではありません。すべてのサーバーは信頼境界であり、すべてのツールスコープは潜在的な影響範囲であり、すべての更新は動作が変化する機会です。安全に出荷するチームは、サーバーを審査し、最小権限を適用し、実行を隔離し、重要なものをログに記録し、人間をループ内に維持します。
チームがMCPを通じてAIエージェントをエンタープライズデータに接続している場合、最も価値のある次のステップは本番前の独立したレビューです。AIセキュリティおよびアーキテクチャ監査をリクエストして、サーバー審査、ツールスコープ、認証、ログ、ガバナンスのギャップを特定し—インシデントが強制する前に具体的な remediation 計画を取得してください。
FAQ
MCPセキュリティとは何ですか？
MCPセキュリティとは、Model Context Protocolを通じて外部データやツールに接続するAIエージェントを保護する実践です。サーバーの審査、最小権限のツールスコープ、実行の隔離、監査ログ、human-in-the-loop制御、およびMCPベースの統合のエンタープライズガバナンスを対象とします。
最も一般的なMCPサーバーのセキュリティリスクは何ですか？
最も一般的なMCPセキュリティリスクには、悪意のあるサーバーによるツールポイズニング、MCPサーバーの応答を通じたプロンプトインジェクション、rug-pullおよびサードパーティのサプライチェーン攻撃、過度に広いツールスコープと認証情報の露出、および認証済みデプロイメントにおけるOAuthやトークン検証の失敗が含まれます。
本番環境でMCPサーバーを安全にするにはどうすればよいですか？
本番環境でMCPサーバーを安全にするには、すべてのサーバーを審査してバージョンを固定し、最小権限のツールスコープを適用し、サーバーの実行をサンドボックス化し、認証されたIDとツール呼び出しをログに記録し、機密性の高いアクションにhuman-in-the-loop承認を適用し、デプロイメントをエンタープライズガバナンスとコンプライアンス管理に整合させます。
Model Context ProtocolはエンタープライズAIエージェントにとって安全ですか？
チームがすべてのMCPサーバーを新しい信頼境界として扱い、明示的なセキュリティ管理を適用する場合、MCPはエンタープライズAIエージェントにとって安全です。MCPはクライアントとサーバー間の通信を標準化しますが、サーバーの信頼、認証、出力の検証、および実行管理はホストとクライアントの責任のままです。
MCPセキュリティはISO/IEC 27001:2022やSOC 2のコンプライアンスにどのように貢献しますか？
MCPセキュリティ管理は、サーバー審査、最小権限アクセス、監査ログ、サプライヤーリスク管理を既存の管理カテゴリに対応させることで、ISO/IEC 27001:2022およびSOC 2との整合を支援できます。ただし、これらの管理を実装するだけではコンプライアンスは確立されません。組織はより広範なマネジメントシステムと監査要件も完了する必要があります。
AI Security & Architecture Auditはいつ実施すべきですか？
AIエージェントを本番環境に昇格させる前、セキュリティインシデントやヒヤリハットの後、エージェントを新しい機密データソースに接続する際、および新しいMCPサーバーが本番ワークフローに導入される際に、AI Security & Architecture Auditを実施してください。
