AICloudflare OneMCPSASEZero Trust產品新聞

Cloudflare 如何偵測 MCP 流量並協助保護其安全

AJ Gerstenhaber和Kenny Johnson

閱讀時間：14 分鐘

這篇文章亦提供 English和简体中文.

大多數公司在設計資源存取權限時，是以人類使用者為前提的。資深工程師或許能夠部署至正式環境、查詢敏感資料庫，或撤銷其他使用者的存取權。這些權限伴隨著風險，但傳統上這類風險受到兩個假設的約束：工程師會運用人類的判斷力行事，且工程師每天能執行的操作量有上限。

當工程師發現意外結果時，通常會暫停並重新審視。任何人一天之內能點擊、輸入和審閱的內容終究有限。AI 智慧體的引入同時打破了這兩個限制。其決策是非確定性的，且可在不疲倦、不需休息的情況下無限次地執行相同動作（或呼叫相同工具）。一個看似合理卻有誤的決策，可能在人類察覺之前已造成數千次錯誤操作。

今天，我們宣布推出全新的 Cloudflare One 功能，可識別受檢查的 MCP 流量、顯示哪些使用者和伺服器產生了該流量，並控制受管理網路路徑上的直接連線。搭配 MCP 伺服器 Portal，這些控制機制可協助管理員判斷智慧體是正在使用已核准的路徑，還是以某種方式繞過了它。

Model Context Protocol（MCP）伺服器為智慧體提供了一種通用方式，以探索並呼叫由第三方 SaaS 產品、內部應用程式和 API 所支援的工具。底層的存取權限設計或許並不陌生；改變的是由誰做出每個決策，以及錯誤決策可以蔓延得多快。

將智慧體連接至其中一個工具，可能只需要一行設定。員工可以將 Claude Code、Codex、Cursor、OpenCode、VS Code 或任何 AI 工具直接指向某個 MCP 伺服器，而不確認該伺服器是否已獲核准。由此產生的流量沒有明顯特徵。Model Context Protocol 不使用固定的主機名稱，也不要求路徑中包含 /mcp，因此直接連線看起來與其他任何 HTTPS API 呼叫無異。

為說明這些控制機制如何相互配合，我們將從工具呼叫的結構及其揭露的資訊開始。接著比較資安團隊可介入的三個位置：用戶端內部、網路層，以及 MCP 伺服器端。在此基礎上，我們將說明 Cloudflare Gateway 如何利用通訊協定訊號找出影子 MCP 流量，並強制執行僅限 MCP Portal 存取受信任 MCP 伺服器的策略。

MCP 工具呼叫的結構

同一個 MCP 工具呼叫在通過系統時會呈現三種形式。在用戶端內部，它是呼叫某個工具並傳入一組引數的決策。在網路層，它是一個攜帶 JSON-RPC 訊息的 HTTP 交易。在伺服器端，它成為對工具處理常式的呼叫，可能讀取資料、變更狀態或完成其他操作。

假設有一個智慧體想查詢奧斯丁的天氣。一個遠端 MCP 請求看起來如下：

POST /mcp HTTP/1.1
Host: tools.example.com
Authorization: Bearer <access-token>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weather

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "Austin"
    }
  }
}

這個請求中包含幾個重要訊號。主機名稱和路徑識別了目標。授權標頭攜帶了當伺服器要求驗證時用於驗證呼叫者的憑證。標頭 MCP-Protocol-Version 識別通訊協定版本，而 Mcp-Method 和 Mcp-Name 在新的無狀態通訊協定中揭露了操作和工具名稱。JSON-RPC 信封重複了方法、賦予請求一個用戶端可與回應進行比對的 id，並在 params 中攜帶工具引數。

引數是最敏感的部分。其中可能包含搜尋查詢、原始程式碼、客戶資料，或觸發建立工單、變更基礎架構等動作的指令。工具名稱說明了智慧體打算呼叫什麼；引數則說明了它將傳送哪些敏感性資料，以及它希望伺服器執行什麼動作。

若呼叫成功，伺服器會回傳一個包含相同 ID 和工具結果的 JSON-RPC 回應。該回應也可能包含敏感性資料。在執行前對請求進行檢查可阻止不安全的操作，而對回應進行檢查和記錄則能顯示工具向智慧體回傳了什麼內容。

