41% MCP 伺服器零認證：AI Agent 安全的計時炸彈

一場遲來的安全審視

Model Context Protocol（MCP）在過去一年的崛起堪稱奇跡。從 Anthropic 在 2024 年底發布的開源規範，到被捐贈至 Linux Foundation 旗下的 Agentic AI Foundation，再到 OpenAI、Google DeepMind、Microsoft 的全面採納，MCP 已確立為 AI Agent 工具連接的事實標準。Python 與 TypeScript SDK 合計月下載量突破 9,700 萬次，數以千計的 MCP 伺服器在 GitHub 上湧現，企業正加速將內部系統接入 MCP 生態。

然而，速度往往是安全的天敵。當整個行業全力奔跑時，一個根本性的問題被嚴重忽略：這些 MCP 伺服器安全嗎？

最新的安全審計數據給出了一個令人警醒的答案。研究人員對 518 個 AI Agent 工具進行了系統性安全評估，結果發現 214 個——佔總數的 41%——在 MCP 協議層完全不需要任何形式的身份認證。這意味著任何能夠觸達這些伺服器的 AI Agent 或惡意行為者，都可以直接調用其暴露的全部工具功能，無需提供任何憑證。

Bitrise 案例：當 CI/CD 大門敞開

在所有被審計的工具中，Bitrise CI/CD 平台的 MCP 伺服器堪稱最觸目驚心的案例。該伺服器向未經認證的發現機制暴露了 67 個工具，其中包括「delete_app」這樣的高破壞性操作。這意味著一個惡意的 AI Agent——或者一個被提示注入攻擊劫持的合法 Agent——可以在沒有任何認證的情況下發現並調用這些工具，直接刪除生產環境的應用程序。

這並非假設性的威脅場景。在 AI Agent 日益頻繁地被用於 DevOps 自動化的今天，CI/CD 工具鏈是最早被接入 MCP 生態的系統之一。開發團隊希望 AI Agent 能夠自動觸發構建、部署代碼、管理環境配置。但如果這些操作的入口不設任何認證門檻，結果就是將企業最核心的軟件交付流水線暴露在完全不受控制的風險之下。

更令人擔憂的是，Bitrise 並非孤例。審計發現，大量 MCP 伺服器在設計時將「功能完整性」置於「安全性」之上，似乎假設所有調用者都是可信的。這種設計哲學在封閉的開發環境中或許勉強可以接受，但在 MCP 快速走向生產部署的今天，它已經成為一種危險的疏忽。

命令注入：老漏洞遇上新攻擊面

43% 的熱門 MCP 實現存在命令注入漏洞——這個數字之所以令人震驚，不在於漏洞本身的技術複雜性，而在於它揭示了一個更深層的問題：MCP 生態系統正在大規模重蹈 Web 應用早期的安全覆轍。

命令注入是一種存在了數十年的經典漏洞類型。當一個應用程序將用戶輸入直接拼接到系統命令中而不進行適當過濾時，攻擊者就可以注入任意命令。在 MCP 的語境下，這個問題被 AI Agent 的特性放大了數倍：

• 輸入來源不可控：AI Agent 的輸入可能來自用戶對話、網頁內容、電子郵件、文檔——任何一個來源都可能被注入惡意內容
• 鏈式調用放大效果：一個 MCP 工具的輸出往往成為另一個工具的輸入，單個注入點可以沿著工具鏈傳播
• 語義理解的雙刃劍：大型語言模型能夠理解自然語言指令，這使得精心構造的提示注入可以繞過簡單的關鍵詞過濾

想像一個場景：一個 AI Agent 被配置為透過 MCP 連接 Git 倉庫管理工具。攻擊者在一個 Pull Request 的描述中嵌入惡意的命令注入載荷。當 Agent 讀取這個 PR 並將內容傳遞給 MCP 伺服器進行處理時，注入的命令在伺服器端被執行——這不再是理論上的攻擊路徑，而是已經被證實的現實。

Anthropic 自家的三個 CVE：信任危機

或許最諷刺的發現是，MCP 協議的創建者 Anthropic 自身提供的 Git MCP 伺服器中，被發現了三個可實現遠端代碼執行（RCE）的 CVE 漏洞。攻擊向量是通過提示注入——攻擊者可以在 Git 倉庫的內容（如 README 文件、程式碼註釋、提交訊息）中嵌入精心構造的惡意指令，當 AI Agent 透過 MCP 讀取這些內容時，觸發遠端代碼執行。

這個發現的意義遠超漏洞本身。它傳遞了一個清晰的信號：即便是最了解 MCP 協議設計意圖的團隊——它的創造者——也未能在自家實現中避免嚴重的安全缺陷。如果 Anthropic 的參考實現都存在 RCE 漏洞，那麼社區中數以千計的第三方 MCP 伺服器的安全狀況可想而知。

「當協議的設計者自己都無法寫出安全的實現，這告訴我們問題不在於個別開發者的疏忽，而在於 MCP 的安全模型從根本上需要重新審視。協議規範本身需要將安全性從『建議遵循的最佳實踐』提升為『必須滿足的強制性要求』。」

