安全與治理

MCP 安全強化清單：1,467 台暴露伺服器以及關閉它們的方法

作者：IdeaBosque最後更新：2026年7月27日

undefined

Trend Micro 掃描了網際網路，發現 1,467 個 MCP 伺服器裸露在外——沒有認證、沒有加密、任何人都能存取。Practical DevSecOps 發現 2,614 個受調查伺服器中有 82% 存在路徑遍歷漏洞。一個為將 AI 代理接入企業系統而設計的協定在發布時沒有生產安全基線，部署模式也證明了這一點：大多數團隊在加固 MCP 之前就把它暴露到了網際網路。這份清單是本應最先到來的基線——涵蓋傳輸、認證、工具註冊、執行時和稽核的 12 項控制，每一項都能在五分鐘內驗證完畢，確保 MCP 伺服器在承接生產流量之前達標。

關鍵要點

1,467 台 MCP 伺服器公開可存取且零認證零加密 — Trend Micro 修正後的掃描，2026 年 7 月。其中 1,227 台執行 2026-07-28 規範以 12 個月棄用時鐘淘汰的 SSE 傳輸。
2,614 台受調查 MCP 伺服器中 82% 易受路徑遍歷攻擊，僅 8.5% 使用 OAuth — Practical DevSecOps MCP Security Statistics 2026 Report。這些攻擊類別在已部署伺服器中廣泛存在，不是理論性的。
2026 年 7 月官方 MCP Python SDK 中出現 3 個 CVE — CVE-2026-59950（DNS rebinding/CSRF）、CVE-2026-52869（未驗證的工作階段請求）、CVE-2026-52870（開放任務處理器）。參考實作與它支撐的社群伺服器存在同類缺陷。
5 台 MCP 伺服器連接 1 個 agent 時攻擊成功率达 78.3% — Palo Alto Networks Unit 42。五台伺服器是典型部署，不是大規模部署。OX Security 識別出一個影響 150M+ 下載量的架構級 RCE，Cloud Security Alliance 將 MCP 安全歸類為系統性設計缺陷問題。
MCP 2026-07-28 規範於 2026 年 7 月 28 日正式發布 — 四個 Tier 1 SDK（TypeScript、Python、Go、C#）在發布日均支援新的無狀態核心，SSE 傳輸有 12 個月棄用策略。遷移和強化是同一項工作。
Deadbugz 把執行時變成攻擊面：中繼資料投毒潛伏到你信任伺服器為止 — Pillar Security 於 2026 年 9 月 23 日揭露一場活躍的 MCP 供應鏈攻擊行動：74 分鐘內提交的 23 個 pull request 提供了一個「productivity-suite」伺服器，它在前三次工具呼叫中表現正常，隨後改寫自身工具中繼資料，去搜尋 SSH 金鑰、AWS 憑證、shell 歷史和 Kubernetes 設定（Pillar Security）。核准時掃描看不見它——見下方 2026-09-30 更新。

通過這份清單 12 項控制的生產 MCP 部署不是不可入侵的——沒有任何系統是——但它不再屬於 Trend Micro 發現的、Practical DevSecOps 掃描的、或 7 月 CVE 波捕獲的那批伺服器。清單將每項控制對映到它所解決的 OWASP MCP Top 10 類別、它所預防的 CVE 或暴露、以及操作員可在五分鐘內執行的驗證步驟。Microsoft Agent Governance Toolkit——首個具備 10/10 OWASP MCP Top 10 覆蓋的超大規模廠商開源治理執行時——是參考實作。本文是營運層面的補充：一份可掃描的強化審查，面向準備將 MCP 伺服器暴露於生產流量的工程負責人或平台負責人。

更新 — 2026-08-18：OWASP GenAI MCP伺服器安全基線、MCP專案沙箱基線、MCP Ruby SDK和檔案伺服器漏洞——三個新標準和新的CVE類別

三個發展增加了兩個新的MCP安全標準和新的CVE類別：OWASP GenAI開發基線、MCP專案部署基線、Ruby SDK和檔案伺服器漏洞。

