8月14日、Cloudflareが「How Cloudflare detects MCP traffic and helps secure it」と題した記事を公開した。この記事では、CloudflareがMCPトラフィックをネットワーク層で検出・制御する仕組みと、新たに追加されたCloudflare One向けのセキュリティ機能について詳しく紹介されている。
なぜ今、MCPのセキュリティが問題になるのか
Model Context Protocol（MCP）は、AIエージェントがSaaSやAPIをツールとして呼び出すための共通プロトコルだ。Claude Code、Codex、Cursor、VS Codeといったクライアントから、たった1行の設定でMCPサーバーに接続できる。
問題は、このトラフィックが通常のHTTPS通信と見分けがつかない点にある。MCPは特定のホスト名やパスを強制しないため、https://tools.example.com/api のような普通のURLでMCPサーバーが動いていても、ネットワーク機器からは判断できない。
さらに根本的な問題として、AIエージェントは人間と違い、誤った判断を疲れることなく何千回でも繰り返す。人間のエンジニアが1日にできる操作には自然な上限があるが、エージェントにはそれがない。
MCPトラフィックの検出：プロトコルヘッダーを使う
CloudflareがMCPトラフィックを識別する核心は、**MCP-Protocol-Version HTTPヘッダー**だ。
MCP 2025-11-25仕様では、初期化後のすべてのHTTPリクエストにこのヘッダーを含めることがMUSTとされている。さらにMCP 2026-07-28仕様では、すべてのPOSTリクエストへの付与が必須となった。
ツール呼び出しのリクエスト例：
POST /mcp HTTP/1.1
Host: tools.example.com
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_weather"}}
2026-07-28仕様ではMcp-MethodとMcp-NameがHTTPヘッダーに追加された。これによりロードバランサーやセキュリティ製品は、ボディをパースせずに操作内容を把握できるようになる。tools/list と tools/call をヘッダーだけで区別してレート制限をかけることも可能だ。
ただし、このヘッダーは万能ではない。旧来のクライアントからの初回リクエストにはヘッダーが含まれない場合があり、stdio（ローカル実行）のMCPサーバーはそもそもネットワークトラフィックを生成しない。ヘッダーの存在はMCPの強い陽性指標だが、ヘッダーがないからといってMCPでないとは言えない。
元記事公開時点でリリース：Gateway向け新セレクター
元記事の公開（8月14日）時点で、すべてのCloudflare Zero Trustユーザーは、GatewayのHTTPログでMCPトラフィックの表示を確認でき、新しいセレクターで制御できるようになっている：
experimental.is_mcp == true
TLS検査が有効な環境でMCP-Protocol-Versionヘッダーが検出された場合、このセレクターがtrueとなり、Allow/Blockポリシーを適用できる。Cloudflareのネットワークを日々通過する数百万のリクエストから構築した検出ヒューリスティックを使っており、特定のホスト名やURLを事前に知らなくても分類できる。
「Shadow MCP」と「Portal迂回」は別の問題
記事ではMCPセキュリティリスクを2つに整理している。
Shadow MCP：組織が承認していないMCPサーバーへの接続だ。従業員がリポジトリや同僚のメッセージからサーバーを見つけ、セキュリティチームの知らないまま直接クライアントに追加する。どんなツールが公開されているか、どんなデータが送られているかが把握できない。
Portal迂回：組織が承認しMCP Server Portalsに登録済みのサーバーに対して、Portalを使わず直接アップストリームのURLへ接続する行為だ。Portalが持つAccessポリシー、ツールカタログ、DLPスキャン、監査ログをすべてバイパスできてしまう。
GatewayはShadow MCPへの主要な対策となるが、Portal迂回にはGatewayに加えて、直接アクセスを拒否できるオリジン側の設定（Accessポリシー、ソースIP制限など）が必要だ。
3層の制御ポイント
記事はMCPリクエストを制御できる場所を3箇所に整理している。それぞれ守備範囲と限界が異なるため、組み合わせて使うことが前提となる。
- クライアント内（フック）：モデルがツールを選択した後、ネットワークに送出する前に介入できる。ローカルの
stdioサーバーもカバーできるが、従業員が使うすべてのクライアントに設定を展開する必要があり、一元管理が難しい。 - ネットワーク境界（セキュアWebゲートウェイ）：TLS検査と組み合わせることで、クライアントに依存せず最も広い範囲のリモートMCPトラフィックを検出・制御できる。ただしオフネットワークやローカル
stdioには届かない。 - MCPサーバー側：最も豊富な実行コンテキストを持ち、ツール呼び出しの直前に拒否できる最後の砦だ。Cloudflareはこのパターンを「WriteGuard」としてCloudflare自社の内部MCPサーバーに適用しており、ツールごとにリスクティアを設定してwrite操作を制御している。クライアントを切り替えても迂回できない点が特徴だ。
3層のうちどれか1つが万能なわけではなく、stdioサーバーをネットワーク層では捕捉できないように、層ごとに死角が存在する。記事はこの前提を踏まえ、多層防御として組み合わせることを推奨している。
詳細はHow Cloudflare detects MCP traffic and helps secure itを参照していただきたい。
