MCP 模組程式碼標準

更新 — 2026-08-18：CoSAI令牌交換、MCP專案沙箱基線、OWASP GenAI基線、Ruby SDK漏洞——授權模式和部署基線

四個發展提供了此程式碼標準所需的授權模式和部署基線。

1. CoSAI令牌交換（8月18日）——授權模式。 每個MCP模組應在信任邊界交換令牌，不持有持久憑證。令牌在幾分鐘內過期，可即時撤銷。

2. MCP專案沙箱基線（8月16日）——部署基線。 每個MCP模組部署必須包含作業系統級沙箱（Landlock/Seatbelt/Windows ACL）。

3. OWASP GenAI MCP伺服器安全基線（8月18日）——開發參考。 本標準的目錄結構、工具註冊和錯誤處理映射到OWASP GenAI的開發控制。

4. MCP Ruby SDK漏洞（8月16日）——新的CVE類別確認防禦姿態。 Ruby SDK DoS擴展了速率限制要求；目錄遍歷擴展了輸入驗證要求。參見MCP安全加固檢查清單。

更新 — 2026-08-15：DeepSeek Harness — 「一切皆插件」驗證了模組模式

DeepSeek 於2026年8月13-14日開源了 DeepSeek Harness — 基於 Cordis 元框架的 MIT 執行環境。原則：**「一切皆插件。」**數小時內獲得33,000+ GitHub 星標。對此標準描述的插件/模組模式的最強產業驗證。

為什麼程式碼標準很重要

我們交付的每個連接器都長得一樣。這不是巧合——這是紀律。當第二個整合到來時，代理的能力更容易測試、稽核和替換，因為每個 MCP 模組都遵循相同的結構、命名和錯誤契約。

本文檔定義了 IdeaBosque 編排主幹中所有 MCP 模組的標準。涵蓋目錄布局、工具註冊、輸入輸出 schema、錯誤處理、速率限制、稽核日誌和 PII 邊界處理。

目錄結構

每個 MCP 模組都位於 app/mcp_modules/ 下自己的目錄中，布局一致：

app/mcp_modules//
  __init__.py
  module.py          # 工具註冊 + handler
  schemas.py         # 輸入輸出 Pydantic 模型
  tests/
    test_module.py
  README.md

工具註冊

每個模組透過標準介面註冊其工具。編排主幹透過掃描 register_tools() 進入點來發現工具——無需手動接線。

def register_tools(registrar):
    """註冊本模組提供的所有工具。"""
    registrar.tool(
        name="search_catalog",
        description="按 SKU 或名稱搜尋供應商目錄",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # 每分鐘呼叫數
    )

錯誤處理

模組必須拋出型別化例外，而不是裸字串。主幹捕獲 MCPToolError 子類並將其轉換為代理可推理的結構化回應：

• MCPAuthError — 憑證缺失或過期
• MCPRateLimitError — 觸及上游速率限制
• MCPTimeoutError — 上游呼叫超過配置的超時
• MCPValidationError — 輸入未通過 schema 驗證
• MCPUpstreamError — 上游回傳錯誤狀態

速率限制

每個工具在註冊呼叫中宣告自己的速率限制。主幹按代理、按工具、按視窗執行這些限制。當達到限制時，代理收到一個帶 Retry-After 標頭的 429 回應——它不會崩潰或盲目重試。

稽核日誌

每次工具呼叫都記錄：時間戳記、代理 ID、工具名、輸入雜湊（不是原始輸入——PII 邊界）、輸出狀態、時長和上游系統。日誌以結構化 JSON 寫入並推送到可觀測性管線。

「每次工具呼叫都被記錄且可稽核」不是我們後來才加的功能。它是標準要求的第一件事。

PII 邊界處理

模組必須宣告哪些輸入欄位包含 PII。主幹在記錄前對這些欄位做雜湊，絕不把原始 PII 發到稽核管線。PII 欄位在 schema 中標記：

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

當設定 pii=True 時，稽核日誌器把值替換為 SHA-256 雜湊。工具 handler 仍然接收原始值——PII 處理在日誌邊界強制執行，不在業務邏輯內部。

Update — 2026-08-06: Transport-mode security — the stateful streamable-HTTP attack surface