OWASP GenAI MCP伺服器安全基線（8月18日）——開發控制。 安全開發MCP伺服器的實用指南。與OWASP MCP Top 10（風險目錄）和MCP專案沙箱基線（部署控制）形成分層MCP安全框架。
MCP專案沙箱基線（8月16日）——來自規範作者的部署控制。 MCP專案發布安全最佳實踐，要求對生成進程進行沙箱化或容器化。來自協議作者的最權威MCP加固指導。
MCP Ruby SDK和檔案伺服器漏洞（8月16日）——新的CVE類別。 Ruby SDK DoS和路徑驗證不足導致的檔案洩露。MCP CVE目錄現在涵蓋Python、TypeScript、Java、Ruby和C# SDK。參見MCP模組程式碼標準。

更新 — 2026-08-07：Black Hat 2026 MCP 伺服器發現產品 — Cyera、SailPoint、Check Point

完整的 Black Hat 2026 產品清單（crn.com，2026年8月4日）新增了三個直接針對控制 12（影子伺服器偵測）和本清單中 MCP 伺服器可發現性和治理維度的產品。

Cyera Agent Guardian — 影子 MCP 伺服器發現。 Cyera 推出了 Agent Guardian，用於發現企業中的影子 MCP 伺服器和未授權 AI 代理。對於控制 12（影子伺服器偵測），Cyera 是清單和漂移監控模式的產品化版本：無需手動維護 MCP 伺服器清單並與登錄核對，Cyera 自動發現生產中的 MCP 伺服器 — 包括從未註冊的。Trend Micro 發現的 1,467 台暴露伺服器是面向網際網路的；Cyera 解決內部 — 在企業網路內運行但無人知曉的 MCP 伺服器。
SailPoint Identity Security — MCP 伺服器身份治理。 SailPoint 將其 Identity Security 平台擴展到涵蓋 MCP 伺服器身份以及人類和代理身份。對於控制 4（代理身份分離），SailPoint 將 MCP 伺服器新增為受管身份類型 — 每個 MCP 伺服器都有一個由處理人類身份的同一身份治理基礎設施管理的生命週期（配置、證明、撤銷）。
Check Point AI Network Firewall — MCP 通訊監控。 Check Point 推出了 AI Network Firewall，監控 MCP 流量 — 代理與 MCP 伺服器之間的通訊 — 以偵測策略違規和資料外洩。對於控制 9（上下文邊界），Check Point 增加了網路層執行：試圖透過 MCP 回應外洩資料的工具伺服器會在防火牆層面被捕獲，而不僅被代理的上下文範圍邏輯捕獲。

MCP 安全產品類別現在有了專門的供應商用於影子伺服器發現（Cyera）、身份治理（SailPoint）和網路層監控（Check Point）— 本清單 12 項控制所涉及但以前需要客製化建構的三個領域。1,467 台暴露伺服器和 82% 的路徑遍歷暴露是本清單關閉的人群；Black Hat 2026 產品浪潮為操作員提供了規模化關閉它們的供應商工具。

攻擊面，用數字說話

OWASP MCP Top 10（Beta Release v0.1，Phase 3 of 5）編目了 MCP 啟用系統全生命週期的 10 個命名風險類別。背後的數字將「治理是好實踐」變成「治理是生產門控」：

1,467 台暴露伺服器 — Trend Micro 修正後的掃描發現 1,467 台公開可存取的 MCP 伺服器，無認證無加密，從初始計數 492 上升。1,227 台執行棄用的 SSE 傳輸。至少三台透過 progress_note 工具暴露患者醫療記錄。execute_sql 工具出現在 70 台主機上。
82% 路徑遍歷暴露 — Practical DevSecOps 在 2,614 台受調查伺服器中測得 82% 路徑遍歷漏洞和 8.5% OAuth 採用率。97M+ 月度 MCP 下載量意味著暴露隨採用規模增長。
150M+ 下載量受架構級 RCE 影響 — OX Security 將 STDIO 命令注入根因定性為架構級缺陷，而非孤立的 CVE。Cloud Security Alliance 將其歸類為 AI agent 基礎設施中的系統性設計缺陷問題。
2026 年 7 月 SDK 中 3 個 CVE — CVE-2026-59950（缺少 Host/Origin 驗證、DNS rebinding/CSRF）、CVE-2026-52869（未驗證的工作階段請求）、CVE-2026-52870（開放任務處理器）。官方 Python SDK——每個 Python MCP 伺服器繼承的參考實作——與它支撐的社群伺服器存在同類缺陷。
最終規範中的 3 個新攻擊面 — backslash.security 識別出 2026-07-28 規範中無狀態重新設計引入的三個新攻擊面。新能力創造新入口點，安全社群仍在繪製中。

