AI 前線提出 MCP 生產環境四層防禦：閘道之外還需保護工具執行、管理平面、出站信任與語意完整性

AI 前線一篇文章主張，生產環境的 MCP（Model Context Protocol，模型上下文協議）安全不應只依賴閘道，而應分成四個控制層：工具執行、管理基礎設施、出站信任邊界，以及語意完整性。文章指出，閘道可集中處理身分驗證、授權、稽核與政策評估，但無法單獨防止工具處理器不安全地執行參數、管理介面暴露、伺服器使用過寬憑證對外連線，或已核准的工具 Manifest 發生語意漂移。 文章稱，2026 年最初 60 天內，針對 MCP 部署的 CVE 報告超過 30 個。其引用 Adversa AI 3 月資料指出，在掃描超過 500 個 MCP 伺服器時，38% 的關鍵端點缺少驗證、43% 存在命令執行漏洞；文章也提到 Microsoft 於 3 月 10 日發布修補程式，處理 Azure MCP Server 的 SSRF 漏洞 CVE-2026-26118，該漏洞 CVSS 為 8.8，可能導致託管身分權杖外洩。上述數據與漏洞說明均為文章引用內容，並非本日報另行驗證的結果。 第一層是工具執行。文章引用的 30 個 CVE 中，有 13 個涉及未驗證的使用者輸入流入 shell 或動態直譯器，包括 mcp-maigret 的 CVE-2026-2130、xcode-mcp-server 的 CVE-2026-2178、HarmonyOS-mcp-server 的 CVE-2026-2131，以及使用 Python eval() 處理圖表規格參數的 CVE-2026-1977。文章建議將工具參數視為資料，使用 execFile 或陣列形式的參數傳遞，避免字串插值進入 shell，並在 CI 以 Semgrep 阻擋 exec、eval、shell=True 與 os.system 等常見不安全執行模式；同時提醒這些規則仍未涵蓋所有直譯器、間接匯流點與語言特有的繞過方式。 第二層是管理平面，包括 inspector、測試 harness、註冊介面與管理主控台。文章稱，其評估中曾發現測試 harness 在未驗證的內部網路上監聽，關閉暴露只花了 20 分鐘；引用的 30 個 CVE 中另有 6 個針對 MCP 的開發與執行基礎設施，而非協議本身。例如，MCPJam Inspector 的 CVE-2026-23744 涉及未驗證端點，預設監聽 0.0.0.0 並可安裝任意 MCP 伺服器；Dive MCP Host 的 CVE-2026-23523 則可透過特製深層連結，在使用者端應用程式內安裝惡意設定。文章建議管理端點禁止匿名存取、避免廣泛對外暴露、限制檔案系統可達範圍、使用短期憑證並記錄存取日誌。 第三層是出站信任與權杖範圍。文章以 Azure MCP Server 的 CVE-2026-26118 為例，稱攻擊者可替換 Azure 資源識別碼為惡意 URL，讓伺服器使用託管身分權杖對該網址發出請求，進而接觸伺服器可存取的 Azure 資源。因此，文章建議同時強制入站端點驗證、以出站允許清單限制伺服器可連線的服務，並將下游憑證權限縮小至符合工具影響範圍；需要新增網域或內部服務時，應視為明確的變更，而非隱含行為。 第四層是語意完整性，即工具在取得信任後，其定義與用途是否仍維持一致。文章建議在註冊時固定工具 Manifest，對後續變更進行差異比較與審查，以降低模式漂移與「rug-pull」行為；差異式審查應成為日常運維流程，而不只是一次性的允許或拒絕門控。文章另引用一個包含 114 個惡意 MCP 伺服器的資料集，稱多元件攻擊鏈往往比單一元件攻擊更有效，藉此支持分層防禦，而非期待單一閘道或控制機制攔截所有問題。 文章表示，作者團隊在 2025 年底將 MCP 作為生產級多智能體平台的整合層，並據此提出上述架構控制。文中也提到，MCP 維護者 David Soria Parra 於 3 月 9 日發布 2026 MCP 路線圖，將企業就緒列為優先事項；4 月 2 至 3 日的 MCP 開發者峰會則有亞馬遜雲端科技、Uber 與 Pinterest 分享 MCP Gateway、Registry 及領域專用 MCP 伺服器架構。文章據此認為，企業導入速度快於安全規範成熟速度，因此建議先落實 CI 門控、工具隔離、出站限制與 Manifest 差異審查，而不必等待協議規範變更。