MCPを利用しているのに、誰もその接続を監視していない。そんな状態の組織が今、急増しています。

AIエージェントが企業システムに深く入り込むにつれて、MCP（Model Context Protocol）が新しいセキュリティの盲点になっています。開発者がnpmから10秒で導入できるMCPサーバーは、既存のIT資産管理やベンダー審査のプロセスをまったく通りません。CTEM（Continuous Threat Exposure Management）にMCPリスクを組み込むことで、攻撃者より先に露出面を把握できます。

この記事でわかること：

  • MCPがセキュリティプログラムの盲点になっている理由
  • postmark-mcp事件とCVE-2025-6514が示す実害の規模
  • AIエージェントの権限設定が危険な理由
  • CTEMの5フェーズをMCP管理に適用する具体的な方法

MCPは「接続の糊」として広がっている

MCPはAnthropicが2024年末に発表した、AIエージェント向けのプラグインアーキテクチャです。LLMとデータソース・ツールをつなぐ規格で、「AIの世界のUSBポート」とも呼ばれます。

問題は普及の速さにあります。開発者はnpmから一行でMCPサーバーを環境に追加します。変更チケットも承認もありません。既存の調達プロセスやベンダー評価が機能するのは、IT部門が把握している資産に対してだけです。MCP接続はその外側で広がっています。

postmark-mcp事件が示したリスクの現実

2025年9月、npmパッケージ「postmark-mcp」が悪意のあるコードとともに公開されていたことが発覚しました。

攻撃者は正規リポジトリのコードをそのままコピーし、1.0.0〜1.0.15までの15バージョンを正常に動作させました。信頼を積み上げた後、バージョン1.0.16にたった1行のコードを仕込みました。送信されるすべてのメールを攻撃者のアドレスにBCCする処理です。

この1行により、約300組織から毎日3,000〜15,000通のメールが流出しました（参考）。パスワードリセット、請求書、社内文書が数週間にわたって漏れ続け、どのアラートも発火しませんでした。SolarWindsと同じ手法です。信頼を確立してから毒を仕込み、一度信頼されたものは検査を受けなくなる。

AIエージェントの設定ファイルに眠る認証情報

MCP環境では、エージェントが動くために多くの認証情報が必要です。LLMのAPIキー、クラウドサービスの認証情報、外部連携に使うトークン。これらはエージェントがアクセスできる場所——環境変数、設定ファイル、Markdownの指示ファイル、サーバー定義——に平文で書かれます。

2023年にはChatGPTの認証情報が22万5,000件以上、情報窃取マルウェアに収集されました（参考）。その多くに、開発者が設定ファイルに直接書いたAPIキーが含まれていました。MCPはこの問題をより深刻にします。エージェントに渡す認証情報が増え、保存場所が散在するからです。スキャナーがMCPサーバーの設定とMarkdownコンテキストファイルを対象に含んでいなければ、この露出面は見えません。

過剰権限エージェントと実証されたRCE

AIエージェントに管理者権限を与える運用は珍しくありません。開発時に楽だからという理由で、sudo権限がMCPサーバーの定義に書き込まれ、そのまま本番環境で動き続けています。

2025年、セキュリティ研究者はこの問題を2つのCVEで実証しました。CVE-2025-6514はmcp-remoteのリモートコード実行の脆弱性で、CVSSスコアは9.6です。悪意のあるMCPサーバーに接続するだけで、クライアントOSでのコード実行が完了します（参考）。mcp-remoteは43万7,000回以上ダウンロードされており、Cloudflare、Hugging Face、Auth0の導入ガイドにも掲載されています。CVE-2025-49596はAnthropicのMCP InspectorのCVSSスコア9.4の脆弱性で、チェーンされたブラウザエクスプロイトにより開発者マシンへの完全なアクセスを実現します。

セキュリティ研究者Ari Marzouk氏による「IDEsaster」研究では、Cursor、GitHub Copilot、Windsurfなど主要AI IDEで30以上の脆弱性が記録されました。自律エージェントが既存の「安全」とされてきた機能を許可なく呼び出せる構造が問題の核心です。

CTEMの5フェーズをMCPリスクに適用する

CTEMは「攻撃者より先に露出を見つける」という考え方のフレームワークです。MCPのためにゼロから何かを作る必要はなく、既存のCTEMプログラムのスコープを拡張するだけです。

スコーピングでは、AIツールチェーンをスコープに明示的に加えます。開発者ワークステーション、AI開発環境、MCPの設定ファイルを保護すべき資産として定義し、開発リーダーと早期にアラインしておくことが先決です。修正作業は開発チームに降りるため、彼らがリスクを理解していないと修正が進みません。

ディスカバリーでは、MCPサーバーは従来の資産インベントリには現れないことを前提に動きます。開発者ワークステーション、AIツールの設定、変更チケットなしに数秒でインストールされたnpmパッケージの中に存在します。スキャン間でサーバーが変化していないかを検出する仕組みが必要です。静かに更新されるサーバーがpostmark-mcp型の攻撃を再現します。

優先順位付けでは、すべてをフラグ立てして順番に処理しようとしないことが重要です。「この露出から攻撃者が実際に何ができるか」「どのデータに接続しているか」という視点で判断します。ネットワーク経由のトランスポート、環境変数内のAPIキー、サーバー定義に含まれる昇格権限コマンドは、優先して対処すべきシグナルです。

バリデーションでは、フラグを立てた露出が実際に悪用可能かどうかを攻撃パスマッピングやBAS（Breach and Attack Simulation）で確認します。理論上のリスクと実際のリスクを区別することで、対応の効率が上がります。

モビライゼーションは技術的な作業より難しいフェーズです。開発者にとってMCPサーバーは仕事を速くするインフラであり、セキュリティの懸念として見ていません。抽象的な脅威の話より「このツールが何にアクセスできるか、攻撃経路はどこか」という具体的な情報が修正チケットに変わります。

対処を後回しにするコストは実証済み

セキュリティはクラウドに追いつきました。今度はAIに追いつく番です。MCPの盲点を放置するコストは、postmark-mcp事件が具体的に示しています。300組織から数週間にわたってメールが流出し、誰も気づかなかった。既存のCTEMにMCPリスクを組み込む作業は、新しいプログラムを立ち上げることではありません。スコープを広げるだけです。それを攻撃者の前にやるか後にやるかの差です。