From Component Manipulation to System Compromise 論文閱讀分析：真正該防的不是某個單點 payload，而是惡意 MCP server 如何沿著 component 一路長成 system compromise

論文基本資訊

• 論文標題：From Component Manipulation to System Compromise: Understanding and Detecting Malicious MCP Servers
• 來源：arXiv:2604.01905
• 年份：2026
• 論文連結：https://arxiv.org/abs/2604.01905
• 主題：MCP、Agentic Security、Malicious Servers、Behavioral Detection、Tool Poisoning、Runtime Monitoring

這篇 From Component Manipulation to System Compromise 真正值得看的地方，不是它又多列了幾種 MCP 攻擊，而是它把問題往前推了一步：惡意 MCP server 不一定靠一個明顯的惡意 payload 取勝，它也可以把壞意圖拆散，藏進不同 component、不同步驟、不同工具語義裡，最後才在整條鏈上長成真正的 system compromise。

這個觀點很重要。因為很多 MCP 防禦到現在還是偏向「抓單點異常」：某段 description 很可疑、某個 command 很危險、某次 tool output 看起來像 injection。但如果攻擊者開始把邏輯分散化，讓每個 component 單看都沒那麼離譜，真正危險的其實是跨 component 的組合行為。這篇 paper 就是在補這個洞。

這篇論文想回答什麼問題？

作者想處理的核心問題可以濃縮成兩句：

• 第一，惡意 MCP server 到底是怎麼沿著不同 component 被拼起來的？
• 第二，如果攻擊不再是一個明顯壞指令，而是一段逐步偏航的行為軌跡，防禦系統要怎麼抓？

這和很多既有 MCP security work 不太一樣。過去不少研究更像是在做 effect-based classification：最後有沒有資料外洩？有沒有 prompt injection？有沒有越權執行？這些當然重要，但它的問題是，你看到的是結果，不一定看得到攻擊是怎麼在不同 component 之間移動、變形、藏匿的。

作者因此改採 component-centric 視角：不要只看最後的 observable effect，而要看惡意邏輯是落在哪個 MCP component、落在什麼位置、以及多個 component 組合後怎麼互相放大。

這篇 paper 最有價值的地方：它把 MCP attack surface 從「功能點」改寫成「組件編排問題」

我認為這篇文章最值得記住的一點是：MCP 風險不是單一工具會不會做壞事，而是整個 server 由哪些 component 組成、它們怎麼被模型理解、又怎麼在執行時彼此接力。

這個 framing 很像把 agent security 從「一個 prompt 有沒有毒」提升到「整個 tool interface architecture 有沒有讓惡意邏輯能分散寄生」。一旦你這樣看，很多傳統檢測法就開始顯得太扁平：

• 只看靜態關鍵字，容易漏掉語義分散的惡意設計
• 只看單次 invocation，容易漏掉跨步驟的偏航
• 只看輸出結果，容易太晚才發現已經造成 side effect

作者想傳達的其實是：當 MCP server 變成一個可被設計、封裝、上架、重複分發的 agent substrate，攻擊面就不再只是 payload，而是 component composition。

114 個惡意 MCP servers：重點不是數量，而是它們證明了攻擊可以被「拆散」

論文先做了一件很實在的事：建立一個 114 個 malicious MCP servers 的 component-centric PoC dataset。這些 server 不是單純拿來示範某個老招，而是特別設計成能展現兩件事：

• component position 會影響攻擊成功率
• multi-component 組合通常比單點攻擊更有優勢

這個結果其實很符合直覺。因為模型對不同 component 的信任程度、本體語義權重、執行時可見度，本來就不一樣。某些惡意邏輯如果直接寫死在最顯眼的位置，很可能太容易被擋；但如果把它拆成幾段，分散到 tool metadata、command behavior、step transition 或 execution trace 裡，單點看起來都不夠致命，合起來卻能把 host 拖進危險狀態。

這也讓我覺得這篇 paper 比不少「新攻擊展示」更成熟一點，因為它真正指出的是：攻擊者優勢不只來自 payload 惡意，而來自架構位置與組合方式。

這篇論文最像 production defense 的部分：Connor

為了對付這種分散式惡意設計，作者提出了 Connor，一個兩階段的 behavioral deviation detector。它的概念不複雜，但很對路：

• Pre-execution analysis：先在執行前分析 shell commands，並抽取每個 tool 的功能意圖
• In-execution analysis：再沿著實際執行步驟，追蹤 tool 的行為軌跡，看它有沒有偏離原本宣稱的 function intent

