Cloudflare：MCP検出がシャドーエージェントのトラフィックをセキュリティ上の判断へ変える仕組み

Cloudflareは、明白なサーバー名だけにとどまらずMCPトラフィックの検出機能を拡張し、従来はセキュリティチームが見落とし得た問題を浮き彫りにした。Cloudflareの仕組みを問う際、出発点は既知ドメインの一覧ではなく、プロトコル上の証拠となる。Gatewayは管理対象のHTTPトラフィックを検査し、MCP固有のパスやJSON-RPCメソッドを確認したうえで、承認済みのPortalトラフィックと直接接続を識別できる。

この区別が重要なのは、Model Context Protocol（MCP）がAIエージェントによる外部ツールの呼び出しや非公開データの取得を可能にするためだ。1本の接続で、ソースコード、顧客記録、クラウドの制御機能、メッセージングシステムに到達することもある。従業員がレビューを受けずにリモートサーバーを設定した場合、そこで生じるシャドーMCP活動は、アクションを実行できるエージェントを伴うシャドーITに似ている。

Cloudflareの答えは、発見機能と強制適用の経路を組み合わせるものだ。Gatewayがネットワークシグナルを提供し、MCP server portalsが承認済みサーバーを単一のエンドポイントの背後に集約する。Accessポリシーはアイデンティティとデバイス条件を統制し、データ損失防止（DLP）はツールのリクエストとレスポンスを検査できる。未解決の問題は、組織が十分なトラフィックをこれらの制御機構に通し、このモデルを信頼できるものにできるかどうかだ。

CloudflareにおけるMCP検出がプロトコルを読み取る仕組み

Cloudflareにとっての重要な変更は、宛先を推測する手法から、検査対象HTTPトラフィック内のMCPの振る舞いを認識する手法への移行である。

最も簡単な検出手法は、宛先ホスト名を見ることだ。管理者はGatewayログで、既知のMCPエンドポイントやmcpを含むホスト名を検索できる。この方法は、mcp.example.comのように名前から用途を明示するサービスを検出する。

第2のシグナルはリクエストURIから得られる。リモートサーバーは一般に、/mcp、/sse、/mcp/sseといったパスを公開する。Gatewayは、ホスト名自体が一般的に見える場合でも、記録されたリクエストからこうしたパターンを検索できる。

どちらの方法も初期インベントリの作成には有用だが、MCPを含むリクエストであることを証明するものではない。通常のアプリケーションも同じパスを利用できる。また、MCPサーバーは一般的なホスト名や目立たないAPIルートの背後に隠れることもある。

そこでCloudflareは、管理者にボディ検査を促している。MCPは、jsonrpc、method、paramsなどのフィールドを含む構造化リクエスト形式であるJSON-RPCを使ってメッセージをエンコードする。標準的なメソッド名は、認識可能なプロトコルレベルの証拠を生み出す。

例としては、initialize、tools/list、tools/call、resources/read、prompts/getがある。DLPプロファイルは、ドメインやパスから何も分からない場合でも、POSTボディからこれらの文字列を検索できる。CloudflareはMCP architectureで、複数の一般的なメソッドとプロトコルバージョンのフィールドを対象とする正規表現の例を公開している。

initializeメソッドは、MCPクライアントとサーバーの関係を開始するため、特に有用だ。クライアントはプロトコルバージョン、機能、名前、バージョンを宣言する。サーバーは自身の機能を返し、セッションを作成することがある。

ツール呼び出しは、より強い運用上のシグナルとなる。tools/callを含むリクエストは、エージェントが単にエンドポイントの存在を確認しているのではなく、機能の呼び出しを試みていることを示す。引数からは、ツールが扱うデータやアクションも明らかになる場合がある。

したがって、Cloudflareの仕組みは階層的だ。

• ホスト名パターンは、既知または明示的に命名されたMCPサーバーを特定する。

• URIパターンは、一般的なリモートMCPエンドポイントを特定する。

• JSON-RPCメソッドは、目立たないエンドポイント上のMCPの振る舞いを特定する。