cataam.com 分析精準概括了 MCP 安全現狀：「MCP 安全大致處於十五年前 Web 安全的位置——攻擊手法是舊的，只是目標是新的。」下面的強化清單是將 Web 安全從 82% 路徑遍歷暴露提升到生產系統預期通過的基線的控制集合。同樣的控制在此適用。

12 項強化控制

清單圍繞五個層級組織，對映到 OWASP MCP Top 10 和 MCP 2026-07-28 規範變更：

層級 1 — 傳輸與網路

控制 1：SSE 到 Streamable HTTP 遷移。 MCP 2026-07-28 規範於 2026 年 7 月 28 日正式發布，對 HTTP+SSE 傳輸實施 12 個月棄用策略。四個 Tier 1 SDK（TypeScript、Python、Go、C#）在發布日均支援新的無狀態核心，並附帶破壞性變更遷移說明。Trend Micro 掃描中的 1,227 台棄用 SSE 伺服器是受影響最大的群體——它們執行的是規範正在淘汰的傳輸。**驗證：**檢查伺服器的傳輸設定。如果它提供 SSE，則已進入棄用倒數。在 12 個月窗口關閉前遷移至 Streamable HTTP。

控制 2：網路隔離與來源驗證。 CVE-2026-59950——已在 National Vulnerability Database 中確認——是官方 MCP Python SDK 中缺少 Host/Origin 驗證的缺陷。受害者造訪的網頁可透過 DNS rebinding 和 CSRF 驅動其本地 MCP 伺服器。瀏覽器成為攻擊者進入操作員認為私有的環回伺服器的代理。**驗證：**確認伺服器在每個請求上驗證 Host 和 Origin 標頭。如果伺服器面向網際網路，確認它位於阻止來自不可信來源直接存取的網路邊界之後。一個本不應從公共網際網路可達的伺服器絕不能從公共網際網路存取。

層級 2 — 認證與身分

控制 3：OAuth 2.1 + OIDC 強制執行。 2026-07-28 規範將 OAuth 2.1 加 OpenID Connect 設為強制——從先前的「自帶權杖」方式轉變。WorkOS 認證遷移指南詳述了要求：RFC 8707（Resource Indicators）防止權杖跨伺服器重放，Client ID Metadata Documents 取代 Dynamic Client Registration，issuer 驗證（RFC 9207）。Practical DevSecOps 的發現——僅 8.5% 的受調查伺服器使用 OAuth——是這項控制要提升的基線。**驗證：**檢查伺服器的認證設定。如果它接受未認證請求或使用無 OAuth 的靜態 API key，則不合格。確認伺服器實作 RFC 8707 resource indicators。

控制 4：Agent 身分分離。 NIST AI Agent Standards Initiative（2026 年 2 月）提議將 agent 視為具有自身生命週期的獨立非人類身分：佈建、證明、撤銷。大多數部署認證人類使用者並將該身分傳遞給 agent。當 agent 採取行動時，稽核日誌記錄的是人類做的。**驗證：**確認每個 agent 擁有獨立於人類操作員的憑證（OAuth token、SPIFFE SVID）。撤銷 agent 身分應停止所有 agent 呼叫，而不影響人類的存取。

層級 3 — 工具註冊與供應鏈

控制 5：工具投毒掃描。 OWASP MCP03 將工具投毒列為 top-10 風險：rug pulls（受信任工具安裝後更新為惡意版本）、schema poisoning（介面定義本身被破壞以誤導模型）、tool shadowing（假工具攔截發給真工具的呼叫）。Microsoft Agent Governance Toolkit 的 McpSecurityScanner 偵測工具投毒、typosquatting 和隱藏指令——一個名為 read_flie（typosquatting read_file）的示範工具在描述中注入內容後評分 85/100 風險。**驗證：**檢查工具註冊流程。如果工具在無安全掃描的情況下註冊，則不合格。掃描必須覆蓋描述中的 prompt injection 模式、針對已知工具名的 typosquatting，以及隱藏的系統指令。