控制 MCP 請求的三個位置

請求給予資安團隊三個觀察或控制呼叫的位置。

MCP 用戶端內部

用戶端掛鉤可在模型選取工具之後、用戶端序列化請求之前執行。在此階段，它可以在不解密網路流量的情況下看到目標伺服器、工具名稱和引數。

這是請求鏈中可介入控制的最早階段。用戶端可以拒絕不在允許清單上的伺服器、要求使用者確認敏感操作，或在資料離開裝置前從引數中移除敏感內容。它也能涵蓋本機 stdio（即本機）MCP 伺服器，這類伺服器不會產生任何網路流量。

這帶來了標準化的挑戰。若要讓資安團隊從中獲益，他們需要在員工使用的每個用戶端上重新部署相同的控制機制。當組織同時管理用戶端和裝置時，用戶端側控制的效果最佳，但單一用戶端的遙測資料永遠無法完整呈現 MCP 使用情況。

裝置的網路邊界

安全網路閘道可在請求離開用戶端後對 HTTP 請求進行觀察。透過 TLS 解密，它可以將請求與使用者和裝置關聯，檢查目標和通訊協定標頭，並在不依賴特定 MCP 用戶端的情況下套用原則。

網路層具有最寬廣的視野，可偵測受管理路徑上的遠端 MCP 流量。它可以識別對已核准 Portal 以外伺服器的直接連線，並在請求抵達目標前加以封鎖。在支援資料外洩防護掃描的情況下，代理也可以檢查 JSON-RPC 方法和引數中是否包含敏感性資料。然而，代理無法看到本機 stdio 呼叫或離線流量。

MCP 伺服器呼叫工具之前

伺服器具有最豐富的執行環境。它已驗證呼叫者身分、解析 MCP 訊息、將 get_weather 解析至對應的處理常式，並根據工具的輸入結構描述驗證所提供的引數。這是工具執行前最後一個可以拒絕請求的位置。

Agents SDK 處理常式或類似的伺服器中介軟體可針對特定工具授權呼叫者、套用限速、檢查引數並記錄結果。伺服器應在呼叫處理常式之前執行這些檢查，尤其是對於會寫入資料或觸發外部動作的工具而言。僅在執行後才進行記錄能說明發生了什麼，但無法預防。

Cloudflare 的 WriteGuard 在我們的內部 MCP 伺服器上採用了此模式。每個工具都有風險等級和啟用或停用狀態。WriteGuard 可以讓讀取操作直接通過、對允許的寫入操作新增智慧體歸屬資訊和稽核事件，或在關鍵操作的處理常式執行前加以封鎖。由於控制機制位於伺服器端，終端使用者無法透過切換用戶端或停用本機掛鉤來繞過它。

雖然伺服器端控制只能保護實作了該控制的伺服器，但用戶端和伺服器具有最佳的請求深度，而網路則能看到最廣泛的遠端連線集合。三者搭配使用，可在敏感性資料離開裝置前加以阻止、找出未受管理的 MCP 流量，並在工具執行前拒絕未授權的操作。

網路控制點的涵蓋範圍最廣，但首先必須能夠區分 MCP 流量與一般 HTTPS 流量、使用者必須正在執行代理，而且 MCP 伺服器（或 Portal）也必須能驗證連線中確實使用了代理。

Cloudflare One 提供了這條鏈路中的網路環節。Cloudflare One 用戶端將受管理裝置的流量透過 Gateway 傳送。Gateway 可以在通訊協定層對 MCP 請求進行分類，並區分流量是源自 MCP Portal 還是繞過了已核准的控制機制。管理員隨後可以對未遵循已核准路徑的連線進行報告或封鎖。這一切都從可靠地識別請求開始。

URL 無法告訴您請求是否使用了 MCP

我們最初尋找 MCP 流量的方式是使用 GraphQL Analytics API，在 Gateway HTTP 記錄中搜尋包含 mcp 的主機名稱及常見路徑（如 /mcp 或 /sse）。我們的 MCP 流量偵測教學課程中包含了相關查詢，並說明了如何為 MCP JSON-RPC 方法（例如請求主體中的 initialize、tools/call 和 resources/read）建立資料丟失預防 (DLP) 規則模式。

