Cloudflare Gateway、MCPトラフィックの検出とブロックが可能に

Cloudflareは August 14, 2026 に、Gateway製品にModel Context Protocolの 検出機能を出荷し、企業のネットワークチームに、AIエージェントが暗号化 セッション内で生成するツール呼び出しトラフィックを可視化し - そして ブロックする - 手段を提供した。これまでそのトラフィックは事実上不可視 だった。Cloudflareの発表はこう述べる。「Model Context Protocolは保証 されたホスト名を使わず、パスに /mcp を要求しないため、直接接続は他の どのHTTPS APIコールとも同じように見えることがある」。

この制御は新しいブール型のGatewayセレクター experimental.is_mcp == true で、Cloudflareのchangelogによれば、HTTP ポリシーで該当するリクエストの許可、ブロック、分離に使える。ベータ版 として提供され、一般提供前に変更される可能性がある。

検出の仕組み

Forkastの分析によれば、GatewayはTLSインスペクション済みのトラフィック 上で、プロトコル固有のヘッダー - MCP-Protocol-Version に加えて Mcp-Method と Mcp-Name - を検査してMCPリクエストを識別するため、 ドメインの許可リストを維持する必要はない。PPC Landは、この検出が Cloudflareのネットワークを日々横断する数百万のリクエストで観測された パターンから構築されたと報じている。

これを可能にしたのはプロトコル自身の進化だ。PPC Landは MCP-Protocol-Version ヘッダーの由来を、それを導入した仕様バージョン 2025-06-18 と、それを必須化した 2025-11-25 および 2026-07-28 の改訂に たどっている。Forkastは、2026-07-28 仕様がステートレスなリクエスト単位 モデルへ移行したことこそが、トラフィックをネットワーク上で確実に識別 可能にしたと付け加える。

Cloudflareがエージェントのトラフィックを独自のカテゴリーとして扱う 理由は行動面にある。発表はAIエージェントについてこう述べる。「彼らの 判断は非決定的であり、疲れることも昼食のために手を止めることもなく、 同じアクションを(あるいは同じツールの呼び出しを)無期限に続けることが できる」。

見えるものと見えないもの

この可視性には明確な限界があり、PPC Landはそれを率直に述べている。 「暗号化されたトラフィックは、Gatewayがこれらのヘッダーを読む前にTLS 復号を通過しなければならない。ローカルのstdioサーバー、ネットワーク外 の接続、Do Not Inspectとマークされたトラフィック、そしてGatewayを一度 も通らないリクエストは、完全に視野の外に残る」。stdio経由でローカル MCPサーバーを動かしている開発者は対象外であり、社内ネットワークの外に あるラップトップも同様だ。

PPC Landはまた、施行側の現在の制限にも触れている。MCP Portalsは パブリックインターネット経由で到達可能なアップストリームサーバーを 必要とし、プライベートDNSのサポートはまだ保留中だ。

狙いを定めた2つの問題

PPC Landは、このリリースが標的とする2つの障害モードを区別する。誰も 承認しておらず、セキュリティガバナンスの外で動いているサーバーである Shadow MCP と、承認済みサーバーへ、認可された経路を通らずに直接到達 するポータル迂回だ。Cloudflareの発表によれば、Traffic Sourceセレクター を使うと、ポリシーがPortal経由のリクエストと直接接続を区別できるため、 組織は直接のMCPトラフィックをブロックしつつ、Portalを介した種類を許可 できる。changelogによれば、新しいAIセキュリティダッシュボードはMCP リクエスト量、ユニークユーザー数、ユニークMCPサーバー数を報告する。

デフォルトでブロックする姿勢を急がせているのは、DEF CON 34 で発表 された 19,000+ のMCPサーバーの分析からForkastが引用する数字だ。82% がパストラバーサルにさらされ、34% がコマンドインジェクションに脆弱 で、OAuthをそもそも使っているのはわずか 8.5% だった。ロールアウトの 順序についてのCloudflareの言い方はこうだ。「まず可視性から始め、 それから存在すべきでない経路を閉じる」。

開発者にとっての意味

企業ユーザーが接続するMCPサーバーを運用しているなら、自分の トラフィックがいまやネットワークエッジで分類可能であり、一部の顧客が ポータル限定ポリシーへ移行すると想定すべきだ。認可されたポータル経由 で到達可能であること、そして現行の仕様を正しく話すことは、気配りでは なくデプロイ要件になりつつある。サーバーが MCP-Protocol-Version ヘッダーを正しく送っているか確認してほしい。あなたを検出させるのと 同じヘッダーが、あなたを正しく許可させるヘッダーでもある。

セキュリティチームやプラットフォームチームにいるなら、実践的な手順は Cloudflareが説明するとおりだ。検出を有効にし、ダッシュボードを見て 組織内にすでにどれだけのMCPトラフィックが存在するかを学び、それから ポリシーを書く。そして地図を信頼する前に盲点を知っておくこと - stdioサーバーとネットワーク外のマシンは、そこに決して現れない。

DEF CONの数字こそが、このリリースを重要にする文脈だ。公開サーバーの 3分の1がコマンドインジェクションに脆弱なエコシステムでは、「どの エージェントがどのツールと話すか」は可観測性の問題であることをやめ、 アクセス制御の問題になる。このセレクターはベータ版であり、名前は 変わるかもしれない - フィールド名への強い依存ではなく、ガバナンスの プロセスを今つくるべきだ。