控制 6：簽名溯源與依賴監控。 OWASP MCP04 覆蓋供應鏈攻擊和依賴篡改。Postmark MCP 後門——野外捕獲的第一個惡意 MCP 伺服器——是一個看似合法的 npm 套件，靜默攔截並外洩郵件。它通過了註冊審查。UpGuard 的研究發現每 15 個 MCP 伺服器中就有一個是旨在冒充合法服務的 lookalike。**驗證：**確認部署中的每個 MCP 伺服器都有簽名溯源記錄和 AIBOM（AI Bill of Materials）清單。確認依賴監控處於活動狀態並在依賴樹中出現新 CVE 時告警。

控制 7：STDIO 強化。 OX Security 的揭露識別出 STDIO 設定中影響 150M+ 下載量的架構級 RCE。根因：TypeScript SDK 中的 shell: true 透過設定字串啟用了命令注入。Cloud Security Alliance 將此歸類為系統性設計缺陷問題。**驗證：**如果伺服器使用 STDIO 傳輸，確認設定了 shell: false 或等效強化。確認命令 allowlist 檢查參數，而非僅檢查二進位名——Upsonic 和 Flowise 的繞過（CVE-2026-30625、CVE-2026-40933）表明 npx -c <惡意命令> 能通過僅檢查二進位的 allowlist。

層級 4 — 執行時與執行

控制 8：速率限制。 每個工具在註冊呼叫中宣告自己的速率限制。骨幹網按 agent、按工具、按視窗執行限制。當達到限制時，agent 收到帶 Retry-After 標頭的 429 回應。被入侵的 agent 無法耗盡上游 API 配額，因為速率限制在模組邊界執行。**驗證：**確認每個註冊工具都有速率限制。確認限制在模組邊界執行，而非在上游 API 執行。沒有速率限制的工具是被入侵 agent 可無限制呼叫的工具。

控制 9：上下文邊界。 OWASP MCP10 將上下文注入和過度共享列為 top-10 風險。具有廣泛上下文存取權的 agent 會跨租戶、工作階段或使用者洩漏資訊——對於同一 agent 服務於具有不同資料存取權限的多個客戶的 B2B 部署，這一擔憂尤為突出。**驗證：**確認每個工具僅接收其特定操作所需的上下文。確認上下文視窗按工具劃分，而非在所有工具間全域共享。一個在只需單一欄位時接收完整工作階段上下文的工具是資料洩漏面。

控制 10：按模組 kill-switch。 每個 MCP 模組必須能獨立停用，而無需觸碰編排骨幹。kill switch 是設定變更，不是程式碼部署。當漏洞揭露時——如 7 月 CVE 波在兩週內揭露了 3 個 SDK CVE 和 7+ 伺服器 CVE——操作員的首要問題是：我能否在不中斷 agent 的情況下停用此模組？在受治理的部署中，答案是肯定的。**驗證：**確認每個模組可透過 feature flag 或設定變更停用。確認停用路徑已經過測試——不只是設定過。一個從未被觸發過的 kill switch 在需要時將會失效。

層級 5 — 稽核與遙測

控制 11：每次呼叫稽核日誌。 OWASP MCP08 將缺乏稽核和遙測列為 top-10 風險。沒有工具呼叫和上下文變更的日誌，權杖竊取和注入仍然不可見。每次工具呼叫必須記錄時間戳、agent ID、工具名、輸入雜湊（非原始輸入——PII 邊界）、輸出狀態、持續時間和上游系統。日誌是傳送至可觀測性管道的結構化 JSON。**驗證：**確認每次工具呼叫產生結構化日誌條目。確認日誌包含輸入雜湊而非原始輸入。確認日誌不可變——入侵伺服器的攻擊者無法重寫稽核軌跡。