CVE-2026-16496 (CVSS 10.0, patched in Terraform MCP Server on August 5, 2026) is the first maximum-severity CVE in the MCP ecosystem and the first production evidence that the transport mode is a security dimension, not just an operational one. The vulnerability is a session-hijacking authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This adds a transport-mode-security rule to the deployment-hardening standard:

5. Prefer stateless transport; treat stateful streamable-HTTP as a security risk. The MCP 2026-07-28 specification moved to a stateless protocol core — the initialize/initialized handshake and Mcp-Session-Id header are removed, and stateful workflows use explicit handles instead of server-side sessions. The stateless design eliminates the session-hijacking attack class at the architecture level: a stateless server has no session to steal. The stateful streamable-HTTP transport mode that CVE-2026-16496 exploits is the mode the stateless core is designed to replace. If a module must run stateful streamable-HTTP (for compatibility with a client that has not migrated), treat it as a known-vulnerable configuration: bind it to a private network, require authentication on every session, and plan the migration to stateless transport on the same 12-month clock as the SSE deprecation. A module that exposes stateful streamable-HTTP on a public interface without authentication is in the same risk class as the 1,467 servers Trend Micro found with zero auth — plus the session-hijacking vector.

The OX Security advisory also expanded with additional CVEs beyond the original four exploit families: CVE-2026-30618, CVE-2026-33224, CVE-2026-30617 (Family 1 — STDIO command injection), CVE-2026-30625 (Family 2 — Upsonic allowlist bypass), CVE-2026-30615 (Family 3 — Windsurf prompt injection), CVE-2026-26015 (Family 4 — SSRF), plus CVE-2025-65720 (GPT Researcher RCE), CVE-2026-30623 (LiteLLM RCE), CVE-2026-30624 (Agent Zero RCE), and CVE-2026-54449 (LangBot RCE). The expanded inventory extends the supply-chain risk beyond MCP servers to the agent frameworks and orchestration layers that wrap them — signed provenance, pinned versions, and AIBOM manifests (the dependency control for MCP) are what make the expanded inventory detectable before it fires.

部署強化：切勿在未認證的情況下暴露 MCP 伺服器

STDIO 強化規則解決的是程式碼層面的漏洞。2026 年 7 月浮現了一個獨立的暴露維度，而且它落在了參考實作本身。2026 年 7 月 11 日至 21 日期間，三個 CVE 被提交給官方 MCP Python SDK——每個 Python MCP 伺服器都繼承自這一參考實作：

• CVE-2026-59950 — 缺少 Host/Origin 驗證。受害者造訪的網頁可以透過 DNS 重繫結和 CSRF 驅動其本地 MCP 伺服器。瀏覽器成為攻擊者進入營運商認為私有的 loopback 伺服器的代理。
• CVE-2026-52869 — 未驗證的工作階段請求。HTTP 傳輸在未驗證工作階段的情況下提供工作階段請求，允許未認證存取。
• CVE-2026-52870 — 開放的任務處理器。實驗性任務處理器允許任何客戶端存取另一個客戶端的任務。

同一兩週內，其他 CVE 影響了熱門伺服器：meta-ads-mcp（CVE-2026-54547 / -54549，auth-token 重用 + SSRF）、LangBot（CVE-2026-54449，已認證 RCE）、ToolHive（CVE-2026-58196，SSRF）和 mcp-atlassian（GHSA-g5r6-gv6m-f5jv，任意檔案讀取）。該模式是類別層面的，而非孤立的：MCP 為 localhost loopback 設計，團隊將其部署到網際網路上，而安全基礎——認證、來源驗證、輸入檢查——被跳過了。參考實作發布與社群伺服器同類缺陷，正是本標準所解決的部署強化證據：下方的認證和來源驗證規則不是理想化的——它們關閉了 CVE-2026-59950 和 CVE-2026-52869 背後的根因。