這些訊號對於尋找舊版用戶端的流量及提供歷史可見性仍然有用，但它們非常基礎——會漏掉位於普通 URL（如 https://tools.example.com/api）上的 MCP 伺服器，而這種情況並不罕見。

同時，它們也可能誤判與 MCP 無關、但主機名稱或路徑中恰好包含 mcp 的服務（可能性雖低，但我們確實遇到過）。對於符合規範的 Streamable HTTP 用戶端，通訊協定標頭是更具體的訊號。MCP 2025-11-25 規範規定，用戶端在初始化後的每個 HTTP 請求中必須包含 MCP-Protocol-Version。MCP 2026-07-28 規範更進一步，要求在每個 POST 請求中都包含該標頭。

這並不代表此標頭是完整的偵測器。舊版用戶端的初始請求可能不包含它，2025-06-18 之前的通訊協定版本也未定義它，而本機 stdio、自訂傳輸或不符合規範的流量可能從未攜帶它。標頭存在是 MCP 流量的強力正向指標；但不存在該標頭也並不能證明該請求不是 MCP。

通訊協定在網路層變得越來越容易識別

舊版 MCP 流程以不包含 MCP-Protocol-Version HTTP 標頭的 initialize 請求開始，因此網路控制機制可能無法僅憑標頭對先前未知端點的第一個請求進行分類。該訊號在用戶端和伺服器完成初始化後才會出現。

後續的工具呼叫看起來如下：

POST /api HTTP/1.1
Host: tools.example.com
Content-Type: application/json
MCP-Protocol-Version: 2025-11-25

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_weather"}}

MCP 2026-07-28 規範大幅改變了此模式。核心通訊協定採用無狀態設計，完全移除了 initialize 交握，並在每個請求中附上通訊協定版本和操作資訊：

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"}}

Mcp-Method 和 Mcp-Name 標頭讓一般的 HTTP 基礎架構無需解析本文即可識別操作。負載平衡器可以路由請求，速率限制器可以區分 tools/list 和 tools/call，而資安產品在每個請求中也能獲得更多資訊。

這些通訊協定訊號為 Cloudflare Gateway 提供了具體的評估依據，而無需仰賴一份「看起來像 MCP」的 URL 清單。

影子 MCP 與核准路徑繞過是兩個不同的問題

一旦 Gateway 能夠識別 MCP 流量，您就可以評估特定連線對您的安全態勢意味著什麼。

影子 MCP 是指連線至組織未核准之伺服器的情況。員工在某個程式碼存放庫、產品指南或同事訊息中找到該伺服器，並直接將其加入自己的 MCP 用戶端。資安團隊完全不知道該伺服器開放了哪些工具，也不知道員工向其傳送了哪些資料。

Portal 繞過則不同：它始於一個組織已核准並置於 MCP Portal 後方的伺服器，但員工直接連線至其上游 URL，跳過了 Portal 的 Access 原則、精選工具目錄、資料外洩防護和工具層級的稽核記錄。

Gateway 是在受管理網路路徑上控制影子 MCP 的主要機制；它識別經 TLS 檢查的 MCP 流量、顯示目標和使用者，並可套用原則。Portal 繞過則需要該網路控制機制，加上一個能夠拒絕直接請求的來源——無論是 Access 原則、來源 IP 限制，還是由 MCP 伺服器本身發起的企業授權機制。

在 Gateway 中偵測 MCP 流量

對於已採用帶有 TLS 檢查的 Cloudflare Gateway 的客戶，我們正在新增一個偵測啟發式方法，為每個受檢查的請求回答一個簡單的問題：這是 MCP 流量嗎？

對於基於工作階段的 Streamable HTTP 連線，MCP 用戶端在初始化後傳送 MCP-Protocol-Version 標頭。Gateway 在每個經 TLS 檢查的請求上檢查該標頭並據此對流量進行分類，使用的偵測機制是從我們在 Cloudflare 網路上每天處理的數百萬個請求中觀察到的模式建立而成的。此分類可識別 MCP 協商和代理至主機名稱的行為，而無需事先知悉特定主機或 URL。

