JA EN
shiichan

まさかの MCP 通信、Cloudflare がヘッダーひとつで見抜けるようになった！

Cloudflare Blog ★★★ Markdown で見る
#cloudflare#security#ai

こんにちは、しぃちゃんだよ！ 今日は Cloudflare が、AI エージェントが使う MCP 通信をきちんと見つけて制御できるようにする新機能をまとめて出したから、技術寄りだけどしっかり紹介しちゃうね！

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare Blog で発表されたのは、Cloudflare One 上で MCP(Model Context Protocol)のトラフィックを識別して、AI エージェントの不正な使われ方を防ぐための一連の新機能だよ。可視化のためのダッシュボードや、ポリシーで使える新しいセレクタなどがまとめて追加されたの。

今までどうだったの？

これまで MCP のトラフィックを見分けようとすると、ホスト名やパスに「mcp」が含まれているかどうかで判定するのが一般的だったんだって。原文によると、この方法は「実装は簡単だけど精度が低い」んだそう。

しかも AI エージェントが絡むと事情はもっとやっかいで、従来の権限モデルは「人間が判断して、人間のスピードで動く」ことを前提にしていたの。でも AI エージェントは判断が非決定論的なうえに、疲れることなく同じ操作を延々と繰り返せちゃう。だから誤った判断が数千回分のおかしな操作に膨れ上がるまで、誰も気付けないリスクがある、と原文は指摘しているよ。

これで何が変わるの？

新しく追加されたのは、大きく 3 つだよ。

  • MCP 検出セレクタ: experimental.is_mcp == true というブール値のセレクタが、すべての Cloudflare Zero Trust ユーザーに使えるようになった。TLS 検査済みのリクエストから MCP-Protocol-Version ヘッダーを検出したものに、許可・ブロックのポリシーをかけられる
  • MCP 専用ダッシュボード: 期間内の MCP リクエスト総数・ユニークユーザー数・ユニークサーバー数、サーバーごとのリクエスト推移、Portal 経由か直接接続かの内訳、Portal を経由していない「シャドウ MCP サーバー」のランキングなどが見られる
  • トラフィックソースセレクタ: MCP Portal 経由のトラフィックには mcp_portal というトラフィックソースが付くようになって、ポリシーの中で区別できる

たとえば次のようなルールを書けば、Portal を経由しない MCP 通信をまるごとブロックできるよ。

experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block

これで、組織が把握していないサーバーに直接つながる「シャドウ MCP」と、承認済みサーバーだけど Portal の Access ポリシー・ツール制御・DLP・監査ログを回避してしまう「Portal バイパス」を、それぞれ狙って対処できるようになったの。

深く潜ってみよう

検出の核になっているのは MCP-Protocol-Version という HTTP ヘッダーだよ。MCP の 2025-11-25 仕様ではすべての HTTP リクエストで必須、2026-07-28 仕様ではすべての POST リクエストで必須になっていて、これを主な手がかりに使っているみたい。実行される操作を示す Mcp-Method や、呼び出すツール名を示す Mcp-Name ヘッダーも補助的に使われるよ。

原文では、MCP の制御ポイントを 3 つの層に整理していて、それぞれに得意・不得意があるの。

  • クライアント内部: いちばん早い段階で止められて、ローカルの stdio MCP にも対応できる。ただし複数クライアントをまたいだ標準化が難しくて、組織として全体を把握しきれない
  • ネットワーク境界(Secure Web Gateway): いちばん広い範囲の MCP を検出できて、社外に持ち出されたトラフィックも見える。ただしローカルの stdio 呼び出しまでは見えない
  • MCP サーバーの実行直前: 実行時の文脈がいちばん豊富で、ツールが動く直前に止められる最後のチャンス。ただしサーバー側の実装が必須

制限事項もはっきり書かれていて、TLS 復号化を通さないと検出できないこと、ローカルの stdio サーバー・社外ネットワークでの接続・「検査対象外」に設定したトラフィックは対象外になること、そして初期化リクエストには MCP-Protocol-Version ヘッダーが付かない古いクライアントもあるから、最初のリクエストでは検出しきれない場合がある、という点が挙げられているよ。

MCP Portal 自体の機能も広がっていて、これまでの Dynamic Client Registration に加えて、クライアント ID・シークレット・コールバック URL・各種エンドポイントを手動で登録する方式にも対応したの。またプライベートネットワーク上のサーバーを Portal 経由でつなげる機能も開発中とのこと。

あわせて Cloudflare Agents SDK も v0.20.0 にアップデートされていて、MCP の 2026-07-28 仕様(ステートレスモデル)に対応したよ。クライアントは server/discover で新しいプロトコルに対応しているか確認して、対応していなければ従来の initialize ハンドシェイクにフォールバックする仕組みになっているの。

導入の流れとしては、まず Gateway を通る MCP トラフィックを可視化して承認済みサーバーと突き合わせ、次に承認済みサーバーを Portal の背後に移行し、最後に Gateway のポリシーで直接接続をブロックする、という 3 段階が推奨されているよ。

まとめ

  • MCP-Protocol-Version ヘッダーを使って、ホスト名頼みより正確に MCP 通信を検出できるようになった
  • experimental.is_mcp == true セレクタと専用ダッシュボードで、MCP トラフィックの可視化とポリシー適用ができる
  • mcp_portal トラフィックソースで「シャドウ MCP」と「Portal バイパス」を区別して制御できる
  • 制御ポイントはクライアント内部・ネットワーク境界・サーバー実行前の 3 層に整理されている
  • TLS 復号化なしの通信やローカル stdio サーバーは検出対象外という制限もある

社内で AI エージェントに MCP サーバーをどんどんつなげ始めているセキュリティ担当・プラットフォームチームには、見えていなかった通信を洗い出す手がかりになる発表だと思うよ！

関連記事