Cloudflare Gateway 靠協定層特徵抓出企業內的影子 MCP 流量
Cloudflare Blog · 2026-08-14
Cloudflare 於 2026-08-14 在官方部落格公布 Gateway 產品線新增偵測 Model Context Protocol（MCP）流量的能力，讓企業能看見有多少 AI agent 正在連到公司內外的 MCP 伺服器。這項更新的核心賣點不是擋掉 MCP，而是先讓資安團隊「看得到」原本完全沒有可視性的流量。文章同時公布了一個新的 Gateway 布林選擇器與對應的儀表板。
原本的問題
AI agent 與傳統使用者不同：agent 的行為是非決定性的，一旦被誘導或出錯，可能在極短時間內對內部工具、資料庫發出成千上萬次錯誤呼叫。多數企業的 secure web gateway 在此之前無法辨識 MCP 流量，因為 MCP 請求外觀上就是一般 HTTPS POST，沒有專屬的偵測規則。這代表大量「影子 MCP」（shadow MCP）連線——員工自行串接、未經 IT 審核的 MCP 伺服器——完全遊走在既有安全政策之外。
偵測機制
Cloudflare 說明偵測靠的是協定層特徵而非單純網域比對。關鍵訊號是 MCP-Protocol-Version 這個 HTTP header；文章引用規格原文：「The MCP 2026-07-28 specification requires it on every POST request.」除此之外還會辨識 Mcp-Method、Mcp-Name 這兩個 header（分別暴露呼叫的操作與工具名稱），以及請求 body 中 JSON-RPC 信封裡的方法名，例如 tools/call、initialize、resources/read。對於較舊、不遵守新規格的 client，Gateway 則退回用網域含 mcp、路徑含 /mcp 等啟發式規則加上請求 body 內的 JSON-RPC 方法名比對。
一個典型 MCP 請求範例如下：
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_weatherGateway 新增功能
Cloudflare 這次上線的核心是一個新的布林選擇器 experimental.is_mcp == true，可直接寫進 Gateway 的 Network 與 HTTP 政策。搭配的還有一個 MCP 流量儀表板，會列出：
- MCP 請求總數、獨立使用者數與伺服器數
- 各 MCP 伺服器隨時間變化的請求量
- 區分「MCP Portal 代理流量」與「直連流量」的占比，文中稱後者為「the shadow MCP traffic that matters most」
企業也能用新增的 traffic.onramp 選擇器（值為 mcp_portal）辨識請求是否經過 Portal 代理，例如以下政策會封鎖所有繞過 Portal 的直連 MCP 流量：
experimental.is_mcp == true and not traffic.onramp in ("mcp_portal")
Action: Block相關產品更新
同一波更新中，MCP Portals 新增手動設定 OAuth 憑證與自訂端點的能力，並預告未來可透過 Cloudflare Gateway 路由私有網路連線、提供工具層級的存取控制與精選工具目錄，另外也開放 Logpush 匯出。Cloudflare Agents SDK 同步發布 v0.20.0，同時支援 client 與 server 端的 2026-07-28 無狀態（stateless）協定版本，並會在偵測到舊版 client 時自動退回舊有的 initialize 交握流程。
Cloudflare 在文中把防護拆成三個控制點：client 端 hook（最早但依賴裝置）、網路邊界（靠 gateway 做 TLS 解密後檢查，涵蓋面最廣）、以及伺服器端授權（執行情境最豐富）。文章坦言 Gateway 作為網路層防線雖然視野最廣，但對本機 stdio 呼叫或完全不經過受管網路的流量仍無能為力。
原始來源：How Cloudflare detects MCP traffic and helps secure it、JSON-RPC 2.0 Specification
Cloudflare 把 Access 政策直接綁在 Worker 上，堵住「vibe coding」內部應用外洩缺口
Cloudflare Blog · 2026-08-14
Cloudflare 於 2026-08-14 發布 Access for Workers，讓 Cloudflare Access 的身分驗證政策可以直接附加在 Worker 應用程式本身，而不再只能綁在個別網域上。背景是員工用 AI 工具「vibe coding」出來的內部小工具，常常因為忘了加驗證就被部署到公開網址上，變成資料外洩的破口。這篇文章說明了新機制如何確保政策在所有部署入口都自動生效。
原本的問題
過去 Cloudflare Access 的政策是綁在特定 hostname 上。當開發者用 AI 快速生成一個 Worker 應用，並透過自訂網域、Routes、workers.dev 子網域或 Preview URL 部署時，只要有任何一個入口忘了掛上 Access 政策，該入口就會直接暴露在公開網際網路上。這正是文章開頭點名的「shadow IT」風險：員工不是惡意行為，而是流程上少了一道保護。
採用的方法
Access for Workers 的做法是把政策掛在 Worker 這個實體本身，而不是掛在某個 URL 上。這樣一來，同一個 Worker 不論透過哪種方式對外曝露，都會套用同一組驗證規則。政策可以設定在三個層級，優先權由細到粗：
- 帳號層級的預設政策
- 個別 Worker 的專屬政策
- 特定 hostname 的規則（最細，優先權最高）
底層依靠的是 FL2——Cloudflare 以 Rust 打造的模組化 proxy。FL2 把「Workers 路由」與「執行」拆成兩個階段，因此 Access 可以在決定由哪個 Worker 處理請求之前，就先完成政策判斷與驗證。
實際效果
對應用程式本身而言，開發者不需要自己處理 JWT 驗證邏輯，只要在程式碼中呼叫 ctx.access.getIdentity() 就能拿到通過驗證的使用者 email、姓名與群組資訊。本機開發體驗也一併處理：wrangler.jsonc 設定檔新增了 access 區塊，可以在本地模擬已驗證使用者，不必每次都真的走一次線上 OAuth 流程。文章也提到開源的「internal static site platform」範本，展示如何用這套機制搭配 Workers for Platforms 架構，讓內部工具預設就具備隱私保護。
原始來源：Secure all your internal vibe-coded applications — in one click
NuGet 大砍 API 金鑰壽命至 30 天，全力導向 OIDC 式 Trusted Publishing
Microsoft DevBlogs · 2026-08-14
.NET Blog 於 2026-08-14 宣布，NuGet.org 將從 2026-08-17 起把新建 API 金鑰的最長有效期限砍到 30 天，取消原本可選的 365 天長效期選項。在 2026-08-17 之前建立的既有金鑰，則會被統一設定在 2026-11-01 到期。這是 NuGet 團隊持續收緊套件發布供應鏈安全性的最新一步。
原本的問題
文章直言：「a NuGet.org API key is effectively a password for publishing packages」——一把 API 金鑰形同一組可以發布套件的密碼，一旦外洩，攻擊者就能直接冒名推送惡意版本。長效期金鑰正是問題核心：金鑰存活越久，一旦不慎外洩（誤 commit、CI 環境變數外流等），攻擊者的可乘之機就越長。文章舉出 npm 生態圈的 NX Console 套件遭竊取憑證入侵一案為例，攻擊者用偷來的憑證發布惡意版本，短短 36 分鐘內就被下載約 6000 次。
金鑰壽命變化
| 項目 | 變更前 | 變更後 |
|---|---|---|
| 新建金鑰上限 | 最長 365 天 | 最長 30 天 |
| 生效時間 | — | 2026-08-17 起適用於新金鑰 |
| 既有金鑰處理 | 依原設定到期 | 統一於 2026-11-01 到期 |
建議改採的方案：Trusted Publishing
比起管理一堆會過期的短效 API 金鑰，官方更建議直接改用 2025-09 上線的 Trusted Publishing 機制。其運作方式是讓 CI/CD workflow 透過 OpenID Connect（OIDC）向 NuGet.org 認證：workflow 出示一個已簽章、短效的身分 token，NuGet.org 依套件擁有者事先設定好的政策驗證這個 token，驗證通過後才即時核發一組僅供本次發布使用的臨時 API 金鑰。這代表 repository 或 CI 設定裡不需要再存放任何長期存在的密鑰，目前已支援 GitHub Actions 與 GitLab 的使用者。
過渡期建議
對於還沒辦法立刻遷移的團隊，官方文章給出的過渡期做法包含以下幾點：
- 盤點目前所有仍在使用 API 金鑰的發布 workflow
- 留意金鑰即將到期的通知信
- 盡量把金鑰的套件範圍（scope）縮到最小
- 及早規劃改用 OIDC 的遷移時程
官方也附上 Trusted Publishing 官方文件供團隊評估遷移細節。
原始來源：Strengthening NuGet Supply Chain Security: Reducing API Key Lifetime、NuGet Trusted Publishing 文件