即日起，所有 Cloudflare Zero Trust 客戶都可以在 Gateway HTTP 記錄中看到 MCP 流量的標示，並可使用新的 Gateway 選擇器明確封鎖或允許該流量：

experimental.is_mcp == true

此選擇器為布林值。若 Gateway 在經 TLS 檢查的請求上偵測到 MCP-Protocol-Version 標頭，則值為 true，管理員可在允許或封鎖原則中使用它，而無需自行維護一份「看起來像 MCP」的網域清單。

直接加密流量必須先通過 TLS 解密，Gateway 才能檢查這些標頭；本機 stdio 伺服器、離線連線、「不檢查」流量，以及從未通過 Gateway 的請求，仍在此視野之外。

掌握網路中 MCP 流量的全貌

今天，我們推出了專屬的 MCP 流量儀表板，顯示網路中哪些主機正在提供 MCP 流量、哪些使用者正在產生該流量，以及請求是正在通過您的 Cloudflare MCP Portal 還是完全繞過它們。

image4.png

此儀表板顯示：

  • 在可設定的時間範圍內，MCP 請求總數、唯一使用者數及唯一伺服器數
  • 各伺服器的 MCP 請求數量隨時間的變化趨勢
  • 按上線方式劃分的流量，區分 MCP Portal 流量與裝置直連流量
  • 在您的 Portal 以外被偵測到的頂端 MCP 伺服器，即最關鍵的影子 MCP 流量
  • 按 MCP 請求量排名的頂端使用者
image2.png

管理員可依特定伺服器、使用者或上線方式進行篩選，並直接跳轉至依相關主機或使用者篩選的 Gateway HTTP 記錄，以進行深入調查。

image1.png

將已探索的伺服器納入 MCP Portal

MCP 探索功能將未知流量轉化為管理員可調查的清單。當組織核准其中某個伺服器後，可以將其置於 Cloudflare MCP 伺服器 Portal 後方。Portal 為員工提供一個受管理的端點，並在上游伺服器前方部署 Access 身分驗證、精選工具目錄和記錄功能。管理員可以將相容的上游呼叫透過 Gateway 路由，以實現 HTTP 原則、可預測的輸出，以及針對整個 Portal 或個別伺服器的資料外洩防護。工具活動也可以透過 Logpush 匯出。探索儀表板隨後可以區分使用 Portal 的請求與直接連線至同一伺服器的請求。

這為從探索到治理建立了一條完整路徑：找出伺服器、決定是否核准、將已核准的使用導入 Portal，並調查持續繞過 Portal 的流量。最後一步至關重要，因為未核准的伺服器和繞過已核准伺服器，是兩個不同的問題。

強制執行僅限 Portal 存取

我們正在將 Traffic Source 選擇器新增至 Gateway 網路和 HTTP 原則，讓管理員能夠依據 MCP 流量是否源自您的 MCP Portal 來精細地撰寫控制規則。

當 MCP Portal 流量透過 Gateway 路由時，它會攜帶 mcp_portal Traffic Source，讓原則能夠區分 Portal 代理的請求與員工的直接連線。基本的強制執行規則如下：

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

任何未透過 Portal 抵達的已偵測 MCP 流量都會被封鎖；透過 Portal 傳來的流量則不受影響。對於希望在強制執行前先觀察的組織，Traffic Source 和 MCP 偵測功能現在已存在於已解密流量的 HTTP 記錄中，讓您無需建立原則即可監控代理流量的行為。

更多 MCP 伺服器現在可以使用受管理路徑

已核准的路徑只有在能夠連線至員工實際需要的大量伺服器時才有實際意義。

早期 MCP 規範建議使用動態用戶端註冊，讓用戶端無需 OAuth 應用程式即可向授權伺服器自行註冊。然而許多常見的 OAuth 提供商採用不同的模式：他們要求管理員預先以固定的用戶端 ID、用戶端密碼、回呼 URL 和範圍集合來註冊應用程式。MCP 2026-07-28 也在近期棄用了動態註冊。

為協助解決此問題，MCP Portal 現在支援預先註冊的 OAuth 用戶端。管理員可以設定手動 OAuth 憑證、在儀表板中顯示的回呼 URL 上向上游提供商進行註冊，並輸入用戶端憑證。Portal 在可用時會自動探索標準 OAuth 中繼資料，且管理員可在探索不可用時手動提供授權、權杖、撤銷和簽發者端點。