控制 12：影子伺服器偵測。 OWASP MCP09 覆蓋影子 MCP 伺服器——對治理不可見的未批准或未監督部署。UpGuard 發現每 15 個 MCP 伺服器中就有一個是 lookalike。安裝了錯誤的 mcp-server-postgress（注意拼寫錯誤）的工程師獲得了一個靜默外洩 SSH 金鑰和 .env 檔案的套件。**驗證：**確認有部署中每個 MCP 伺服器的清單。確認清單與已知良好套件登錄檔核對。確認 drift 監控在出現不在清單中的新伺服器時告警。

框架如何對映到清單

控制	OWASP MCP	Spec 2026-07-28	Microsoft AGT	NIST	CSA
1. SSE 遷移	—	12 個月棄用	—	—	—
2. 網路隔離	MCP07	來源驗證	—	—	—
3. OAuth 2.1 + OIDC	MCP07	強制認證	—	OAuth 2.0	—
4. Agent 身分	MCP07	—	AgentMesh Identity	SPIFFE/SPIRE	—
5. 工具投毒掃描	MCP03	—	MCP Security Gateway	—	—
6. 簽名溯源	MCP04	—	—	—	—
7. STDIO 強化	MCP05	—	—	—	系統性設計缺陷
8. 速率限制	—	—	Policy Engine	—	—
9. 上下文邊界	MCP10	—	Response sanitizer	—	—
10. 按模組 kill-switch	—	—	Hypervisor kill switch	—	—
11. 每次呼叫稽核日誌	MCP08	—	Audit + metrics	—	—
12. 影子伺服器偵測	MCP09	—	—	—	—

沒有任何單一框架覆蓋全部 12 項控制。清單是 OWASP、規範、Microsoft、NIST 和 CSA 的交集——每個框架貢獻其他框架缺失的控制。Microsoft Agent Governance Toolkit 覆蓋 10/10 OWASP MCP Top 10 類別（7/10 完整，3/10 部分並有路線圖），是首個具備顯式 OWASP 對映的超大規模廠商開源執行時——Agent OS Policy Engine 中 68 項測試，MCP Security Gateway 中 127 項測試，Agent Hypervisor Execution Control 中 80 項測試包括 kill switch。

評分清單

生產就緒的 MCP 伺服器通過全部 12 項控制。部分就緒的伺服器通過 8–11 項。通過少於 8 項的伺服器不應在無文件化補救計畫和每項失敗控制的目標日期下暴露於生產流量。

得分	狀態	行動
12/12	生產就緒	帶監控部署
8–11/12	部分就緒	帶文件化例外和補救時間線部署
<8/12	未就緒	不部署。先補救失敗的控制

最常見的失敗模式是通過控制 1–4（傳輸、認證、身分）而未通過控制 5–12（供應鏈、執行時、稽核）。前四項是架構性的，在設計審查中受到關注。後八項是營運性的，在事件或稽核暴露前常被忽視。2026 年 7 月的 CVE 波——兩週內 3 個 SDK CVE 和 7+ 伺服器 CVE——就是營運控制缺失時的後果。

更新 — 2026-08-08：Skill/Plugin Security Scanning — 廠商側供應鏈緩解

Anthropic 於 2026 年 8 月 6 日發布了 Skill/Plugin Security Scanning — 首個模型廠商側第三方工具伺服器供應鏈緩解措施。該掃描在第三方 Claude Code 上傳（skills 和 plugins）到達 marketplace 之前檢查其是否包含惡意內容。這是營運商對自身工具定義進行掃描的廠商側補充：Control 10（工具投毒防禦）管轄你對自身工具定義的掃描；Skill/Plugin Scanning 管轄模型廠商在其 marketplace 上做的檢查。

digitalapplied.com 框架（2026 年 8 月 6 日）量化了生產差距：88% 的 AI agent 專案從未達到生產，平均失敗專案成本為 $340,000。七種失敗模式佔停滯的 94% — 範圍蔓延（34%）、資料品質（27%）、安全阻礙（14%）、整合複雜性（9%）、成本超支（7%）、治理差距（5%）和組織阻力（4%）。達到生產的 12% 共享四個特徵：更窄的範圍、資料準備投資、並發安全架構和部署前治理。應用結構化故障模式評估的組織將失敗率降至 15% 以下 — 4 倍改善。

更新 — 2026-09-30：Deadbugz 執行時期門控中繼資料污染 — 第四種 MCP 攻擊類別擊穿核准時審查