我覺得這個設計抓得很準，因為它沒有再把防禦重點放在「這段文字像不像 prompt injection」，而是轉去問一個更工程化、也更可落地的問題：

你說你是做 A，那你實際上是不是正在往 B、C、甚至 D 偏航？

這其實就是 MCP / agent runtime 最缺的一層：intent-to-behavior consistency checking。很多 server 在描述上很正常，甚至 command 片段單看也未必有問題，但只要執行軌跡一路偏離原本功能目的，風險就已經出現。Connor 的價值，就是試圖把這種「逐步偏航」變成可檢測對象。

為什麼這個方向比單純 blacklist 更有前途？

因為 MCP 世界的問題，本來就不是一個穩定的惡意字串集合。真正難的地方在於：

• 新 server 會一直出現
• 同一種惡意能力可以換很多包裝方式
• 攻擊可能分散到多個 component
• host、模型、執行順序不同，實際效果也會變

在這種情況下，單靠 signature 或單點 heuristic 的壽命通常不長。相比之下，用「宣稱功能」對照「實際行為」 來抓 deviation，至少比較接近一種可泛化的 runtime security 思路。它不要求你先知道所有 payload 長什麼樣，而是要求你持續判斷：這個工具現在做的事，還像不像它本來該做的事。

結果怎麼看？重點不是 94.6%，而是它真的比現有方法更能抓 multi-component 攻擊

論文報告 Connor 在作者整理的資料集上做到 F1-score 94.6%，而且比 state-of-the-art 高出 8.9% 到 59.6%。另外，在 real-world detection 裡也抓到兩個惡意 server。

分數本身當然不錯，但我覺得更重要的是它背後代表的訊息：當防禦開始把視角從單點惡意特徵轉向 component-level behavioral deviation，它對 previously unknown malicious behaviors 的耐受性確實會比較高。

這點對 MCP 很關鍵。因為你不可能等每一種 server abuse pattern 都先被命名、收錄、再寫規則。生態長太快，這條路根本追不上。比較可行的方向，反而是建一層會問「這個工具現在是否正在偏離其宣稱任務」的 runtime monitor。

這篇 paper 對 MCP host / registry / enterprise governance 的啟示

如果把這篇 paper 放回更大的 agent security 脈絡裡看，我覺得它其實在提醒三件事：

• 對 host 來說：不要只做 invocation allow/deny，還要監看執行過程是否偏離工具意圖。
• 對 registry / marketplace 來說：不要只審 metadata 與 schema，還要考慮 component composition 會不會把惡意邏輯拆散藏起來。
• 對企業治理來說：不要假設「已安裝 = 已信任」，而要把 server 當成持續觀測對象，而不是一次性審核通過就放生。

也就是說，MCP server 的安全不應該只在 onboarding 階段解決，而應該延伸到 runtime 的持續行為稽核。 這和傳統軟體供應鏈其實很像：簽章、掃描、政策檢查都重要，但真正能攔住未知變形攻擊的，往往還是 execution-time monitoring。

這篇論文的限制

當然，這篇 paper 也不是沒限制：

• 114 個 PoC dataset 對研究來說很有價值，但距離真實世界 MCP 生態的複雜度還有距離
• behavioral deviation detection 本身仍仰賴對 tool intent 的抽取品質，這裡若抽歪，後面判斷也可能跟著歪
• 不同 host、不同模型、不同 execution environment 下的泛化能力，仍需要更長期驗證
• 它能抓「偏離」，但不代表它已經完整解決 benign-but-overprivileged 或 policy-unsafe 這類更灰的問題

所以我會把 Connor 看成一個很像方向對了的 runtime detector，而不是已經把 MCP security 做完的終局方案。

總結

這篇論文最值得記住的一點，是它把惡意 MCP server 的風險，從單點 payload 問題改寫成 component composition 與 behavioral deviation 問題。

這個轉向很重要。因為當攻擊者開始把惡意邏輯拆成多段、藏進不同 component，再透過多步執行把它們重新接回來時，還停留在「抓可疑字串」或「擋單次 invocation」的防禦，很容易只看到表面，卻看不到整條正在成形的 compromise path。

如果把這篇濃縮成一句話，我會說：真正該防的不是某個單獨壞掉的 MCP component，而是那些看似分散、最後卻會一起長成 system compromise 的組件級惡意編排。

免責聲明

本文由 AI 產生、整理與撰寫。