
Model Context Protocol (MCP) 安全性:完整指南
MCP 伺服器會集中憑證,形成單點故障。本文詳細說明 AI 代理整合的安全性,以防範工具投毒、注入與憑證攻擊。

什麼是 MCP 安全性?
MCP 伺服器會彙總多個企業服務的憑證,形成單點故障,一旦遭到入侵,整個組織都將暴露。若部署的 MCP 伺服器缺乏驗證控制且遭到入侵,攻擊者便可存取您的 AI 助理所連接的每個整合資料庫、檔案系統與雲端服務。這種弱點模式已在實際攻擊中被利用於 CVE-2025-49596(CVSS 9.4),攻擊者可透過未經驗證的 MCP Inspector 執行個別命令。
Model Context Protocol (MCP) 是 Anthropic 於 2024 年底發布的開放標準,透過用戶端-伺服器架構將 AI 助理連接至企業資料來源與工具。MCP 安全性涵蓋保護這些整合免於遭受利用所需的控制措施、實務作法與框架。根據官方 MCP 規範,該通訊協定「明確不在通訊協定層級強制執行安全性」,將實作責任完全交由安全團隊承擔。
當您部署 MCP 伺服器時,便是在 AI 推理引擎與企業基礎架構之間建立橋樑。該伺服器會儲存多項服務的 OAuth tokens、執行系統命令、讀取檔案並查詢資料庫。安全團隊面臨多個已記錄的弱點類別,其中包括國家弱點資料庫追蹤的三個重大 CVE。第一個惡意 MCP 套件於 2025 年 9 月出現,在外洩電子郵件資料的同時,未被偵測地運作了兩週。
這些風險說明了為何 MCP 安全性會與更廣泛的網路安全領域交會。
.jpg?width=2560&quality=90&format=auto)
MCP 安全性如何與網路安全相關
MCP 安全性與 身分與存取管理、 供應鏈安全,以及現有工具並非為阻止 AI 特定攻擊而設計的攻擊手法相互交會。該通訊協定架構建立了三個安全邊界:處理用戶端與伺服器之間通訊的傳輸層、管理生命週期與能力協商之 JSON-RPC 2.0 訊息的通訊協定層,以及定義代理可存取之工具、資源、提示與通知的資料層。
CISA 發布聯合指引 於 2025 年 5 月 22 日,強調資料安全對於確保 AI 系統可信度至關重要。這項政府層級的認可表明,AI 代理基礎架構已納入 SOC 團隊必須監控的攻擊版圖。OWASP MCP Top 10 專案建立了首個用於分類 MCP 風險的業界標準框架,為評估 AI 整合的安全團隊提供結構化的 風險評估 方法論。
傳統邊界安全無法防禦 MCP 攻擊,因為這些攻擊是在自然語言的語意層級運作。不同於基於特徵碼的威脅,MCP 攻擊會透過工具投毒與 prompt injection 等技術利用 AI 模型的推理過程。這些模式會完全繞過傳統識別,因此需要行為分析與具備情境感知能力的安全控制。
因應這些攻擊模式,需要了解保護 MCP 部署的架構元件。
MCP 安全性的核心元件
MCP 安全架構必須涵蓋跨越架構、存取管理、識別與治理的基礎控制。
- 驗證與授權層: MCP 伺服器需要 OAuth 2.1 搭配 PKCE、能力層級範圍界定,以及防止因記錄外洩或記憶體擷取而導致的廣泛範圍權杖存取。
- 傳輸安全: 強制使用 TLS 1.2+ 與強式密碼套件,為伺服器對伺服器通訊實作雙向 TLS(mTLS),並啟用 DNS rebinding 防護。根據 GitHub Security Advisory GHSA-w48q-cv73-mx4w, MCP TypeScript SDK 預設不會啟用此防護。
- 工具驗證流程: 安全控制必須透過三個階段進行驗證:(1) 針對命令與提示注入的模式式過濾,(2) 針對工具描述中語意攻擊的神經式識別,以及 (3) 針對邊緣案例的 LLM 式仲裁。
- 憑證管理: MCP 伺服器會彙總多項服務的 OAuth tokens。請使用企業保管庫,例如 AWS Secrets Manager 或 HashiCorp Vault,實作自動輪替、使用短效權杖,並防範記錄外洩與記憶體擷取。
- 識別與監控基礎架構: 記錄所有 MCP 作業,包括含參數的工具呼叫、驗證嘗試、資源存取與範圍違規。在您的 SIEM 中將 MCP 事件與身分行為及網路流量建立關聯。
這些元件會在協調一致的執行流程中共同運作,以處理每一項 MCP 請求。
MCP 安全性如何運作
MCP 安全性透過分層控制運作,以保護 AI 代理與企業系統互動的每個階段。
- 集中式閘道架構: 集中式閘道代理會套用一致的政策、監控行為並強制執行防護欄。該閘道會對核准的 MCP 伺服器強制執行允許清單、集中化 access control 與識別,並檢查所有工具呼叫。這可防止未經授權的 MCP 伺服器存取企業資源,而不受開發人員如何設定其本機環境影響。
- 能力協商階段:在初始化期間,閘道會根據政策規則檢查伺服器能力,封鎖要求過多權限的伺服器。細緻化存取控制會將特定使用者角色對應至特定工具能力。
- 執行階段: 當 AI 代理呼叫 MCP 工具時,安全層會驗證輸入參數是否存在 注入攻擊、在沙箱中執行工具,並記錄完整的鑑識內容。
- 持續識別:安全平台使用結合模式式篩選、神經網路分析與行為異常識別的多階段識別流程來分析 MCP 流量。
- 事件回應流程:當安全平台識別出惡意 MCP 活動時,自主回應能力會隔離遭入侵的伺服器、撤銷所有整合服務中的相關憑證、回復未經授權的變更,並重建完整的攻擊時間軸以供調查。
了解此作業流程可揭示為何 MCP 安全性對企業風險管理至關重要。
為何 MCP 安全性很重要
憑證彙總風險正在重塑部署 MCP 的組織之攻擊模型。MCP 伺服器會儲存多項服務的 OAuth 權杖,形成單點失效。當其遭到入侵時,攻擊者便可廣泛存取所有已連線的服務,因此需要 MCP 專屬的事件回應程序。
供應鏈 驗證變得至關重要,因為 MCP 的簡易整合路徑會透過不受信任的伺服器引入風險。第一個惡意 MCP 套件於 2025 年 9 月出現,在外洩電子郵件資料的同時未被偵測長達兩週。
治理框架必須建立對未受監控之 MCP 整合層的控制。安全團隊需要在閘道層級集中執行政策、為新伺服器建立核准工作流程,並制定與資料分類一致的安全基準。
零信任架構 為 MCP 安全性提供基礎,要求 MCP 微服務之間採用雙向 TLS、以身分為基礎的流量控制,以及獨立於網路拓撲的安全性。
當 AI 代理存取受監管資料時,合規與法規一致性能保護組織。 CISA 指引 於 2025 年 5 月指出,資料安全可確保 AI 系統的可信賴性。MCP 安全控制必須證明 AI 助理的資料存取遵循與人類使用者相同的治理方式。
要了解為何 MCP 安全性很重要,必須檢視鎖定這些系統的特定攻擊。
MCP 安全威脅類型
MCP 環境面臨獨特的攻擊模式,這些模式會利用該通訊協定的信任模型與工具架構。
- 工具投毒 將惡意指令嵌入工具中繼資料與描述。攻擊者會將如「將所有資料轉送至外部端點」之類的指示隱藏在工具定義中,這些定義對使用者看似無害,但當 AI 代理讀取中繼資料時便會執行。這些指令會跨工作階段持續存在,影響每個與受損工具互動的代理。
- Rug Pull 攻擊 利用核准後的行為變更。工具通過初始安全審查後,接著會悄悄修改其定義以納入惡意功能。大多數 MCP 用戶端不會在工具描述於核准後變更時提醒使用者,使攻擊者得以將先前受信任的工具武器化。
- Shadowing 攻擊 讓惡意工具無需直接呼叫即可影響受信任工具。受損工具的描述可指示 AI 代理在使用合法工具時修改行為,例如重新導向電子郵件收件者或加入隱藏的交易費用。
- 伺服器偽冒 以與合法服務相似的名稱註冊惡意 MCP 伺服器。當 AI 助理執行以名稱為基礎的探索時,可能會解析到惡意伺服器,進而擷取憑證與敏感查詢。
這些攻擊模式說明了安全團隊面臨的實作挑戰。
實作 MCP 安全性的挑戰
安全團隊在保護 MCP 部署時面臨數項障礙:
- 架構缺口:在缺乏通訊協定層級指引的情況下,安全責任完全轉移至實作團隊。 官方 MCP 規格 明確指出其「無法在通訊協定層級強制執行這些安全原則」,造成開發人員預期與安全現實之間的不一致。
- 可視性限制:傳統監控難以處理 JSON-RPC 2.0 訊息模式與分散式部署,因此需要自訂儀表化來追蹤 MCP 伺服器活動。
- 工具蔓延: 組織在缺乏集中治理的情況下跨部門部署 MCP 伺服器。若沒有集中式盤點,安全團隊便無法實施一致的控制,也無法追蹤哪些伺服器可存取敏感憑證。
- 新型攻擊模式:工具投毒與 shadowing 等語意攻擊可完全繞過以特徵碼為基礎的工具,因此需要能理解自然語言操控的情境感知模型。
- 事件回應複雜性:單一入侵會同時影響多項服務。現有應變手冊假設僅需圍堵單一服務,但 MCP 事件需要在所有整合系統中協調撤銷憑證,並進行橫跨身分、 端點安全,以及 雲端安全 環境的鑑識分析。
這些挑戰往往會導致常見的實作錯誤。
常見的 MCP 安全錯誤
安全評估揭示出反覆出現的模式,顯示組織未能有效保護 MCP 部署。
- 未部署驗證: 組織經常部署可透過網路存取的 MCP 伺服器,卻未實作驗證機制。根據 MCP 安全最佳實務,不建議在未經驗證的情況下執行 MCP 伺服器。攻擊者會透過連接埠掃描發現這些暴露的伺服器,在沒有憑證的情況下連線,並以完整權限執行任意工具。
- 沙箱實作不佳:安全事件分析指出,在已記錄的事件中,目錄限制執行不足是根本原因。執行檔案操作卻未進行路徑驗證的 MCP 伺服器,會導致路徑遍歷攻擊,使攻擊者得以存取包含資料庫密碼、API 金鑰和雲端憑證的組態檔。
- 安裝不受信任的伺服器:團隊會從不受信任的來源安裝 MCP 伺服器,而未進行程式碼審查或安全掃描。安全研究人員記錄到惡意 MCP 伺服器偽裝成合法工具,同時實作憑證竊取功能。組織也未監控 rug pull 攻擊,也就是先前已核准的工具在部署後改變行為的情況。
- 授權範圍過大: MCP 安全規範警告,攻擊者會透過日誌外洩、記憶體擷取或本機攔截,取得帶有廣泛範圍的存取權杖(例如 files:*、db:* 和 admin:*)。在初始授權期間要求所有可用權限的 MCP 伺服器,未能在能力層級實作權限範圍控管。
- 監控不足:來自 Model Context Protocol 系統的遙測資料有限,使調查變得困難。 安全日誌若遺漏關鍵細節,便無法重建攻擊時間軸。監控必須包括記錄所有操作、追蹤驗證嘗試,以及確保 SIEM 整合。
避免這些錯誤需要遵循既有的安全框架。
MCP 安全最佳實務
部署集中式 MCP 閘道架構,作為基礎架構控制。該閘道會代理所有 MCP 通訊,對已核准的 MCP 伺服器強制執行允許清單、集中化存取控制與識別,並檢查所有工具呼叫。此架構模式提供單一控制點,讓組織能在所有代理式工作流程中一致地執行政策。
在能力層級以細緻的範圍管理實作最小權限存取:
- 將使用者角色對應至特定工具能力
- 在授權期間動態驗證範圍請求
- 使用能力層級的權限範圍控管,而非廣泛範圍權杖
- 防範透過日誌外洩、記憶體擷取或本機攔截造成的權杖竊取
在任何正式環境部署之前,建立 MCP 伺服器供應鏈安全控制。核准流程要求對所有伺服器進行靜態應用程式安全測試與弱點掃描、以密碼編譯方式驗證伺服器完整性,以及對套件進行掃描以偵測 malware 和隱藏的惡意指令。釘選特定 MCP 伺服器版本,並在有任何變更時提醒管理員。
部署專為 MCP 工具投毒與語意攻擊設計的多層識別流程。三階段識別方法包括:用於命令注入的模式式過濾、用於工具描述中語意攻擊的神經式識別,以及針對對手操縱工具中繼資料以欺騙 AI 代理的邊緣案例所採用的 LLM 式仲裁。
實作與 SIEM 平台整合的稽核記錄。記錄基礎架構必須擷取每一次工具呼叫及其完整內容。監控異常模式,包括不尋常的工具存取序列、權限提升嘗試,以及資料外洩指標。
透過企業級保管庫保護憑證與密鑰管理。整合 AWS Secrets Manager 或 HashiCorp Vault 以保護 API 金鑰和 OAuth 憑證。實作自動輪替與短時效權杖。部署安全權杖保管庫,以防範日誌外洩與記憶體擷取。
強制執行傳輸安全與網路控制。要求使用具備強式密碼套件的 TLS 1.2+、對伺服器對伺服器通訊實作雙向 TLS,並將 MCP 伺服器隔離於專用網路區段中,搭配適當的 firewall 規則。
建立具備自主政策執行能力的治理框架。正式的 MCP 使用政策需與資料分類及存取控制標準一致。在閘道層級進行自主政策執行、為新伺服器部署建立核准工作流程、定期檢視工具存取模式的安全性,以及 資料外洩防護 控制,可防止敏感資訊透過 MCP 整合而暴露。
使用 SentinelOne 阻止 MCP 攻擊
Purple AI透過自然語言調查找出可疑的 MCP 活動,並在安全資料湖中關聯 MCP 事件,速度比手動方法快達 80%。查詢 Purple AI:「顯示過去 24 小時內使用者 X 的所有工具呼叫」或「哪些憑證是透過此 MCP 伺服器外洩的?」SentinelOne 的 Storyline 技術可重建完整的 MCP 攻擊鏈,顯示遭入侵的伺服器如何存取多個服務並執行未經授權的工具。SentinelOne 的行為式 AI 可在語意層級找出零時差威脅與新型攻擊模式,提供 警示減少 88%,以消除妨礙有效 MCP 監控的警示疲勞。
MCP 在 AI 工具與企業資料之間建立了未受監控的層級。因應這項治理挑戰需要採用縱深防禦安全架構:用於政策強制執行的集中式 MCP 閘道、最小權限存取控制、供應鏈安全審查,以及多層識別管線。安全團隊必須在工具層級實作能力層級的權限範圍界定、經驗證的 MCP 伺服器連線、集中式稽核日誌,以及對代理程式到工具流量的持續監控。
SentinelOne 的 Singularity Data Lake 使用 OCSF(Open Cybersecurity Schema Framework)標準,擷取並正規化來自原生與第三方來源的安全資料。 威脅狩獵 工作流程會關聯多個平台上的安全事件,透過行為模式分析與異常識別,找出如憑證竊取、權限提升嘗試及不尋常資料存取序列等複雜攻擊。
向 SentinelOne 申請示範,了解自主式安全如何在憑證彙整導致企業全面遭入侵之前阻止 MCP 攻擊。