• ユーザーとデバイスのフィールドは、その振る舞いを個人または管理対象システムに結び付ける。

• Gatewayアクションは、リクエストが許可、ブロック、または別の形で処理されたかを示す。

Cloudflareが文書化したワークフローでは、GraphQL Analytics APIのgatewayHttpRequestsAdaptiveGroupsデータセットを使用する。管理者は、ホスト、URI、ユーザー、アクション、マッチしたDLPプロファイルごとに結果をグループ化できる。同社のdetection tutorialによると、このデータセットは最大30日間の履歴クエリをサポートする。

これは、最も広い意味でのコンテンツ認識型脅威検出ではない。tools/callへの一致は、MCPツールが呼び出されたことを示す。しかし、そのツールが信頼できるか、その指示が悪意のあるものか、そのアクションがユーザーの意図に沿うかまでは判断しない。

それでも、プロトコル認識は重要な可視性の欠落を埋める。セキュリティチームは調査を始める前に、すべてのMCPベンダーやエンドポイントを把握している必要がなくなる。プロトコルそのものの特性を検索できるからだ。

ここに本稿の中心的な緊張関係がある。検出は直接MCPトラフィックを明らかにできるが、シグナルだけでは、どの接続を利用可能なままにすべきかは定まらない。管理者が正当な業務を止めずに管理対象外の経路をブロックするには、Cloudflareが統制された代替手段を提供する必要がある。

シャドーMCPはセキュリティチームをアクセスと導入の間に置く

直接的な圧力は、有用なエージェント接続と、機密システムへの未審査アクセスを切り分けなければならないセキュリティチームにかかる。

MCPは、AIアプリケーションがツールを発見し、リソースを読み取り、プロンプトを取得し、アクションを呼び出す方法を標準化する。このプロトコルはカスタム統合作業を減らすため、従業員や開発者が中央の導入プロジェクトなしにサーバーを追加することも容易になる。

このスピードは、よく知られたガバナンス上の問題を生む。ユーザーはMCPクライアントにリモートサーバーURLを設定し、OAuthなどの認証情報を使ってアクセスを許可できる。セキュリティチームは、承認済みソフトウェアカタログの外で行われた設定をまったく把握できない可能性がある。

リスクは、未承認のWebアプリケーションへのアクセスを超える。MCPサーバーはエージェントにツールを公開し、そのツールには重要な権限が伴い得る。統合の内容によっては、文書の検索、リポジトリの閲覧、サポート記録の参照、インフラの変更、メッセージの送信が可能になる。

正当なツールであっても、不適切なデータを受け取ることがある。従業員がエージェントに顧客問題の分析を依頼し、知らないうちに規制対象の情報を外部サーバーへ送信する可能性がある。侵害されたサーバーや欺瞞的なサーバーは、その後のエージェントの振る舞いを操作するよう設計された指示を返すこともある。

Cloudflareが管理対象外の接続をシャドーMCPと表現する理由はここにある。決定的な問題は、未知のサーバーがすべて敵対的かどうかではない。組織がそのサーバー、その運営者、要求される権限、そこを流れるデータをレビューしていないことだ。

Gatewayログは、この未知の活動をインベントリへ変えられる。管理者は、ユーザー、宛先ホスト、リクエスト量、ポリシーアクション、検出されたプロトコルメソッドを特定できる。その後、どのクライアントがトラフィックを生成したのか、どのような業務目的があるのかを調査できる。

このインベントリは、より慎重な強制適用も支援する。チームは初期一致をログに記録し、アクティブな宛先をレビューし、何かをブロックする前に各サーバーを分類できる。未承認のリモートツールへの直接トラフィックのような確信度の高いケースには、より厳格なポリシーを適用できる。

ただし、境界を定めるのは管理対象ネットワークのカバレッジだ。Gatewayは、関連するHTTPトラフィックを積極的にプロキシする必要がある。従業員が管理対象外のデバイス、別のネットワーク経路、または組織の制御外にあるクライアントを利用すれば、そのリクエストは同じログには表示されない。

