Tool Surface：MCP Audit + Lethal Trifecta 收尾

tool 不是功能清單。對 agent 來說，每一個可呼叫的 tool 都是一條可能被濫用的路。

Hook

你在社群裡看到一個 MCP server。 名字很吸引人。

super-claude-helper 下載數很多。

留言區一堆人說：

超好用。 裝了之後，

Claude 幾乎什麼都能做。 你看了一眼 README。

支援：

• repo 掃描
• shell helper
• 自動整理設定
• 幫你補全工作流

你心裡想的是：

「反正只是多一個 helper。」 「而且大家都在裝。」

「先加進來試試看。」 一週後，

OX Security 揭露了一類 MCP 風險：

有些 server 的設計， 會把 prompt injection

一路放大成 local command execution。 你這時候才回頭看，

才發現自己那天安裝的不是「一個方便工具」。

而是：

• 一個新的執行面
• 一個新的 context 注入面
• 一個新的 supply chain 入口

這就是 MCP 特別危險的地方。 你不是只多了一個 API。

你是多了一個會跟 LLM 來回互動、 而且可能拿到本機能力的工具層。

Learn

先把一句話講死

agent 能呼叫哪些 tool，本身就是 attack surface。

很多團隊在做 agent 時， 會把 tool 想成 product feature。

像是：

• 能查 issue
• 能讀文件
• 能部署 preview
• 能整理 shell output

這些敘述都沒錯。 但從 security 角度，

每一個 tool 同時也是：

• 一個新的 side effect 來源
• 一個新的權限承載體
• 一個新的 prompt injection 放大器

所以 Lesson 03 的核心不是：

tool 很危險。

而是：

tool 的集合， 就是一張工具層 attack surface 地圖。

為什麼 MCP 比一般 helper script 更敏感

因為 MCP tool 不是單向執行。 它的結果會直接進 LLM context。

這代表什麼？ 代表一個 tool 一旦被攻擊者影響，

危險不只停在它做了什麼。

還包含：

它回了什麼。

例如：

• tool 從外部頁面抓回污染文字
• tool 把惡意 instruction 包在 output 裡
• tool output 被模型當成高權重上下文
• 模型基於這段 output 再去呼叫下一個 tool

這就是為什麼 MCP 特別容易跟 prompt injection 綁在一起。 它既是能力面，

也是 context 面。

OX Security 在 2026 年 Q1 揭示了什麼

這裡不展開所有細節。 只抓對工程師最有用的結論。

OX Security 的研究把注意力拉回一個很本質的問題：

如果一個 MCP server 或其周邊實作，

允許不安全的 command / stdio / 設定路徑， 那 prompt injection

就有機會一路放大成：

• 任意命令執行
• 本機檔案存取
• 憑證外送
• 長期持久化設定污染

也就是說， 問題不在於 MCP 三個字母本身邪惡。

問題在於：

你把什麼 execution capability 包進了 tool surface。

一個實用的 trust 分層

這門課先用三桶分類就夠。

類別	判斷原則	預設態度
信任清單	官方來源、自建、團隊已審核 OSS	可以進 allowlist，但仍要記 owner
不信任清單	marketplace 熱門、來源不明、未審核一鍵安裝	預設不要裝
需先 audit	OSS repo 存在但尚未 review，或是新出不久但需求明確	先審再說

這個分類刻意很保守。 因為工具層一旦出事，

通常不是回答變怪。 而是你的本機跟憑證一起遭殃。

什麼可以算進信任清單

比較合理的候選包括：

• Anthropic 官方維護的 MCP
• 你自己寫的內部 MCP
• 團隊已經做過 source review 的 OSS MCP
• 經過固定 owner 維護、版本 pin、變更可追的工具

但即使進信任清單， 也不代表永遠安全。

你仍然應該知道：

• 誰負責它
• 它能呼叫哪些底層功能
• 它會不會做 outbound request
• 它最近一次 review 是什麼時候

什麼應該直接放進不信任清單

下面幾種情況， 在沒有額外證據前，

最好的預設就是不信任：

• marketplace 上隨手裝的 MCP
• 社群熱推但你沒看過 source 的工具
• 新出不到一個月的熱門專案
• README 非常炫，但權限範圍說不清楚的 helper
• 會自動改設定檔、寫 shell profile、碰 dotfile 的安裝器

這不是保守到僵化。 這是因為 tool surface

一旦跟本機權限綁在一起， 你很難靠 prompt 補救。

「需先 audit」其實是最常見的真實狀態

不是所有第三方工具都該永久拒絕。 有時候它真的有價值。

只是還沒到可以直接信任的程度。

那它就應該先待在：

需先 audit 這一桶。

這種狀態最重要的好處是：

它強迫你把安裝衝動， 變成審查流程。

最小 audit 到底要看什麼

如果沒有現成 skill:audit-skill， 手動看 source，

至少先掃這幾類訊號：