每位使用者仍須自行授權存取其上游資料來源，而儲存的用戶端密碼僅用於取得更新的工具和提示清單。

手動 OAuth 支援現在有助於涵蓋各種 OAuth 實作的排列組合。部分提供商需要自訂標頭、個人存取權杖或明確的用戶端允許清單，而這些是另外的相容性問題。我們將在未來幾個月內持續擴展 MCP Portal 的 OAuth 支援。

將私有 MCP 伺服器納入同一個 Portal

公共 SaaS 工具只是企業 MCP 目錄的一部分。大多數企業依賴的安全資訊並非可從公共網際網路取得；它存在於公有或私有雲端基礎架構中，或在本地部署，只能透過連線至私有網路才能存取。

目前，MCP Portal 必須能夠透過公共網際網路解析並到達上游伺服器。這意味著僅在私有網路上可用的伺服器（例如透過私有 DNS 可用或在私有 IP 空間內可用）無法被 Portal 連線。我們正在努力讓 MCP Portal 透過 Cloudflare Gateway 路由和 Cloudflare One 網路（已用於其他私有應用程式的相同網路）連線至私有伺服器。

私有伺服器保留其私有主機名稱；Portal 透過 Cloudflare 的私有路由連線至該伺服器，並將其工具與公共上游伺服器並列呈現；而 Access 原則、Portal 記錄和工具控制在同一個前端閘道繼續適用。

透過 Gateway 路由 Portal 流量也會將其標記為 mcp_portal Traffic Source，讓 Gateway 原則可以區分 Portal 請求和員工的直接連線。MCP 伺服器的私有連線能力正在積極開發中；請持續關注 Changelog 以獲取更多資訊。

Agents SDK 支援新的無狀態模型

幾週前，MCP 專案發布了 2026-07-28 規範，這是一個重大修訂，以無狀態的每請求模型取代了基於連線範圍的初始化。我們在《新一代 MCP》中介紹了通訊協定變更和遷移路徑。

Cloudflare Agents SDK v0.20.0 以用戶端和伺服器雙重角色支援 MCP 2026-07-28。對於每個連線，用戶端首先以 server/discover 探測新的無狀態通訊協定；若伺服器不支援，用戶端則在同一連線上繼續使用舊版的 initialize 交握。現有的 addMcpServer 呼叫無需單獨設定通訊協定或使用不同的用戶端。

在伺服器端，createMcpHandler 無需建立傳輸工作階段或 Durable Object，即可從 Worker 提供無狀態工具、提示、資源和 elicitation：

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";

function createServer() {
  return new McpServer({ name: "example", version: "1.0.0" });
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
} satisfies ExportedHandler;

回退機制至關重要，因為通訊協定遷移很少一次到位。新的用戶端仍需連線至既有的伺服器，而新的伺服器也仍需處理尚未完成遷移的用戶端。Agents SDK 在生態系統過渡期間同時支援兩條路徑。

從可見性出發，再封鎖不應存在的路徑

一個可行的 MCP 資安方案，始於了解使用者的流量概況和 MCP 使用情況，並就已核准的工具集和存取方法達成共識。

首先，檢查通過 Gateway 的 MCP 流量，並將其目標與組織已核准的伺服器進行比對。將更多已核准的伺服器移至 MCP Portal 後方。

接著，在您可以控制的邊界上強制執行原則。組合使用 MCP 偵測條件、Traffic Source 和目標條件來撰寫 Gateway 原則，以封鎖來自受管理裝置和網站的直接 MCP 連線，並盡可能將自架上游伺服器限制為僅限 Portal 流量。

我們即將為 MCP 流量的可見性和控制提供更精細的功能，包括對特定工具使用的控制，以及環境中所有 MCP 伺服器（無論是否為資安組織所知）工具使用情況的新報告功能。

我們的 MCP 流量偵測教學課程涵蓋了目前 Gateway 記錄可用的主機名稱、路徑和 JSON-RPC 啟發式方法。待新訊號正式上線後，我們將在文件中更新通訊協定選擇器的詳細資訊。