暗号化されたトラフィックには、さらに条件が加わる。直接MCP接続のHTTPボディを検査するには、GatewayにTLS復号が必要だ。これがなければ、管理者は宛先ホスト名を確認できても、JSON-RPCメソッドやツール引数を見逃す可能性がある。

CloudflareはPortalトラフィックを異なる方法で処理する。Portalはクライアント接続を終端し、アップストリームサーバーへの新しい接続を作成する。このアーキテクチャにより、アカウント全体のTLS復号設定に依存せず、GatewayはルーティングされたPortalトラフィックを検査できる。

直接トラフィックには、この自動処理は適用されない。CloudflareのPortal documentationによれば、WARP管理下のデバイスを通じてエージェントが直接接続する場合、ボディ検査には通常のTLS復号設定が必要となる。

トラフィックを検査から除外する正当な理由もある。プライバシー要件、証明書ピンニングを行うアプリケーション、運用上の制約により、チームはDo Not Inspectポリシーを作成することがある。こうしたポリシーは優先され、該当するMCP活動がDLP分析の対象外となる可能性がある。

これらの制約が検出を無用にするわけではない。結果として得られるダッシュボードが実際に何を意味するのかを定めるものだ。レポートが示すのは、検査済みかつ管理対象の経路で可視化されたMCP類似の活動である。企業全体に存在するすべてのエージェント接続の完全な調査ではない。

この区別はインシデント対応に反映されるべきだ。検出された接続には調査の価値があるが、レポートが空であることはシャドーMCPが存在しない証拠ではない。セキュリティチームには、ネットワーク検出に加えて、エンドポイントのカバレッジ、アイデンティティデータ、クライアント設定の制御が必要だ。

真の競争はPortalアクセスと直接接続の間にある

Cloudflareのセキュリティモデルが強制適用可能になるのは、管理対象経路で承認済みのPortalアクセスが直接サーバーURLに置き換わるときだけである。

MCP server portalは、複数の承認済みサーバーを単一のHTTPエンドポイントの背後に集約する。ユーザーはMCPクライアントでそのエンドポイントを設定し、Cloudflare Accessを通じて認証を受け、ポリシーで許可されたサーバーとツールだけを利用する。

Portalは、直接接続では個々の統合に分散している複数の役割を担う。ユーザーの識別、Accessルールの評価、アップストリーム認証の管理、承認済みツールの公開、リクエストのログ記録だ。管理者は、すべての従業員に個別のエンドポイント一覧を維持させることなく、サーバーを整理できる。

Accessポリシーでは、アイデンティティグループ、場所、デバイスのポスチャを利用できる。財務向けポータルでは、財務部門の従業員に選択した読み取り専用ツールを公開できる。エンジニアリング向けポータルでは、管理対象の企業デバイスからのみ追加アクションを許可できる。

管理者は個別のツールやプロンプトを非表示にすることもできる。サーバーを承認しても、そこで公開されるすべての機能を承認する必要はないため、これは重要だ。リポジトリにアクセスできるサーバーであっても、検索と読み取り操作は公開しつつ、書き込み操作は利用不可のままにできる。

CloudflareのPortal設計は、認証不要のアップストリームサーバーとOAuthで保護されたサーバーをサポートする。ユーザーはアップストリームサービスに個別に認証でき、マシンツーマシンのワークフローの一部ではAccessサービス トークンを利用できる。Portalはその後、ツール呼び出しをプロキシする際に適切な認証情報を付加する。

Gatewayルーティングを有効にすると、リアルタイム呼び出しはPortalからGatewayを経由し、アップストリームサーバーに到達する。Gatewayはリクエストをログに記録し、HTTPポリシーおよびDLPポリシーを適用できる。エグレス制御により、これらのリクエストに予測可能な送信元アドレスを与えることもできる。

これにより、実用的な許可・ブロックのパターンが生まれる。セキュリティチームは従業員に承認済みのPortalエンドポイントを提供し、アップストリームMCPサーバーへの直接接続を停止するGatewayルールを作成する。Portal経路は利用可能なまま、統制されていない代替経路は制限される。

