大多數公司的資源權限，是為「人」設計的。資深工程師可以部署 production、查敏感資料庫、撤銷別人的存取權，這些特權之所以敢給，是因為背後站著兩個前提：這個人會用判斷力踩剎車，而且他再快也只能以人類的速度行動。AI agent 把這兩個前提同時拆掉了——決策是 nondeterministic 的，而且同一個工具呼叫可以無限重複、不會累、不用吃午餐。一個貌似合理但錯誤的決策，可能在任何人察覺之前放大成上千個錯誤行動。
更麻煩的是，這些流量就藏在你的網路裡，而且沒有長相。
一行設定就能接上，錯誤也會以同樣速度放大
把一個 agent 接上 MCP server，只需要一行設定。員工可以把 Claude Code、Codex、Cursor、OpenCode、VS Code 或任何 AI harness 指向一個未經資安核准的 MCP server，過程不需要任何人的簽核。MCP 讓 agent 用統一的方式探索並呼叫第三方 SaaS、內部應用與 API 背後的工具，這是它的價值，也是治理的破口：改變的不是權限本身，而是「誰在做每一個決定」，以及一個壞決定能多快擴散。
傳統的權限模型假設犯錯的人會停下手來猶豫。Agent 不會。這就是為什麼以人為中心的 RBAC 設計，在 agent 時代需要一條完全不同的防線。
MCP 流量沒有長相，URL 認不出它
資安團隊的第一直覺是用 URL 過濾，但 MCP 沒有保證的 hostname 慣例，也不要求路徑裡有 /mcp。一條 direct connection 在網路上看起來就是普通的 HTTPS API call，光看目的地什麼都判斷不出來。
不過協定本身留了指紋。MCP 規範定義了幾個隨每個請求傳送的識別欄位：
POST /mcp HTTP/1.1
Host: tools.example.com
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weatherheaders 之外，body 是一則 JSON-RPC 2.0 訊息。hostname 和路徑指認目的地，這些 protocol signals 則說明「這是一個 agent 在呼叫工具」。同樣一筆 MCP 請求，在 client 內是一個帶參數的工具呼叫決策，在網路上是一則 HTTP 交易，到了 server 則變成一次可能讀資料、改狀態的 handler 執行——三種形態，三個潛在控制點。
三個控制點，為什麼網路層最實際
理論上安全團隊有三個出手位置。第一個在 MCP client 內，但那取決於每個 harness 的實作，跨工具難以標準化。第二個在裝置的網路邊界，問題是 local VPN 只看得到單一裝置的流量，公司沒辦法在每台機器上強制部署。第三個在 MCP server 呼叫工具之前，但那已經是最後一跳，credential 早已跨網傳出。
三個位置各有破口，結論指向同一個地方：企業的網路層。那是所有流量不論用什麼 client、去什麼 server 都必經的共同攔截面。
Cloudflare 的做法：先讓流量現形
Cloudflare 的更新圍繞 Cloudflare One 與 Gateway 展開。現階段，Gateway logs 已經能用 hostname、path 與 JSON-RPC 的 heuristics 從 inspected traffic 中找出疑似 MCP 的流量；接下來 HTTP policies 會加入 mcp_protocol_version、mcp_method、mcp_name 三個 protocol selectors（發文時為即將 GA，尚未正式上線），屆時就能寫出「僅當 mcp_name 在核可清單內才允許 tools/call」這類規則。搭配 Cloudflare One dashboard 的 telemetry，管理員可以看到哪些身分呼叫了哪些 server、各 method 的呼叫量，以及哪些目的地繞過了 portal。
這裡有個容易混淆的區分：shadow MCP 是 agent 連向根本未核准的 server；approved-path bypass 則是該走治理路徑的流量直連 origin。前者該用的是 onboarding——把被需要的 server 收編進治理軌道；後者該用的是 enforcement——把 direct route 封起來。混為一談的結果通常是全面封鎖，然後逼著使用者繞更遠的路。
另外，所有 Cloudflare Zero Trust 客戶現在都能在 Gateway HTTP logs 中看到 MCP 流量的標記，並用一個新的 selector 明確封鎖或允許這類流量：
experimental.is_mcp == true這個 selector 是 boolean 值：只要 Gateway 在經過 TLS 解密的請求中偵測到 MCP-Protocol-Version header，值就會是 true，可以直接放進 Allow 或 Block 政策，不必自己維護一份「看起來像 MCP」的網域清單。
Portal 模式：核准、稽核、強制一條龍
MCP Server Portals 給每個核准的 MCP server 一個 Cloudflare 網路上的 hostname，附帶 access controls、logging 與 audit，agent 改走 portal 而非直連。被發現的 shadow server 可以直接 onboard 成 governed access，不必從零重建。實際情境長這樣：資安團隊先在 Gateway logs 裡發現某個部門的 agent 長期直連一個第三方工具的 MCP server；確認用途正當後，把它註冊進 portal、掛上存取政策與稽核，流量隔天就走治理路徑，原本的影子風險變成可管理的存取。過去 portals 要求 OAuth，現在支援更多 server 認證方式，內部工具不用 re-architecture 就能納入同一套治理；連 private network 後面的 MCP server，也能經由 Cloudflare Tunnel 用同一個 portal 模式發布，拿到相同的 policy 與 audit。Gateway policy 進一步可以強制 MCP 流量只能走 portal hostname——就算 agent 手上有合法 credential，直連 origin 照樣被封鎖。對應的 baseline 封鎖規則長這樣：
experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block凡是未經 portal 進來的 MCP 流量都會被擋下，走 portal 的流量不受影響；想先觀察再強制的團隊，也可以先只在 HTTP logs 裡監看，不急著上政策。
配套還包括 Cloudflare Agents SDK 對新 stateless MCP server model 的支援：單一 Worker 就能服務 tool calls，不需要 long-lived sessions，在 Workers 上更好擴展。
給治理團隊的落地順序
這套能力建議按順序部署，而不是一次全開。第一步先開 visibility：用 Gateway logs 的 heuristics 跑一兩週，看網路裡實際存在哪些 MCP 流量、誰在用、去了哪裡。第二步做 onboarding：把高頻且正當的 server 收進 portal，讓使用者有合法的路可走。第三步才是 enforcement：selectors GA 之後，把非 portal 的直連路徑封鎖。
順序顛倒的代價很具體——在合法路徑存在之前先封鎖，agent 使用者只會找更隱蔽的出口，你反而失去剛剛拿到的 visibility。治理的重點從「誰可以按按鈕」轉向「流量走哪條路」，而這條路必須先存在、再強制。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。