The Governed Execution Gateway: Securing MCP Servers and Tool Egress Proxies 封面圖片

Google Developer Experts 個人檔案圖片 Jitendra Gupta

Model Context Protocol (MCP) 的邊界缺口

隨著 Model Context Protocol (MCP) 快速成為連接 LLM 與本地檔案系統、SaaS 平台及企業資料庫的產業標準,平台工程團隊正面臨新的安全邊界。

讓自主 AI 代理直接連接到未受監控的 MCP 伺服器或外部 API 閘道,會帶來嚴重的企業風險:

  • 嵌入在工具回應中的提示注入酬載
  • 未經授權的資料外洩
  • 未受限的 API 迴圈 以及失控的遞迴呼叫
  • 缺乏協定層級的檢查

若要安全地大規模運行 MCP 伺服器與工具執行,企業架構必須導入 受控執行閘道——一種位於代理協調器與下游工具執行環境之間的專用出口代理。


受控執行閘道的架構

受控執行閘道作為所有非人類工具呼叫酬載的雙向安全代理:

  • 輸入檢查與參數清理:檢查代理產生的 JSON-RPC 工具呼叫請求。驗證引數型別、移除惡意的 SQL/命令注入字串,並在將請求轉發至目標 MCP 伺服器前,驗證權杖執行者宣告 (act)。
  • 輸出酬載過濾(資料出口控制):在內容填充前,掃描下游系統傳回的工具輸出。防止隱藏在檢索資料中的間接提示注入,並自動編輯敏感的 PII 或系統權杖。
  • 速率限制與迴圈阻斷器:追蹤有狀態的執行深度。若代理在單一追蹤情境中持續迴圈或觸發遞迴工具呼叫,閘道將動態終止執行。

MCP 與工具閘道治理的 3 項必要規則

  1. 協定層級的雙向 TLS 與短效期 MCP 權杖:直接對 MCP 伺服器的 TCP 或 stdio 連線必須透過雙向 TLS (mTLS) 或 OAuth 2.1 範圍權杖進行管控。未經身份驗證的純文字 MCP 傳輸在生產環境中必須嚴格禁止。

  2. 雙向酬載檢查:永遠不要信任來自模型的輸入或來自工具的輸出。輸入必須經過嚴格的 JSON Schema 參數驗證;輸出在填充情境前,必須掃描隱藏的提示注入標記與敏感資料洩漏。

  3. 集中式出口控制與遙測:所有工具呼叫都必須透過具備 OpenTelemetry 追蹤的統一代理層進行路由——記錄完整的請求-回應配對、執行延遲以及用於稽核的身分中繼資料。


架構師觀點

關鍵洞見:MCP 標準化了 AI 代理與企業系統的介面方式,但若在標準化連線協定時未建立邊界治理,則會在基礎架構中製造一扇未受監控的後門。

請以對待公開面向微服務的相同 零信任 安全原則來對待您的 MCP 伺服器:驗證每項引數、檢查每項酬載,並將所有出口流量導經受控代理。


來源與參考


關於我

我是一名擁有 14 年 IT 產業經驗的 企業雲端與 AI 架構師,協助各組織設計與擴展企業級雲端、AI 與自動化解決方案。

我目前的工作重點在於建構企業規模的 AIOps 平台、加速客戶的 AI 優先轉型旅程、推動 FinOps 採用,以及開發能創造可衡量商業影響的生產就緒生成式 AI 應用程式。

歡迎透過 LinkedInX (Twitter) @jitu028 與我聯繫。若需一對一架構諮詢,請造訪我的 Topmate