ポリシーは適切な宛先を対象にしなければならない。Cloudflareによると、PortalトラフィックのDLPルールは、単にPortalドメインに一致させるのではなく、アップストリームMCPサーバーのホスト名に一致させるべきだ。Portalはクライアント向けの入口だが、Gatewayが評価するのは実際のサーバーへ向かう再オリジネーションされたリクエストである。

この構成は、単なるディレクトリというよりアプリケーションゲートウェイに近い。アイデンティティ、ツール選択、ログ記録、データ制御が交差するチョークポイントを提供する。このチョークポイントこそが、発見をガバナンスへと変える。

しかし、直接URLは依然として中心的な弱点である。Cloudflareは、Portalからサーバーを非表示にしても、ユーザーが元のアドレスへ接続することは防げないと警告している。アップストリームサーバーが公開アクセス可能なままであれば、Portalのポリシーだけでは迂回を阻止できない。

そのため組織には、Portalのインターフェース外に強制力を持つ制御が必要となる。ホスト名を管理している場合はAccessでサーバーを保護でき、既知のエグレスアドレスに受信トラフィックを制限することも、Gatewayで直接の宛先をブロックすることもできる。サードパーティーサービスでは、導入モデルがサポートする制御を利用する必要がある。

選択肢はCloudflareか別のセキュリティベンダーか、という話ではない。主な対立軸は、統制されたPortalアクセスと、ユーザーが設定する直接接続である。主要機能はすべて、この競争に対応するためにある。

Portalログは承認済みのアクティビティを特定する。Gatewayの検出機能は、承認済みルートの外側にあるトラフィックを探す。Accessは誰がPortalを利用できるかを定める。DLPは管理対象パスを通過するデータを評価する。ネットワークポリシーは直接ルートを閉じようとする。

このモデルは、強制措置の開始後にも開発者に利用可能な行き先を提供する。MCPを一律に禁止すれば、実験は公式チャネルの外へ押し出される。厳選されたPortalにより、チームは承認済みツールを利用可能な状態に保ちながら、追加サーバーのセキュリティレビューを実施できる。

結果は運用規律に左右される。承認済みサーバーカタログの所有者、ツール権限のレビュー、Accessポリシーの維持、新たに検出された宛先への対応を担う担当者が必要だ。中央集約は制御の分散を減らすが、こうした判断そのものをなくすわけではない。

プロトコルのヒューリスティクスは網羅性を生むが、確実性は生まない

Cloudflareは強力なMCP指標を識別できるが、それらの指標は接続が安全か、悪意あるものか、適切に統制されているかを証明するものではない。

検出パターンはヒューリスティクスである。"method":"tools/call" を含む本文はMCPによく似ているが、別のJSON-RPCアプリケーションが同じメソッド名を使う可能性もある。独自実装のMCPでは、厳密に記述された正規表現の範囲外となるフォーマットを生成する場合もある。

空白文字の許容範囲は、この問題を示している。例示されている式は、JSONフィールドの周囲に限られた空白を許可する。各パターンが1つのフィールドを対象とするなら、フィールド順の変更も検出できるはずだが、別のシリアライズ形式やエスケープ処理はマッチングを複雑にし得る。

暗号化されたトラフィックや未サポートのトラフィックでは、より大きなギャップが生まれる。Gatewayが復号しない限り、DLPは直接HTTPSの本文を検査できない。標準入出力を介して通信するローカルMCPサーバーは、そもそもHTTPゲートウェイを通過しない。

Cloudflareの現行設計において、最も重要なリモートトランスポートはStreamable HTTPである。MCP transport specification は、JSON-RPCメッセージと任意のセッション識別子を運ぶHTTPリクエストを定義している。こうした規則的な構造は、Gatewayによるプロトコル認識を支援する。