檢查項	為什麼重要
outbound network call	可能把資料送到外部服務
讀 sensitive path	例如 ~/.ssh、~/.gnupg、.secrets
寫 dotfile / shell profile	可能做持久化或偷偷注入後門
執行 shell / subprocess	可能把 prompt 影響放大成 RCE
自動下載額外 binary	把供應鏈風險再往下延伸一層

很多審查其實不用看懂全部業務邏輯。 先抓這些危險動作，

就已經能篩掉一大批不該先裝的東西。

一個很小的分類函式

下面這段 code 沒有 magic。 只是把 trust 分桶先寫死。

真正重要的不是這個函式本身。 而是你要有意識地把來源先分層。

不要讓所有工具， 一律從「看起來好像有用」

直接跳到 「可在你機器上跑」。

為什麼 MCP output 也是攻擊面

傳統權限思路只會看：

這個 tool 能不能寫檔、 能不能開 shell。

但 MCP 還有一個特別危險的面：

tool output 會被模型讀。

這使得攻擊鏈可能長成：

1. 攻擊者先污染 tool 的資料來源
2. tool 把污染內容回給 LLM
3. LLM 把它當成可靠上下文
4. LLM 再調用更高權限的 tool

所以縮小 tool surface， 不只是少裝幾個東西。

還包括：

• 少讓模型看到不必要的 tool output
• 少讓高權限 tool 接在不可信輸入後面
• 少讓任何 tool 擁有無條件 shell 能力

這裡怎麼跟 lethal trifecta 接起來

前面兩門系列課已經介紹過：

tools + sensitive data + full autonomy 會形成 lethal trifecta。

這堂課的收尾重點是：

不要把它只當成某個 agent 的 checklist。

應該把它提升成一個系統設計原則：

只要某個 tool surface 讓這三項同時接通，它就會成為整體 attack surface 的乘法器。

也就是說，

你不是在檢查：

這個 agent 有沒有背對三要素。

你是在檢查：

整個工具層， 有沒有讓任何一條路徑把三要素串起來。

「permissions ARE the security model」在這門課的意思

這句話到 tool surface， 比前面幾門更直接。

因為工具層的 permission 幾乎就是 execution surface 本體。

一個 read_docs tool 跟一個 run_shell tool

不是同一種風險。 一個 draft_email tool

跟一個 send_email_now tool 也不是同一種風險。

permission 一改， 你的 attack surface 形狀就跟著改。

縮小 attack surface 的具體做法，不是抽象口號

最實用的做法通常是：

拆掉 trifecta 裡至少一項。

例如：

• 把 run_shell 改成固定子命令 allowlist
• 把 send_email 改成只產草稿
• 把敏感資料移出這個 agent 的可見範圍
• 把 full autonomy 改成人工確認

你會發現， 這些做法都不是在跟模型鬥智。

而是在縮工具層 surface。

Surface 越小，綁定就越少，路徑就越少

你可以把整門課的工程翻譯濃縮成一句：

少一個 tool，不只是少一個功能；是少一條可以被攻擊者借道的路。

這也是為什麼成熟團隊的 agent 設計， 常常不是「能接的全接」。

而是：

先從最小工具集開始。 真的有需要，

再一個一個加。

給工程師的最小 tool audit checklist

如果今天有人丟給你一個新 MCP server，

你至少先問這 6 題：

1. 它的來源是官方、自建、已審核 OSS，還是 marketplace 熱門項目？
2. 它會不會執行 shell、subprocess、或任何系統命令？
3. 它會不會讀 ~/.ssh、~/.gnupg、.env、.secrets？
4. 它會不會偷偷做 outbound request？
5. 它的 output 會不會把外部內容原樣回灌進 LLM？
6. 這個工具如果被濫用，是否能把 trifecta 串起來？

這六題答不出來， 就還沒到能裝的程度。

這門課真的要你帶走的，不是恐懼

不是叫你看到第三方工具就全部拒絕。 而是把預設改掉。

從：

「好像有用就先裝」

改成：

「先分層、先 audit、先縮權，再決定要不要給模型碰」 這才是 tool surface 的工作習慣。

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位， 是讓你要求 AI 幫你盤點某個 MCP server 的權限面與危險動作，

而不是只讀 README 然後照著安裝。 你的人類優勢：

• 只有你能決定某個工具值不值得進入工作流程，因為只有你知道它一旦失控會碰到哪些真實資產。
• 只有你能判斷哪些能力只是 nice-to-have，哪些則會把 lethal trifecta 三面直接串起來。

可以這樣跟 AI 說：

我在考慮安裝一個第三方 MCP server。請先幫我做 tool surface audit：列出它的來源層級、可能的 subprocess / shell / outbound network 行為、是否會讀 sensitive path、以及它的 output 是否會直接回灌進 LLM。最後只回答三種判斷之一：trust、untrusted、audit-first，並說明理由。

Do