Pillar Security 於 2026 年 9 月 23 日揭露 Deadbugz——一場活躍的 MCP 供應鏈攻擊行動在 74 分鐘內提交了 23 個 GitHub pull request，每個都提供一台「productivity-suite」MCP 伺服器。這台伺服器在前三次工具呼叫中表現正常；第三次之後，它維護的每客戶端呼叫計數器翻轉自身的中繼資料：後續的 tools/list 和 prompts/get 回應指示已連線的 AI agent 去搜尋 SSH 金鑰、AWS 憑證、shell 歷史和 Kubernetes 設定——並向操作員隱瞞這些活動。該伺服器宣告了 tools.listChanged，因此客戶端無需重新連線即可取得被投毒的定義。Cloud Security Alliance 指出其與較早的「Miasma」攻擊行動在機制上高度相近，橫跨 73 個 GitHub 儲存庫。完整的機制分析見Deadbugz 文章。

這是第四種獨立的 MCP 攻擊類別——接在 STDIO 命令注入、工具投毒和 SHA-pinning 繞過之後——而且正是精準擊穿本清單層級 3 核准時控制的那一種。操作員核准時，Deadbugz 的工具確實是良性的；惡意酬載潛伏在執行時期門控之後。核准時的任何掃描都看不見它，因為在核准時，根本沒有東西可看。偵測面從安裝時移向執行時。

為這份 12 項控制的清單新增一個層級 4 項目：安裝後的工具中繼資料漂移偵測。 記錄伺服器核准時回傳的每一個工具定義的雜湊指紋——名稱、描述、輸入 schema、註記。當伺服器發出 tools.listChanged 訊號時（或按排程），取回新定義，與指紋比對，並將任何差異視為中繼資料漂移安全事件——在被更改的工具能夠影響敏感操作之前，需要操作員重新核准。相同的指紋比對也能捕獲較早的工具投毒類別，因為兩種攻擊共享同一機制：工具定義在核准之後發生改變。**驗證：**連線到已核准的伺服器，進行三次或更多次一般工具呼叫，然後重新取得 tools/list，並將其與核准時的指紋比對差異——Deadbugz 的設計就是要通過每一場在那第四次呼叫之前就停止的審查。

更新 — 2026-10-01：模型級補充——Gemini 4 Argon 在 Gray Swan 的 IPI 基準上領先

上述模組層防禦如今有了一個具名的模型級對應物。Google 於 10 月 1 日 MENA 轉貼的 Argon 公告聲明，藉由自動化紅隊測試與對抗訓練，Gemini 4 Argon「在 Gray Swan 的 Indirect Prompt Injection(IPI)基準上於提示注入穩健性方面居於領先」。這是一條供應商基準宣稱——把它當作待採購證據，在你自己的工作負載上驗證，而不是當作一項控制。架構閱讀依然成立：模型級穩健性降低了成功注入的基率;它不取代層級 3 執行時控制、指紋漂移偵測或出口範圍限定，因為在模型層失效時開放的防禦需要模組層守住。同時部署兩者的部署獲得注入路徑上的縱深防禦;只依賴其一的部署繼承那一層的失效模式。

更新 — 2026-10-02：服務台作為憑證集中點——DIVD ATA 入侵事件

本清單層級 2（認證）與層級 3/4（執行時）控制的攻擊版對應物已落入現實：Sysdig 於 10 月 2 日的分析記錄了一名代理化威脅行為者在 2026 年 9 月 21 日入侵荷蘭漏洞揭露研究院（DIVD）的過程——將兩個 Zammad 服務台零日漏洞——CVE-2026-102489（RCE，CVSS 8.7）與 CVE-2026-102490（LPE，CVSS 8.5）——串聯起來，在數秒內從被劫持的工作階段拿到根權限（Sysdig）。對這份 12 項控制清單而言，這新增了一條系統清點項：一個服務台集中了工作階段 cookie、密碼重置流程與整合權杖——恰是一個串聯到根權限的代理所需要的資產。映射哪些可被代理存取的系統以此方式集中憑證，核驗它們的工作階段劫持姿態（與 Terraform MCP Server 的 CVE-2026-16496 所暴露的同一類別），並在清點控制中把「持有通往憑證密集系統之權杖的代理」視為一個獨立的風險類別——因為在 DIVD 案例中，整條提權鏈正是從這樣一個系統起步的。