CloudflareのルーティングされたPortalパスはStreamable HTTPをサポートする。アップストリームサーバーが旧来のServer-Sent Eventsトランスポートのみをサポートする場合、そのサーバーではGatewayルーティングは失敗する。ルーティングが有効な場合、PortalはStreamable HTTPを試行するが、アップストリームサービス側もこれをサポートしていなければならない。

バックグラウンド同期も例外の一つである。Portalは定期的にアップストリームサーバーからツールとプロンプトを取得するが、Cloudflareによると、これらの同期リクエストはGatewayを通過しない。文書化されたルーティング検査を受けるのは、リアルタイムのユーザーツール呼び出しだけである。

DLPのカバレッジにも製品固有の制限がある。Cloudflareによると、AIプロンプトプロファイルは異なるAPIパスと形式を想定しているため、MCP Portalトラフィックには適用されない。管理者は標準DLPプロファイルを使用する必要がある。

Do Not InspectルールはPortalトラフィックにも引き続き有効である。Portalルーティングでは自動復号が可能だが、明示的な除外設定によりペイロード検査は行われなくなる。したがって、広範な例外は承認済みアップストリームサーバーに対するDLP保護を外す可能性がある。

アイデンティティポリシーにも注意点がある。Cloudflareは、Portal経由で承認されたサーバーについては、独立したMFA、目的の正当化、一時認証は強制されないと文書化している。メール、グループ、国、デバイスポスチャーのセレクターは引き続き適用される。

Portalは実際のポリシーパス以上に制約が強く見えることがあるため、こうした制限は重要である。管理者はサーバーレベルの要件を割り当て、ユーザーがPortalの認可時にそれを求められると想定するかもしれない。Cloudflareのドキュメントでは、複数のステップアップ制御がそのようには機能しないとされている。

セキュリティチームは、プロトコル検出とセマンティックなセキュリティも分けて考えるべきだ。リクエストは承認済みPortalを通り、DLPルールに一致しなくても、安全でない操作を引き起こす可能性がある。DLPが探すのは定義済みのデータパターンであり、プロジェクトの削除がユーザーの意図に合致するかどうかではない。

ツールインジェクションは関連する問題をもたらす。アップストリームサーバーは、エージェントの次の判断に影響を与えるコンテンツを返す可能性がある。ネットワーク検査は機密文字列を記録またはブロックできるが、正当なコンテンツに埋め込まれた操作的な指示を必ずしも認識できるわけではない。

逆もまた真である。シャドーMCP接続が自動的にインシデントになるわけではない。開発者が無害な公開データソースをテストしている可能性もある。接続は統制されていないままだが、事業上およびセキュリティ上の影響を判断するには文脈が必要になる。

したがって、誤検知と見逃しは運用モデルに組み込むべきである。チームはホスト名とURIの一致を手がかりとして扱い、その後、本文シグナル、ユーザー属性、クライアントデータ、サーバーレビューを使って判断すべきだ。影響の大きいブロックルールは、汎用的なパスマッチだけに依存すべきではない。

段階的な展開により、混乱を抑えられる。管理者はログ記録から始め、想定されるPortalトラフィックを確立し、一般的な直接宛先を特定できる。その後、新しいサーバーの承認プロセスを整えつつ、確信度の高いシャドー接続をブロックできる。

最も強力な形態は、ネットワーク制御とエンドポイント制御を組み合わせることだ。Gatewayは管理対象パスを横断するリモートトラフィックを把握する。エンドポイント管理は、ユーザーがインストールできるクライアントと設定を制御できる。Accessとアップストリーム制限は、承認済みルートが存在した後の迂回をより困難にする。

Cloudflareは、このアーキテクチャを構成する要素を提供している。ただし、それを設計する必要性までなくしたわけではない。

CloudflareのMCPモデルが機能するかを示す3つのシグナル

次の試験は、企業がMCPの可視性を一貫したルーティング、意味のあるブロック、測定可能なツールガバナンスへ転換できるかどうかである。

第1のシグナルは、検出されたトラフィックのうち承認済みPortalドメインを通過する割合だ。初期のGateway検索では、既知のサービス、実験、誤検知が混在して見つかる可能性が高い。承認済みの代替手段が利用可能になった後に直接MCPアクティビティが減少すれば、このモデルの信頼性は高まる。

