Cloudflare Gateway 怎麼偵測 MCP？用 Is MCP 建立封鎖規則

先分清楚三個功能邊界#

Cloudflare 文件把 selector 標成 Beta，API 表達式是 experimental.is_mcp == true。Beta selector 可能在正式版前變更，所以不要把它當成永遠不變的 policy schema；在內部 runbook 記下查核日期與實際 expression。

如果你還在決定某個工作流是否真的需要 MCP，可以先看 接 MCP 前的能力盤點與最小 scope。本文接續的是「已經有流量後，如何從 Gateway 層觀察與收斂」這個不同問題。

先讓測試流量出現在 Gateway#

Gateway 只能觀察實際經過它的網路流量。正式建立封鎖規則前，先用一個可控的測試 client 和測試 MCP server 做 baseline：

1. 確認測試裝置或服務的 HTTP 流量確實經過 Cloudflare Gateway。
2. 發送一個不含敏感資料的 MCP 初始化或工具查詢請求。
3. 到 Insights & Logs → Dashboards 查看 AI security report 是否出現 MCP request。
4. 記下偵測到的 server、來源使用者與時間，再和 client 端 log 對照。

如果 Gateway 報表沒有資料，先查路由、代理設定與流量來源，不要直接把 Is MCP 規則改成全網路封鎖。這一步的目的是確認「偵測功能沒有資料」和「MCP 流量沒有經過 Gateway」不是同一件事。

用 Is MCP 做最小政策#

Cloudflare 的官方範例是：如果請求被辨識為 MCP，而且來源不是核准的 MCP portal，就封鎖。可以先把這個邏輯拆成可審查的條件：

實際在 dashboard 建立 policy 時，先從 Is MCP selector 開始，再加入來源、使用者或目的地條件。不要一開始只寫「所有 MCP 都封鎖」，因為你可能同時需要保留經過核准的內部 portal、測試環境或服務帳號流量。

建議採用以下 rollout：

1. 觀察：先用 report 和 logs 建立已知 server、使用者與來源清單。
2. 縮小：把核准的 portal、測試來源與服務身份寫成明確條件。
3. 限制：對不符合條件的 MCP 流量先套用隔離或封鎖。
4. 回歸：測試核准來源可以使用工具，未核准來源確實收到預期的阻擋或隔離結果。

這樣做能保留一條回復路徑。若 policy expression 或偵測結果在 Beta 期間改變，你仍有測試請求、來源清單與 dashboard 紀錄可以重新比對。

AI security report 要看哪些欄位？#

Cloudflare 公告列出的報表資訊包括：

• MCP request 的總量。
• 觀察到的 unique users 與 unique MCP servers。
• unique MCP servers 隨時間變化的 time series。
• 目前針對 MCP 流量的 Gateway policies 摘要。

這些欄位比較適合拿來做盤點與異常 triage，而不是直接當成「允許清單」。例如某個 server 的請求量突然增加，只能說它值得回查來源、使用者、變更時間與實際工具操作；仍要回到 server repository、OAuth scope、部署環境與 audit log 做核准判斷。

若你的團隊已經使用 Cloudflare 的套件註冊表 policy，也可以參考 Gateway 套件註冊表安全設定。兩篇文章都在談 Gateway 的可觀測與政策邊界，但一篇處理 package registry，本文則處理 MCP traffic。

上線前的驗證清單#

把以下項目放進 policy 的 PR 或變更紀錄：

1. 哪些裝置、代理或服務的流量會經過 Gateway。
2. 測試時實際被辨識的 MCP server 與來源。
3. Is MCP selector 的 Beta 狀態與查核日期。
4. 核准 portal、測試來源與服務帳號的例外條件。
5. 未核准流量的動作是 block 還是 isolate，以及回復方式。
6. 一次核准來源和一次未核准來源的實際測試結果。

MCP detection 的價值在於把原本散落在各台 client 的流量，拉到可觀察的網路邊界。 但它不會替你判斷 server 是否安全；先建立流量基線，再用小範圍的 Beta policy 收斂來源，才不會把可見度誤當成完成治理。

常見問題#