更新 — 2026-10-04：按智能體資料庫隔離作為儲存層控制

檢查清單在模型閘道與工具範圍遏制旁獲得一個儲存層控制：按智能體資料庫。Supabase 融資 1.5 億美元並收購 Turso 以供應按智能體資料庫——600% 的資料庫成長歸因於 AI 智能體——把本檢查清單資料外流章節視為假設的東西產品化了。每個智能體一個資料庫時，智能體間資料面的橫向移動在憑證層即告失敗，而審計問題（「哪個智能體寫了這一行？」）由構造本身解決。代價是跨智能體一致性：連接與共享參照資料上行移交給編排層。

更新 — 2026-10-04：MCP Events 訂閱是憑證——且撤銷是不對稱的

檢查清單的憑證管理章節有了新的治理物件類別：MCP Events 訂閱。OpenAI 的機制為 MCP 伺服器加入簽章 webhook 事件訂閱——events/subscribe 建立訂閱，攜帶交付模式、回呼 URL、HMAC 簽章密鑰與 cursor。WorkOS 的表述就是操作性的表述：訂閱本身就是憑證，需要像任何憑證一樣的撤銷、輪換與存取控制。不對稱的部分要明確寫進檢查清單：ChatGPT 支援 webhook 交付模式但不支援 terminated 封套，因此「已撤銷」的訂閱可能持續觸發直到其 TTL——在把撤銷視為即時生效之前，先驗證你的智能體平台兌現的交付模式。

更新 — 2026-10-04：CrewAI 的沙箱逃逸——自 Semantic Kernel 以來首個開源框架 CVE 家族

受治理模組的論題在本輪延伸到開源智能體框架：CrewAI 吸收了五枚 CVE——首推 CVE-2026-37008（經物件圖操縱實現 Python 沙箱逃逸 RCE），加上 CVE-2026-2275（CodeInterpreter RCE，Docker 沙箱與 SandboxPython 回退）、CVE-2026-2285（SSRF）、CVE-2026-2286 與 CVE-2026-2287（本地檔案讀取）——見 CERT/CC 建議 VU#221883。CrewAI 的修補本身就是答案：CodeInterpreterTool 被完全移除，allow_code_execution 被棄用。SandboxPython 的回退鏈——伸手取 Docker、失敗即回退到不安全的本地執行——與 LiteLLM 預設管理員金鑰發現是同一種「不安全預設」模式，如今出現在框架層：檢查清單的沙箱項必須驗證回退以拒絕終止，而非以降級終止。

智慧體 SDK 認證範圍限定（CVE-2026-104873 先例）。 框架 SDK 認證面如今是反覆出現的漏洞類別——CrewAI 的沙箱家族與 LangGraph 的 langgraph-sdk CVE-2026-104873（已在 0.4.4 修復）落在同一週。該缺陷使 actions 範圍限定的認證處理器被全域套用，已登入使用者得以觸及其他使用者的執行緒。檢查清單項：在執行緒/工作階段層獨立於框架的認證處理器預設值驗證按使用者隔離，並鎖定帶有範圍限定修復的 SDK 版本。

更新 — 2026-10-06:三個新的 MCP CVE 類別進入檢查清單——Confluence 檔案讀取、ArcadeDB 權杖暴露、Facebook Ads SSRF

本檢查清單追蹤的 MCP CVE 庫新增三個工具級攻擊面(bonfy.ai《MCP Security Statistics 2026》):CVE-2026-73498(Atlassian Confluence MCP)——confluence_upload_attachment 將用戶端提供的檔案路徑未經校驗直接傳入檔案開啟呼叫,可透過工具路徑參數實現任意檔案讀取;CVE-2026-67357(ArcadeDB MCP)——設定工具將 HA 叢集權杖以明文暴露,足以借特定請求標頭冒充 root——一個新子類:透過工具回應洩漏密鑰;CVE-2026-19956(Facebook Ads MCP 伺服器)——分頁函式中的 SSRF,經身分驗證的遠端呼叫方從伺服器的網路位置發起請求。檢查清單的翻譯:為每個接觸檔案的工具加入路徑校驗(由伺服器校驗,絕非用戶端),稽核工具回應中的密鑰洩漏——而不只是稽核呼叫中的注入——並收斂模組的網路出口,使連接器內的 SSRF 無法轉向內部中繼資料端點。每一類都映射到既有的控制族(輸入校驗、回應稽核、網路隔離)——這正是檢查清單自身的論點:類別每週在變,控制族不變。