セキュリティチームは、これを単なるブロック数ではなく、ルーティングの成果として測定すべきである。ブロックされたリクエスト数が増えればポリシーが機能していることを示すかもしれないが、ユーザーが承認済みルートの迂回を試み続けていることを示す場合もある。移行の成功とは、正当なアクティビティがPortalを通じて継続することである。

第2のシグナルは、ツールおよびデータレベルでのポリシー品質である。承認済みのすべてのサーバーからすべての機能を公開するPortalは、アクセスを中央集約するだけで、ほとんど制約を適用しない。より強力な導入では、ツールを厳選し、アイデンティティ条件を用い、リクエストとレスポンスの両方にDLPプロファイルを適用する。

CloudflareのGatewayは、送信コンテンツが標準DLPプロファイルに一致した場合、ツールリクエストをブロックできる。また、アップストリームサーバーが一致する機密データを返した場合には、レスポンスをブロックできる。MCPクライアントは、保護されたコンテンツの代わりにエラーを受け取る。

組織が実際のワークフローに合わせてこれらの制御を調整すると、その価値はさらに高まる。認証情報、財務情報、顧客識別子、独自文書には、それぞれ異なるリスクがある。すべてをブロックするポリシーはユーザーを苛立たせ、まったく発火しないポリシーはほとんど保護を提供しない。

セキュリティチームは、ブロックされたツールメソッド、一致したデータカテゴリ、影響を受けたサーバー、ユーザーの結果を追跡すべきである。また、エージェントがブロックされたリクエストを繰り返し再試行していないかも確認すべきだ。繰り返される試行は、不適切なクライアント動作や、より安全な承認済み設計が必要なワークフローを示す可能性がある。

第3のシグナルは、CloudflareとMCPエコシステムが既知のカバレッジギャップをどれほど迅速に埋めるかである。Streamable HTTPの採用が進めば、Gatewayルーティングを利用できないアップストリームサーバーの数は減るはずだ。より優れたエンドポイント制御により、ローカルおよび管理対象外の設定に対する可視性も向上する可能性がある。

プロトコルの変更も重要になる。現行のJSON-RPCメソッドを中心に構築された検出パターンは、仕様の進化に追随しなければならない。安定したヘッダーや他の標準化されたトランスポートシグナルは分類を容易にする可能性があるが、セキュリティチームはすべてのクライアントが新しいフィールドを直ちに採用するとは考えるべきではない。

中心的な対立軸を変えずとも、競合各社の動きは別の手がかりを与える。セキュアWebゲートウェイやエンドポイントベンダーは、独自のMCP分類、サーバーインベントリ、エージェント制御を追加する可能性が高い。その圧力は検出手法を改善し、ネットワークのみのアプローチが不十分な領域を明らかにし得る。

Cloudflareの強みはアーキテクチャ統合にある。Portal、Access、Gateway、DLP、エグレス、アプリケーション制御を、1つのポリシーパスに参加させることができる。課題は、顧客が意味のある迂回経路を残さずにこれらのコンポーネントを設定できることを証明する点にある。

したがってCloudflareの「どのように」は、単一の検出器というよりフィードバックループの話である。直接MCPトラフィックを発見し、調査し、必要なサーバーを承認し、それらをPortal経由にルーティングし、管理されていないパスをブロックする。そして、ユーザーが新しいツールを採用するたびにこれを繰り返す。

このモデルを検討する組織は、1つの実践的な問いから始めるべきだ。自社のセキュリティチームは、現在どの管理対象ネットワークパスとエージェントクライアントを実際に観測できるのか。

そこから、MCPシグナルをインベントリ化し、承認済みPortalトラフィックと比較し、十分な確信をもって強制措置を適用できる場所を選べる。目標は、すべてのMCP接続を危険と分類することではない。エージェントが、組織が認証、検査、監査できるルートを通じて機密ツールに到達するようにすることである。