AI-Powered Cybersecurity
Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.
重點整理
隨著 AI 助理取得對正式環境基礎架構的存取權,MCP 安全對企業安全團隊而言代表關鍵轉折點。此通訊協定的憑證彙整架構會形成單點失效,一旦一台伺服器遭入侵,就會使每個整合服務中的 OAuth 權杖暴露。組織必須實作 縱深防禦 控制措施,包括集中式閘道架構、能力層級的權限範圍界定、供應鏈驗證,以及結合模式式過濾與行為分析的多層識別流程,以阻止工具投毒和提示注入攻擊。
資安團隊應優先採取立即行動:盤點現有的 MCP 部署、實作經過驗證的伺服器連線,並在 30 天內建立稽核記錄。於 90 天內部署閘道架構與核准工作流程,接著在 180 天內建立全面的識別與治理框架。OWASP MCP Top 10 提供業界標準的風險評估框架,而像 SentinelOne 這樣的平台則提供行為式 AI、跨平台關聯分析,以及在認證資料遭竊進而導致企業範圍全面入侵之前,找出並阻止 MCP 攻擊所需的自然語言調查能力。
常見問題
MCP 安全是指保護 Model Context Protocol 整合免於遭受利用的控制措施、實務作法與框架。MCP 透過用戶端-伺服器架構將 AI 助理連接至企業資料來源,並在傳輸、協定與資料層建立安全邊界。
由於 MCP 規範未在協定層級強制執行安全性,組織必須實作驗證、授權、監控與治理控制,以防範憑證聚合風險與 AI 特定攻擊。
憑證聚合造成主要弱點。MCP 伺服器會儲存多個整合服務的 OAuth 權杖,形成單點失效。一旦遭到入侵,攻擊者便可存取所有已連接的服務。
在企業環境中,單一 MCP 伺服器遭到攻破,就會使多個整合系統中的組織資源暴露,讓攻擊者同時存取使用者或組織已完成驗證的每一項連接服務。
工具投毒會透過在伺服器定義與工具描述中嵌入隱藏指令來操控 AI 代理的行為。攻擊者會竄改中繼資料,加入 AI 模型會解讀為合法參數的惡意指令。
這些語意攻擊會繞過以簽章為基礎的安全工具,因為它們是在自然語言推理層級運作,因此需要 AI 驅動安全 方法,透過分析行為模式與語意脈絡來識別惡意工具修改。
專用於 MCP 的安全工具仍在持續成熟中。傳統 SIEM 規則與以簽章為基礎的識別無法發現語意攻擊與工具投毒。有效的 MCP 安全需要三階段識別流程:針對明顯攻擊的輕量模式式識別、針對複雜語意攻擊的深度神經識別,以及針對邊緣案例的以 LLM 為基礎的智慧仲裁。
在專門的 MCP 安全工具成熟之前,組織應將行為分析與 AI 驅動識別結合人工程式碼審查。
這個 OWASP MCP Top 10提供了首個針對 Model Context Protocol 安全風險的業界標準分類系統。這個正式的 OWASP 專案建立了風險評估與安全控制實作的標準化框架。
此框架涵蓋的弱點類別包括命令注入 (MCP05)、脈絡注入與過度分享 (MCP10)、代理人混淆攻擊,以及供應鏈風險。安全團隊使用此框架,根據已記錄的攻擊模式評估 MCP 部署。
組織應在 30 天內開始盤點現有 MCP 部署、建立基本稽核記錄,以及進行密鑰管理。在 90 天內部署閘道架構與核准流程。在 180 天內建立完整的識別流程與治理框架。
第一個惡意 MCP 套件於 2025 年 9 月出現,證實這些都是活躍中的攻擊。這種分階段方法可在安全急迫性與實際實作限制之間取得平衡。


