Model Context Protocol (MCP) 的邊界缺口
隨著 Model Context Protocol (MCP) 快速成為連接 LLM 與本地檔案系統、SaaS 平台及企業資料庫的產業標準,平台工程團隊正面臨新的安全邊界。
讓自主 AI 代理直接連接到未受監控的 MCP 伺服器或外部 API 閘道,會帶來嚴重的企業風險:
- 嵌入在工具回應中的提示注入酬載
- 未經授權的資料外洩
- 未受限的 API 迴圈 以及失控的遞迴呼叫
- 缺乏協定層級的檢查
若要安全地大規模運行 MCP 伺服器與工具執行,企業架構必須導入 受控執行閘道——一種位於代理協調器與下游工具執行環境之間的專用出口代理。
受控執行閘道的架構
受控執行閘道作為所有非人類工具呼叫酬載的雙向安全代理:
-
輸入檢查與參數清理:檢查代理產生的
JSON-RPC工具呼叫請求。驗證引數型別、移除惡意的 SQL/命令注入字串,並在將請求轉發至目標 MCP 伺服器前,驗證權杖執行者宣告 (act)。 - 輸出酬載過濾(資料出口控制):在內容填充前,掃描下游系統傳回的工具輸出。防止隱藏在檢索資料中的間接提示注入,並自動編輯敏感的 PII 或系統權杖。
- 速率限制與迴圈阻斷器:追蹤有狀態的執行深度。若代理在單一追蹤情境中持續迴圈或觸發遞迴工具呼叫,閘道將動態終止執行。
MCP 與工具閘道治理的 3 項必要規則
協定層級的雙向 TLS 與短效期 MCP 權杖:直接對 MCP 伺服器的 TCP 或
stdio連線必須透過雙向 TLS (mTLS) 或 OAuth 2.1 範圍權杖進行管控。未經身份驗證的純文字 MCP 傳輸在生產環境中必須嚴格禁止。雙向酬載檢查:永遠不要信任來自模型的輸入或來自工具的輸出。輸入必須經過嚴格的 JSON Schema 參數驗證;輸出在填充情境前,必須掃描隱藏的提示注入標記與敏感資料洩漏。
集中式出口控制與遙測:所有工具呼叫都必須透過具備 OpenTelemetry 追蹤的統一代理層進行路由——記錄完整的請求-回應配對、執行延遲以及用於稽核的身分中繼資料。
架構師觀點
關鍵洞見:MCP 標準化了 AI 代理與企業系統的介面方式,但若在標準化連線協定時未建立邊界治理,則會在基礎架構中製造一扇未受監控的後門。
請以對待公開面向微服務的相同 零信任 安全原則來對待您的 MCP 伺服器:驗證每項引數、檢查每項酬載,並將所有出口流量導經受控代理。
來源與參考
- Anthropic:Model Context Protocol (MCP) 架構規格
- Cloudflare:在規模化環境中保護 AI 代理出口與 MCP 連線
- OWASP:大型語言模型應用程式前十大風險 – OWASP LLM07:不安全的插件設計
- Solo.io:AI 代理工具執行與治理的 API 閘道模式
關於我
我是一名擁有 14 年 IT 產業經驗的 企業雲端與 AI 架構師,協助各組織設計與擴展企業級雲端、AI 與自動化解決方案。
我目前的工作重點在於建構企業規模的 AIOps 平台、加速客戶的 AI 優先轉型旅程、推動 FinOps 採用,以及開發能創造可衡量商業影響的生產就緒生成式 AI 應用程式。
歡迎透過 LinkedIn 或 X (Twitter) @jitu028 與我聯繫。若需一對一架構諮詢,請造訪我的 Topmate。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.