Trend Micro 更正後的後續掃描發現 1,467 個公開可存取的 MCP 伺服器沒有認證或加密——幾乎是從初始 492 個翻了三倍，而非此前引用的「約 2,000」。升級不僅在於數量：1,467 個中有 1,227 個在執行已棄用的 SSE 傳輸（受 7 月 28 日規範遷移和安全暴露影響最大的群體），execute_sql 工具出現在 70 台主機上，「Graphiti Agent Memory」（一個 agentic MCP 伺服器）在 39 台主機上——是竊取記憶體駐留資料的主要目標——至少三台伺服器透過「progress_note」工具暴露患者病歷。威脅從本地 STDIO 配置擴充到了可從網際網路存取的雲端部署 MCP 伺服器。其中許多伺服器向任何能夠存取該連接埠的人暴露了硬編碼憑證、工具端點和系統存取權。

BlueRock Security\uff1a7,000+ MCP \u4f3a\u670d\u5668\u4e2d 36.7% \u5b58\u5728 SSRF \u6f0f\u6d1e\u3002 BlueRock Security \u5206\u6790\u4e86\u8d85\u904e 7,000 \u500b MCP \u4f3a\u670d\u5668\uff0c\u767c\u73fe 36.7% \u53ef\u80fd\u5b58\u5728 Server-Side Request Forgery \u6f0f\u6d1e\u2014\u2014\u9019\u662f\u6bd4 Trend Micro \u7684 1,467 \u53f0\u66b4\u9732\u4f3a\u670d\u5668\u6383\u63cf\u66f4\u5927\u7684\u8a9e\u6599\u5eab\uff0c\u4e14\u5c6c\u65bc\u4e0d\u540c\u7684\u6f0f\u6d1e\u985e\u578b\u3002SSRF \u5141\u8a31\u653b\u64ca\u8005\u5f37\u5236 MCP \u4f3a\u670d\u5668\u5411\u4f3a\u670d\u5668\u53ef\u9054\u4f46\u653b\u64ca\u8005\u4e0d\u53ef\u9054\u7684\u5167\u90e8\u7db2\u8def\u8cc7\u6e90\u767c\u8d77\u8acb\u6c42\u2014\u2014\u96f2\u5143\u8cc7\u6599\u7aef\u9ede\u3001\u5167\u90e8 API\u3001\u8cc7\u6599\u5eab\u300236.7% \u662f\u65b0\u7684\u7e3d\u5408\u6f0f\u6d1e\u7d71\u8a08\u6578\u64da\uff1a\u8d85\u904e\u4e09\u5206\u4e4b\u4e00\u7684 MCP \u4f3a\u670d\u5668\u53ef\u4ee5\u88ab\u6b3a\u9a19\u63a2\u6e2c\u5167\u90e8\u7db2\u8def\u3002\u5c0d\u65bc B2B \u90e8\u7f72\uff0cSSRF \u98a8\u96aa\u5c24\u70ba\u56b4\u5cd9\uff0c\u56e0\u70ba MCP \u4f3a\u670d\u5668\u901a\u5e38\u53ef\u4ee5\u8a2a\u554f\u5167\u90e8\u7cfb\u7d71\uff08ERP\u3001CRM\u3001\u5eab\u5b58\u8cc7\u6599\u5eab\uff09\u2014\u2014\u4e00\u500b\u7372\u53d6\u4f9b\u61c9\u5546\u76ee\u9304\u7684\u4f3a\u670d\u5668\u53ef\u4ee5\u88ab\u91cd\u5b9a\u5411\u53bb\u7372\u53d6\u96f2\u5143\u8cc7\u6599\u7aef\u9ede\u4e26\u6d29\u9732\u6191\u8b49\u3002

2026 \u5e74 7 \u6708\u6ce2\u6b21\u4e2d\u51fa\u73fe\u4e86\u4e09\u500b\u984d\u5916\u7684 CVE\uff0c\u5c07 CVE \u6642\u9593\u7dda\u64f4\u5c55\u5230\u4e86\u5b98\u65b9 SDK \u6f0f\u6d1e\u4e4b\u5916\uff1a

