當大型語言模型只能回答問題時，風險多半停留在錯誤內容；當 AI Agent 能透過 Model Context Protocol（MCP）讀取資料庫、操作檔案、呼叫雲端服務，錯誤便可能直接變成真實世界的動作。CIS 發布首版 MCP Server Benchmark，重要性不在於又多了一份安全指南，而在於企業首次有一套可拿來設定、驗收與稽核 MCP 部署的中立基準。
從「會連接」走向「可管控」
來源事實：Center for Internet Security（CIS）公告，CIS MCP Server Benchmark v1.0.0 是依當前 MCP 規格、透過共識程序制定的安全設定建議，涵蓋本機與遠端部署，也納入企業常用的閘道器及代理伺服器。全套基準共有 55 項具體建議，分布於治理與版本、傳輸、身分驗證與授權、用戶端與伺服器設定、資料保護、稽核、供應鏈、隔離與執行安全、資源限制及快取等十個領域；每一項都附有理由、稽核程序和修正指引。原始公告見 https://www.cisecurity.org/about-us/media/press-release/cis-releases-cis-mcp-server-benchmark-v1-0-0，CIS 的基準清單也已列出 MCP Server 1.0.0：https://www.cisecurity.org/cis-benchmarks。
這裡的關鍵字是「可測試」。一般安全白皮書會告訴企業應採最小權限、留下紀錄或保護憑證，卻不一定說明稽核人員如何判定合格。CIS Benchmark 的商業價值，是把原則轉成可重複檢查的控制項，讓開發、資安、採購與內稽能使用同一套語言。對提供 MCP 平台或代管服務的廠商而言，它也可能逐漸成為投標文件、供應商問卷與服務契約中的共同驗收底稿。
為何 MCP 需要獨立的安全邊界
MCP 的角色類似 AI 與外部系統之間的標準轉接層。模型提出要呼叫哪個工具、帶入哪些參數，伺服器則把請求送往真正的資料或服務。便利之處在於一套介面可以連接許多能力；風險也由此而生：同一個入口可能同時碰到客戶資料、內部檔案、瀏覽器與具寫入權限的 API。
MCP 官方在 2026 年 7 月公布的規格更新，已把核心改為無狀態的請求／回應模式，並要求 Streamable HTTP 請求帶上方法及工具名稱標頭，使閘道器、限流器或 WAF 可以直接依標頭路由與計量；授權部分也加入發行者驗證、憑證與發行者綁定等強化措施。這些內容可在官方說明交叉查證：https://blog.modelcontextprotocol.io/posts/2026-07-28/。
合理推論：協定開始提供更清楚的身分、路由與快取訊號，代表企業更容易把既有 API Gateway、WAF、身分管理和監控系統接進 MCP；但「協定可表達」不等於「部署已安全」。是否限制來源、驗證權杖受眾、隔離程式執行、控制資源消耗，以及工具異動後是否重新審查，仍是營運層的責任。CIS 基準正好填補規格與實際控制之間的落差。
真正難管的是能力漂移
CIS 另一份針對 MCP 整合層的官方說明指出，授權決策不能交給模型，而應由伺服器或閘道器執行身分綁定、權杖驗證、權限範圍、工具存取清單與最小權限。該文件也提醒，MCP 伺服器可能更新其工具、資源與提示詞；原本安全的服務，可能因相依套件更新或新增能力而擴張權限。文件建議建立允許清單、能力基準、異動偵測與新能力預設拒絕機制：https://www.cisecurity.org/insights/blog/securing-the-integration-protocol。
作者觀點：MCP 最值得警戒的地方，不只是單次提示注入，而是「今天通過審查的工具，明天是否仍是同一個工具」。企業若只在上線前掃描程式碼，卻不保存工具清單、參數結構、權限範圍與版本的基準快照，就很難發現能力悄悄改變。換言之，MCP 安全更接近持續性的供應鏈治理，而不是一次性的弱點掃描。
落地時可以怎麼用
台灣企業不必等到正式稽核才導入。採購或自建 MCP Server 時，可先把驗收拆成四組證據：
- 資產與治理：列出伺服器、擁有者、協定版本、部署位置，以及所有工具與資料來源。
- 存取控制：證明模型輸出的請求仍須經過獨立授權，並確認讀取、寫入、刪除等能力分權。
- 執行與供應鏈：保存套件來源、版本及核准紀錄，對新工具採預設拒絕，並隔離不受信任程式。
- 稽核與韌性：記錄誰以何種身分呼叫哪項能力及結果狀態，同時測試限流、逾時、快取與異常回復。
這些做法是依已公開的十個領域所做的實務分組，並非逐字轉述 55 項控制。企業仍應下載正式基準，逐項核對適用範圍，避免把概括清單誤當成完整合規證明。
容易忽略的限制
第一，v1.0.0 是設定基準，不是產品認證，也不能證明模型不會產生危險意圖。第二，本機 stdio、遠端 HTTP、閘道器與代理架構的信任邊界不同，不能用一份設定檔直接套用所有情境。第三，MCP 規格仍在快速演進；官方 2026 年版本已調整連線狀態、授權與棄用政策，因此控制項、SDK 與實際部署版本必須同步盤點。最後，稽核紀錄若直接保存提示內容、權杖或敏感回傳資料，監控系統本身反而可能成為外洩來源。
接下來要看什麼
後續可觀察四項指標：CIS 是否公布修訂版及版本對照；主流 MCP SDK、閘道器與雲端服務是否提供自動化檢查；企業採購案是否開始要求基準符合度；以及工具清單或權限漂移能否被持續偵測。若這些配套成熟，MCP Server Benchmark 的影響將不只是一份文件，而是把 AI Agent 從試驗性整合，推向可盤點、可驗收、也可追責的企業基礎設施。