更新 — 2026-10-11:AgentCorruption — IMDS 憑證攻擊面抵達託管代理人平台

Zenity Labs 的 AgentCorruption 揭露(2026 年 10 月 8 日,SecTor 多倫多)正是本清單執行階段控制所要應對的憑證暴露類別,這次發生在託管代理人平台上。向 Amazon Bedrock AgentCore 公開代理人發送的一個 prompt 將一個具備 HTTP 能力的工具指向 169.254.169.254,執行個體詮釋資料服務隨即傳回了該代理人預設執行角色的臨時憑證——該角色的作用域不是這一個代理人,而是同一 AWS 帳戶和區域中的所有 AgentCore 代理人。隨後的攻擊鏈完全是 IAM:DescribeLogGroups 列舉每個代理人 ID,InvokeAgentRuntime 觸及使用者從未獲授權的內部代理人,ListEvents 讀取全部私有對話,GetSecretValue 擷取 API 金鑰和 OAuth 權杖,而一個跨代理人的記憶寫入權限植入了在工作階段結束後仍存續的持久行為改變。這與 LiteLLM KEV 文章在閘道層記錄的是同一憑證類別——把一個薄弱邊界變成整個雲端帳戶淪陷的 pass-through 路由——如今抵達平台層,由平台自身的預設值提供了被過度授權的憑證。對執行階段控制族的清單轉譯:在每條模組對外路徑上阻斷 link-local 詮釋資料端點(169.254.169.254),在代理人上線前逐條審讀執行角色政策,並驗證該角色無法列出、呼叫、讀取或寫入帳戶中其他代理人的資源。AWS 於 2026 年 9 月 29 日強化了預設角色——距最初揭露 278 天——這是第二重教訓:已報告與已修復之間的窗口屬於客戶,在任何託管平台上都是如此。完整事件分析見 AgentCorruption 文章。

預設角色而非模型:一個 prompt 如何接管 AWS 帳戶中的所有代理人 — 執行階層憑證控制的實證:託管平台的預設執行角色、作用域涵蓋全帳戶,決定了影響範圍——涵蓋五步攻擊鏈、278 天修復窗口,以及任何託管代理人平台的部署前問題
MCP 伺服器防護成為產品品類:12 項控制的 buy-vs-build 測試 —— 配套文章,評估專用網路產品對本清單 12 項控制能阻斷多少(3 項阻斷、5 項部分涵蓋、4 項仍歸營運方),附 buy-vs-build 決策矩陣與 RFP 問題集
Markdown 是新的可執行檔:一個 AGENTS.md 檔案如何劫持 Codex 與 Claude Code — 同一周界工作站側的指令檔案劫持類別:一份被植入的 AGENTS.md 以整機設定裡的 MCP 伺服器註冊形式持久化,註冊表 diff 稽核紀律同樣適用

更新 — 2026-10-20：Splunk CVE-2026-76286——工具裡配置的 URL 本身就是信任邊界

Splunk 於 2026 年 10 月 7 日在其自家 MCP Server 中披露 CVE-2026-76286（CWE-918、CVSS 5.3、已在 1.2.1 修復）——一處 SSRF，會把當前運行使用者的平台代幣寄送至自訂 API 工具所配置的 URL（官方通告）。該案例加入帳本（CVE-2026-16496 的 CVSS 10.0 會話類、Spring AI 的 SSRF CVE-2026-45609，以及兩條 KEV 記錄），並帶來一條截然不同的控制教訓：為工具配置的 URL 本身就是信任邊界。鎖定並校驗工具配置的 URL，絕不讓使用者直接提供的裸 URL 進入工具配置；並把工具發起的每一次外呼都視為攜帶伺服器自身憑證。