• CVE-2025-68143 \u2014 \u8def\u5f91\u904d\u6b77\u3002MCP \u4f3a\u670d\u5668\u5141\u8a31\u901a\u904e\u7cbe\u5fc3\u69cb\u9020\u7684\u8def\u5f91\u53c3\u6578\u8a2a\u554f\u9810\u671f\u76ee\u9304\u4e4b\u5916\u7684\u6a94\u6848\uff0c\u5be6\u73fe\u4ee3\u7406\u4e3b\u6a5f\u4e0a\u7684\u4efb\u610f\u6a94\u6848\u8b80\u53d6\u3002
• CVE-2025-68144 \u2014 \u53c3\u6578\u6ce8\u5165\u3002\u63a5\u53d7\u547d\u4ee4\u884c\u53c3\u6578\u7684\u5de5\u5177\u53ef\u4ee5\u88ab\u5f37\u5236\u57f7\u884c\u64cd\u4f5c\u54e1\u672a\u9810\u671f\u7684\u984d\u5916\u6a19\u8a18\uff0c\u985e\u4f3c\u65bc\u4e0a\u6587 OX Security \u56db\u898f\u5247\u6a19\u6e96\u4e2d\u8a18\u9304\u7684 STDIO \u5141\u8a31\u540d\u55ae\u7e5e\u904e\u6a21\u5f0f\u3002
• CVE-2025-68145 \u2014 \u5009\u5eab\u7bc4\u570d\u7e5e\u904e\u3002\u61c9\u9650\u5236\u65bc\u55ae\u500b\u5009\u5eab\u7684\u4f3a\u670d\u5668\u53ef\u4ee5\u8a2a\u554f\u5ba3\u5e03\u7bc4\u570d\u4e4b\u5916\u7684\u5009\u5eab\uff0c\u66b4\u9732\u79c1\u6709\u7a0b\u5f0f\u78bc\u548c\u5bc6\u9470\u3002

cyberdesserts.com \u78ba\u8a8d 2026 \u5e74 7 \u6708 28 \u65e5\u7684\u5354\u8b70\u4fee\u8a02\u7248\u672a\u95dc\u9589\u6388\u6b0a\u6a21\u578b\u7f3a\u53e3\u2014\u2014\u5141\u8a31\u53d7\u640d\u5de5\u5177\u63cf\u8ff0\u6216\u8f38\u51fa\u52ab\u6301\u4ee3\u7406\u884c\u70ba\u7684\u7d50\u69cb\u6027\u6f0f\u6d1e\u5728\u6700\u7d42\u898f\u7bc4\u4e2d\u4ecd\u7136\u5b58\u5728\u3002\u7121\u72c0\u614b\u91cd\u8a2d\u8a08\u63d0\u9ad8\u4e86\u71df\u904b\u6548\u7387\uff0c\u4f46\u672a\u89e3\u6c7a MCP03\uff08tool poisoning\uff09\u3001MCP06\uff08intent flow subversion\uff09\u6216 MCP10\uff08context over-sharing\uff09\u3002\u6cbb\u7406\u5c64\u4ecd\u662f\u64cd\u4f5c\u54e1\u7684\u8cac\u4efb\u2014\u2014\u672c\u6a19\u6e96\u662f\u8a72\u8cac\u4efb\u7684\u5be6\u73fe\u5408\u7d04\u3002

Spec final \u9077\u79fb\u6ce8\u91cb\uff082026 \u5e74 7 \u6708 28 \u65e5\uff09\u3002 MCP 2026-07-28 \u898f\u7bc4\u4f5c\u70ba\u6700\u7d48\u7248\u767c\u4f48\uff0c\u9650\u9650 12 \u500b\u6708\u7684 SSE \u5ee2\u68c4\u7b56\u7565\uff1aSSE \u50b3\u8f38\u5df2\u5ee2\u68c4\uff0c\u5fc5\u9808\u5728 12 \u500b\u6708\u5167\u9077\u79fb\u5230 Streamable HTTP \u50b3\u8f38\u3002\u56db\u500b Tier 1 SDK\uff08Python\u3001TypeScript\u3001Java\u3001Kotlin\uff09\u5747\u5df2\u767c\u4f48\u76f8\u5bb9\u7248\u672c\u3002\u4f7f\u7528 SSE \u50b3\u8f38\u7684\u6a21\u7d44\u5fc5\u9808\u9077\u79fb\uff1b\u4f7f\u7528 STDIO \u7684\u6a21\u7d44\u4e0d\u53d7\u5f71\u97ff\u3002\u9077\u79fb\u662f\u50b3\u8f38\u5c64\u66f4\u6539\u2014\u2014\u672c\u6a19\u6e96\u4e2d\u7684\u5de5\u5177\u8a3b\u518a\u3001\u932f\u8aa4\u8655\u7406\u3001\u901f\u7387\u9650\u5236\u548c\u5be1\u8a08\u65e5\u8a8c\u898f\u5247\u8207\u50b3\u8f38\u7121\u95dc\u3002\u6a21\u7d44\u5408\u7d04\u4e0d\u8b8a\uff1b\u8b8a\u7684\u53ea\u662f\u50b3\u8f38\u7d81\u5b9a\u3002