更大的圖景：Agentic AI 攻擊面的全面擴張

MCP 的安全問題並非孤立存在，它是 Agentic AI 安全態勢急劇惡化的一個縮影。過去數月，多項發現勾勒出一幅令人擔憂的全景圖。

Microsoft 發現 AI 推薦投毒攻擊

Microsoft 安全研究團隊發現了一種被 MITRE ATLAS 編目為 AML.T0080 的新型攻擊技術——AI Recommendation Poisoning（AI 推薦投毒）。這種攻擊的核心在於操控 AI Agent 的工具選擇過程：攻擊者透過污染 MCP 伺服器的元數據描述、在社區註冊表中植入誤導性的工具資訊，引導 AI Agent 選擇惡意的工具或數據源。在 MCP 生態中，這意味著一個偽裝成合法數據庫查詢工具的惡意 MCP 伺服器，可以透過優化其工具描述來提高被 AI Agent 選中的概率，從而竊取查詢中包含的敏感數據。

MITRE ATLAS 新增 Agentic AI 攻擊技術

MITRE ATLAS 框架——AI 系統威脅分類的行業標準——近期新增了多項專門針對 Agentic AI 的攻擊技術。其中最值得關注的是「AI Agent Clickbait」（AML.T0100），這種攻擊利用 AI Agent 自主瀏覽網頁的能力，透過精心設計的網頁內容誘導 Agent 執行非預期操作。當這種攻擊與 MCP 工具鏈結合時——例如一個被誘導訪問惡意網頁的瀏覽器 Agent 將頁面內容傳遞給一個存在命令注入漏洞的 MCP 伺服器——攻擊的殺傷力將呈指數級放大。

Zenity 擴展 Agentic 瀏覽器安全

安全公司 Zenity 的最新動作也印證了威脅的現實性。該公司宣布將其 AI 安全防護能力擴展至覆蓋新一代的 Agentic 瀏覽器——包括 ChatGPT 的 Atlas 瀏覽器、Perplexity 的 Comet、以及 The Browser Company 的 Dia。這些瀏覽器被設計為能夠自主執行複雜的網頁操作，而非僅僅展示內容。當它們透過 MCP 連接到更廣泛的工具生態時，每一個瀏覽器實例都成為了一個潛在的攻擊入口。Zenity 的業務擴展方向清楚地表明，市場已經認識到 Agentic 瀏覽器與 MCP 工具鏈的結合創造了全新的攻擊面。

Google 揭示國家級模型竊取威脅

Google 的威脅情報團隊報告稱，已偵測到超過 100,000 次來自國家級行為者的模型提取嘗試。雖然模型竊取與 MCP 安全是不同的威脅類別，但它們共同指向同一個結論：AI 基礎設施已成為高價值攻擊目標。國家級威脅行為者的介入意味著攻擊的持續性、精密度和資源投入都將遠超普通黑客攻擊。在這樣的威脅環境下，MCP 伺服器 41% 的零認證率無異於在城牆上留下了一個巨大的缺口。

為甚麼 MCP 安全問題如此棘手？

理解 MCP 安全問題的根源，需要回到協議的設計哲學。MCP 在誕生之初的首要目標是解決 N×M 整合問題——讓任何 AI 模型能夠連接任何工具。為了最大化採納速度，協議規範在安全性方面採取了「建議性」而非「強制性」的立場。身份認證、輸入驗證、權限控制等安全機制被視為「實現者的責任」，而非協議層面的硬性要求。

這個設計決策在早期是有其合理性的。一個過於嚴格的安全框架可能會顯著降低開發者的採納意願，畢竟在概念驗證階段，「能跑起來」遠比「安全地跑」更受重視。但問題在於，MCP 的採納速度遠超預期——它幾乎跳過了通常標準化過程中「從實驗到生產」的安全加固階段，直接從概念驗證進入了企業部署。

另一個結構性問題是 MCP 的「工具發現」機制。MCP 允許 AI Agent 動態發現和調用伺服器上的可用工具，這是其靈活性的核心所在。但這也意味著，一個 Agent 可能在運行時接觸到它在設計時從未預見過的工具。如果這些動態發現的工具沒有認證門檻，Agent 就可能被引導去調用危險的操作——這正是 Bitrise 案例所暴露的風險。

「MCP 的安全困境本質上是一個經典的『可用性與安全性』權衡問題，只不過它被 AI Agent 的自主性放大到了前所未有的程度。在傳統 API 中，不安全的端點至少需要人類開發者去主動調用。但在 MCP 生態中，AI Agent 可以自主發現並調用任何暴露的工具——這將攻擊面從『開發者已知的端點』擴展為『所有可發現的端點』。」

企業應該做甚麼？

面對這些風險，已經或正在部署 MCP 的企業需要立即採取行動。以下是一套分層防禦策略：

1. MCP 伺服器安全審計

對所有已部署和計劃部署的 MCP 伺服器進行全面安全審計。重點檢查：是否實施了協議層認證？工具輸入是否經過嚴格的參數驗證？是否存在命令注入、路徑遍歷等常見漏洞？對於第三方 MCP 伺服器，應要求供應商提供獨立的安全評估報告。

