MCP 安全現狀：WASM sandbox 能否終結 Plugin 安全噩夢？
2025 年到 2026 年，MCP（Model Context Protocol）由一個新興嘅 protocol 變成咗 AI agent 嘅標準整合層。Claude Desktop、Cursor、Windsurf，甚至 Cloudflare 嘅 enterprise 架構都採用咗 MCP。但同一時間，CVE 一個接一個——OX Security 披露嘅 systemic command injection 漏洞橫跨 LiteLLM、Agent Zero、LangBot、Bisheng 等主流工具；Windsurf 嘅 prompt injection 漏洞可以令 attacker 修改本地 MCP config，達成 RCE。每星期都有新嘅 MCP CVE，而且唔係 bug，係 architecture 層面嘅問題。MCP 嘅 stdio transport 本質上就係叫個 agent 幫你執行任意 command——你裝一個 MCP server，就等於畀咗個 agent root access 去行 code。呢個模型喺 developer 嘅 local machine 上可能還好，但一旦推到 production、multi-tenant 嘅環境，就係災難。
MCP 嘅安全噩夢：唔係 bug，係信任模型嘅缺陷
MCP 嘅設計本身有幾個結構性問題。首先，stdio transport 嘅本質係「host application spawn 一個 subprocess，然後透過 stdin/stdout 溝通」。呢個 pattern 意味住每個 MCP server 都有同 host process 一樣嘅 privilege——可以讀文件、可以連 network、可以 access 環境變數。OX Security 喺 2026 年初披露咗成個 vulnerability family：attacker 透過改 MCP config 嘅 JSON，將 transport type 由 SSE 改成 STDIO，再插入任意 command，就做到 RCE。呢個唔係單一 product 嘅 bug，而係 MCP 生態系統性嘅問題——成個 STDIO 嘅 spawn pattern 本身就預設咗信任。
第二個問題係 secrets management。而家大部份 MCP server 嘅 API key 同 credentials 都擺喺 .env 或者環境變數入面。Agent 可以讀到呢啲 secret，prompt injection 嘅時候就可以 leak 出去。傳統嘅 secrets manager（AWS Secrets Manager、HashiCorp Vault）都解決唔到呢個問題——因為 agent 最終都要拎到個 secret 先用得，而拎到嘅一刻就存在 memory 入面，可以被 exfiltrate。呢個係 agentic AI 獨有嘅 threat model：唔係「點樣保護啲 secret 唔俾人偷」，而係「點樣令 agent 可以用 secret 但永遠見唔到個 secret」。
第三，MCP server 之間冇 isolation。同一個 process 入面行十個 tool，一個 tool 嘅 dependency 出事，所有 tool 嘅 credentials 都洩漏。Supply chain attack 唔需要攻陷你個 server，只需要 compromised 一個 npm package 就已經可以 read process.env 拎走所有 API key。
呢三個問題加埋，構成咗 MCP 嘅安全噩夢。而而家有兩個方向嘗試解決呢個問題：WASM sandbox（hyper-mcp）同 token-proxy architecture（Pincer-MCP）。
WASM Sandbox：hyper-mcp 嘅 security-first 架構拆解
hyper-mcp 係一個用 Rust 寫嘅 MCP server，核心 design philosophy 係「每一個 plugin 都係一個 WASM module，行喺 sandbox 入面」。佢用咗 Extism 嚟做 WASM runtime——Extism 係一個建基於 Wasmtime 嘅 plugin system，畀 host program 以 plugin 形式 load WASM module，並且精準控制每個 plugin 嘅 capabilities。
hyper-mcp 嘅安全模型有幾層。第一層係記憶體隔離：每個 WASM module 有自己嘅 linear memory，一個 plugin 冇辦法讀或寫另一個 plugin 嘅 memory。呢個係 WASM 語義層面嘅保證，唔係 OS process 層面，所以 overhead 好細——每個 WASM VM startup 只需 1-10ms，per-instance memory footprint 低過 5MB。
第二層係 capability gating。hyper-mcp 嘅 config 入面，每個 plugin 可以設定 allowed_hosts（允許連線嘅 network host）、allowed_paths（允許讀寫嘅 filesystem path）、allowed_secrets（允許 access 嘅 secret key）。呢啲唔係 convention，而係 runtime 強制執行嘅——個 WASM module 叫 std::env::var("GITHUB_TOKEN")，如果 config 冇將呢個 secret pass 畀佢，佢就拎唔到。同樣，network call 去 evil.example.com 會被 Extism 嘅 host function 直接 block 喺 network stack 之前。
第三層係供應鏈安全。hyper-mcp 支援 OCI registry 做 plugin distribution，每個 plugin image 喺 publish 嘅時候用 cosign 簽名，load 嘅時候 hyper-mcp 會驗證 signature。呢個確保咗你 load 嘅 plugin 確實係 publisher 發出嚟嘅，冇被人篡改過。
值得一提嘅係 MCP-SandboxScan——一個由學術團隊開發嘅 WASM-based 安全掃描框架，將 MCP tool 喺 WASM/WASI sandbox 入面執行，捕捉 runtime behavior（env access、file read、HTTP fetch intent），然後做 source-to-sink 嘅 data flow 分析。呢個研究證實咗 WASM sandbox 唔單止可以做 containment，仲可以做 runtime security analysis——呢個係傳統 static scanning 做唔到嘅。
但 sandbox 唔係萬能。Extism 嘅 host function 係最大嘅 attack surface——如果你 expose 咗一個 read_file(path) 嘅 host function 而冇做 path validation，個 sandbox 就形同虛設。WASM 保護嘅只係記憶體，host function 係 native code，行喺 sandbox 外面。Extism 嘅安全研究好清楚咁指出：unconfigured Extism 同 hardened Extism 嘅安全差距極大——前者 plugin 可以讀任何 file、出任何 network，後者先真正有 isolation。
Token Proxy 同 Zero-Trust 架構：Agent 唔應該擁有 Secret
如果話 WASM sandbox 解決緊「plugin 之間嘅隔離」，咁 token-proxy architecture 解決緊「agent 同 secret 之間嘅隔離」。
Pincer-MCP 嘅核心 insight 好簡單：Agent 需要 用 一個 API key，但唔需要 知道 個 API key。傳統做法係 agent 拎住個 key 喺 memory，用嘅時候直接 pass。Pincer-MCP 嘅做法係 agent 拎住一個 opaque 嘅 proxy token（例如 pxr_a1b2c3d4），每次要 call API 嘅時候，由 Pincer 呢個 proxy 代為攞個 real key 出嚟簽 request，用完即棄。
呢個架構有幾個關鍵設計。第一，hardware-backed vaulting——real secret 放喺 OS 原生嘅 keychain（macOS Keychain、Windows Credential Manager、Linux Secret Service），encryption key 唔會離開 Secure Enclave 或者 TPM。第二，Just-In-Time decryption——個 real key 喺 memory 入面存在嘅時間只有 microseconds，夠簽一個 request 就即刻 scrubbed。第三，granular tool-level ACL——每個 proxy token 綁定咗可以 access 邊啲 tool、邊啲 secret，就算 prompt injection 成功咗，attacker 都冇得 escalate。
Claude Desktop 嘅用戶應該留意到，而家呢個 token-proxy pattern 其實同 hyper-mcp 嘅 runtime config guide 入面提到嘅 authentication setup 同 platform-specific keyring integration 係同一個方向。hyper-mcp 支援 Basic、Token、同 Keyring 三種 auth mode，其中 keyring mode 就係用 OS-native secret storage 嚟保護 credential。兩個 project 雖然 approach 唔同（一個用 WASM sandbox，一個用 proxy layer），但 philosophy 一致：least privilege、defense in depth、architectural 而非 prompt-based 嘅安全。
Cloudflare 喺 2026 年 4 月發表嘅 enterprise MCP reference architecture 亦都認同呢個方向。佢哋用 Cloudflare Access 做 OAuth provider，用 MCP server portals 做 centralized logging 同 policy enforcement，再用 Code Mode 將幾十個 tool 壓縮成兩個 portal tool，大幅減少 token consumption 同時 maintain security boundary。
實戰建議：WASM Sandbox 唔係銀彈，咁應該點做？
講咗咁多理論，作為香港嘅 developer 或者 startup CTO，你應該點樣喺自己嘅 MCP deployment 應用呢啲概念？
第一，分層隔離，唔好靠單一機制。 WASM sandbox 解決 memory isolation 同 capability gating，但 host function 係最大嘅 attack surface。唔好 expose 太寬鬆嘅 host function——每一個 host function 都係一個 potential 嘅 backdoor。如果你用 hyper-mcp，花時間正確設定每個 plugin 嘅 allowed_hosts、allowed_paths、allowed_secrets，唔好求其畀 /* 或者 wildcard。如果你用 container 做 isolation，唔好信 Docker 做 security boundary——用 gVisor 或者 Kata Containers 加強 isolation。
第二，Agent 永遠唔應該直接擁有 secret。 唔好用 .env，更加唔好 hardcode API key。用 token-proxy pattern 或者最少用 OS keychain。hyper-mcp 嘅 keyring support 係最低門檻——將 secret 搬離 environment variable，搬入 hardware-backed vault。Pincer-MCP 嘅做法更加徹底，但兩者都比將 secret 擺喺 process.env 安全得多。
第三，Plugin 供應鏈要有簽名驗證。 如果你係 publish MCP plugin 嘅人，用 cosign 簽名，用 OCI registry 做 distribution。如果你係 consume MCP plugin 嘅人，唔好用 unsigned plugin。hyper-mcp 嘅 cosign integration 係而家成個 MCP 生態入面最成熟嘅 supply chain security 實踐。
第四，Monitor runtime 行為。 MCP-SandboxScan 嘅研究好重要：static scanning 睇唔到 runtime behavior。一個 tool 喺 binary 入面冇任何可疑字串，但 runtime 嘅時候可以 assembly path、read file、exfiltrate data。WASM sandbox 嘅其中一個隱藏好處係 runtime observability——當 WASI 拒絕咗一個 path_open 嘅 syscall 嘅時候，嗰個 error 唔單止係 security event，仲係一個高 fidelity 嘅 IoC，代表緊 active exploit attempt。
MCP 嘅安全問題本質上係一個新嘅 trust model 問題。我哋習慣咗俾 code full access 去 file system 同 network，但 agentic AI 嘅世界入面，code 係由 LLM 生成嘅、tool 係 third-party 嘅、攻擊面係 prompt injection 嘅。呢個新 threat model 需要新嘅 security architecture——WASM sandbox 同 token-proxy 係呢個方向嘅重要一步，但佢哋只係工具，真正關鍵嘅係你點樣 design 成個信任邊界。