部署強化規則：

1. 切勿在未認證的情況下將 MCP 伺服器暴露在公共介面上。 每個 MCP 伺服器——無論是 STDIO、SSE 還是 HTTP 傳輸——都必須要求認證（OAuth 2.1 with PKCE、API key 或 mTLS）。一個在沒有認證情況下可從 0.0.0.0:3000 存取的伺服器是一個遠端程式碼執行面，而非開發便利。

2. 繫結到 localhost 或私有網路。 生產 MCP 伺服器繫結到 127.0.0.1 或私有子網路。如果需要外部存取，請透過帶有認證、速率限制和 TLS 終止的反向代理路由——而非直接暴露連接埠。

3. 切勿在 MCP 配置檔案中硬編碼憑證。 Trend Micro 掃描在可公開存取的 MCP 伺服器配置中發現了硬編碼的 API key、資料庫密碼和 OAuth 密鑰。憑證必須來自環境變數或密鑰管理器——絕不能來自攻擊者可以讀取的 JSON 檔案。

4. 加密所有傳輸。 STDIO 按定義僅限本地，但 SSE 和 HTTP 傳輸必須使用 TLS。公共網路上的明文 HTTP MCP 伺服器會將每次工具呼叫——包括認證權杖和 PII——暴露給網路層級攔截。

Trend Micro 掃描是 OX Security 公告在部署側的補充：程式碼層面的漏洞（未經清理的 STDIO、allowlist 繞過、配置注入）在伺服器本身未認證暴露時變得可被遠端利用。沒有部署強化的程式碼強化是一扇鎖著的門裝在一個敞開的前廊上。

更新 — 2026-08-07：MCP 伺服器可發現性和治理 — Black Hat 2026 產品維度

完整的 Black Hat 2026 產品清單（crn.com，2026年8月4日）為 MCP 程式碼標準增加了新的維度：MCP 伺服器可發現性和治理。Black Hat USA 2026 上推出的三個產品直接解決了程式碼標準（管理模組如何編寫）與部署現實（管理存在多少模組以及誰了解它們）之間的差距。

1. Cyera Agent Guardian — 影子 MCP 伺服器發現。 程式碼標準假設每個 MCP 模組都已註冊、文件化並遵循目錄結構和錯誤合約。Cyera 的產品揭示了差距：大多數企業中存在不遵循程式碼標準的影子 MCP 伺服器。程式碼標準管理已授權模組；Cyera 發現未授權的。

2. SailPoint Identity Security — MCP 伺服器身份生命週期。 程式碼標準管理模組如何認證。SailPoint 的產品增加了生命週期維度：每個 MCP 伺服器都有一個必須透過身份治理工作流程來配置、證明和撤銷的身份。硬編碼憑證的模組無法透過身份生命週期進行治理；使用 OAuth 2.1 和託管憑證的模組可以。

3. Check Point AI Network Firewall — 網路層 MCP 通訊監控。 程式碼標準管理模組在應用層記錄什麼。Check Point 的產品增加了網路層維度：MCP 通訊通道現在可以在網路層監控。在應用層不記錄工具呼叫的模組仍可在網路層監控，但在兩層都記錄的模組才是產生完整審計追蹤的模組。

Black Hat 2026 MCP 伺服器發現產品為程式碼標準增加了「可發現性和治理」維度：遵循目錄結構、錯誤合約和安全規則的模組是編寫良好的模組，但也註冊在身份治理平台（SailPoint）中、可被影子伺服器偵測工具（Cyera）發現、並在網路層監控（Check Point）的模組是治理良好的模組。程式碼標準是基礎；Black Hat 2026 產品是其上的治理層。

更新 — 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 上做的檢查。