2. 強制認證閘道

在 MCP 客戶端與伺服器之間部署認證閘道（Authentication Gateway），強制要求所有 MCP 請求攜帶有效的身份憑證。即便底層 MCP 伺服器本身不實現認證，閘道層也能提供一道額外的安全屏障。這類似於在微服務架構中使用 API Gateway 統一管理認證的做法。

3. 工具白名單與最小權限

不要依賴 MCP 的動態工具發現機制來決定 Agent 可以調用甚麼。為每個 Agent 配置明確的工具白名單，只允許它調用完成特定任務所需的最少工具。「delete_app」這樣的高危操作應該被完全排除在自動化工具鏈之外，或至少需要人工審批。

4. 輸入消毒與輸出監控

在 MCP 工具鏈的每個環節實施嚴格的輸入消毒（Input Sanitization）。特別要注意 AI Agent 從外部來源（網頁、郵件、文檔）獲取的內容，因為這些是提示注入攻擊的主要載體。同時，監控 MCP 工具的輸出，檢測異常模式——例如一個本應返回數據庫查詢結果的工具，輸出中卻包含系統命令的執行結果。

5. 沙盒隔離與網絡分段

將 MCP 伺服器部署在隔離的網絡環境中，限制它們能夠訪問的內部資源。即便一個 MCP 伺服器被攻破，攻擊者也無法輕易橫向移動到企業核心系統。對於處理敏感數據的 MCP 伺服器，考慮使用容器沙盒或微虛擬機來提供額外的隔離層。

6. 持續安全測試

將 MCP 工具鏈納入企業的持續安全測試流程中。定期進行紅隊演練，模擬提示注入、工具投毒、命令注入等攻擊場景。建立自動化的安全掃描管道，在每次 MCP 伺服器更新後自動執行漏洞檢測。

協議層面需要甚麼改變？

個別企業的防護措施固然重要，但真正的長期解決方案必須來自協議層面的改革。Agentic AI Foundation（AAIF）作為 MCP 的現任治理機構，需要在以下方面採取行動：

• 強制性認證要求：將身份認證從「建議」提升為規範的強制性要求。任何聲稱符合 MCP 規範的伺服器都必須實現至少一種標準化的認證機制（如 OAuth 2.0、mTLS 或 API Key）
• 工具安全分級：建立工具的安全分級體系，根據操作的破壞性將工具分為不同的安全級別（如「唯讀」、「可寫」、「破壞性」），並為每個級別規定最低安全要求
• 輸入驗證規範：在協議層面定義標準化的輸入驗證框架，而非將其完全交由個別實現者自行處理
• 安全認證計劃：建立 MCP 伺服器的安全認證計劃，類似於 SOC 2 合規認證，為企業選擇第三方 MCP 工具提供可信的安全基線
• 漏洞披露與回應機制：建立統一的 MCP 生態安全漏洞披露與回應流程，確保已知漏洞能夠被快速修復和通報

歷史的教訓：Web 安全演進的啟示

MCP 今天面臨的安全困境，與早期 Web 技術的經歷有著驚人的相似性。1990 年代末到 2000 年代初，Web 應用的爆發式增長同樣伴隨著安全問題的大規模暴發——SQL 注入、跨站腳本（XSS）、跨站請求偽造（CSRF）——這些漏洞在 Web 發展早期幾乎無處不在，因為開發者和框架都還沒有建立起安全意識和防護機制。

Web 安全的成熟花了將近十年時間，經歷了無數次大規模數據洩露事件，才最終催生了 OWASP Top 10、內容安全策略（CSP）、HTTPS Everywhere 等標準化的安全實踐。問題在於：AI Agent 的發展速度遠快於 Web 應用，而其潛在危害也遠大於傳統 Web 攻擊。一個被攻破的網站可能洩露用戶數據；一個被攻破的 AI Agent 可以自主地執行一系列破壞性操作，從刪除代碼倉庫到發送欺詐性郵件，從篡改數據到操控業務流程。

我們不能等待另一個十年的痛苦學習。MCP 安全的加固必須與其採納同步推進——而不是在災難發生之後再亡羊補牢。

對香港企業的特別警示

香港作為國際金融中心和企業密度極高的商業社會，在 AI Agent 部署上面臨獨特的風險敞口。本地金融機構和專業服務公司正積極探索將 AI Agent 接入交易系統、合規審查、客戶服務等核心業務流程。如果這些整合建立在不安全的 MCP 基礎之上，後果不堪設想。

根據《個人資料（私隱）條例》的要求，數據控制者有義務採取切實可行的措施保護個人數據。如果企業透過存在安全缺陷的 MCP 伺服器處理客戶數據，一旦發生洩露事件，將面臨法律責任。香港金管局和證監會對金融機構的 IT 風險管理亦有嚴格要求——AI Agent 工具鏈的安全性必須被納入這些監管框架的評估範圍。

建議香港企業在部署 MCP 前，聘請獨立的安全評估機構對整個工具鏈進行滲透測試，並將 MCP 安全風險納入企業風險管理框架的定期評估項目中。