Rug-Pull Attack

地毯式撤除攻擊是什麼，跟一般的工具描述污染有什麼不同？

一般的工具描述污染是攻擊者從一開始就在工具描述裡埋入惡意指令，Agent 第一次讀取這份說明時就已經被誤導。地毯式撤除攻擊的時間軸完全不同：攻擊者一開始發布的是一個完全正常、甚至表現優異的工具，讓 Agent（或使用這個 Agent 系統的人類）在多次使用後逐漸建立信任，這段「表現良好」的時期可能持續數週甚至數月。等到攻擊者判斷信任已經累積到足夠程度——例如這個工具已經被寫進常用清單、已經被多個下游流程依賴——才動手把工具的說明或實際行為悄悄換成惡意版本。

這個時間差是攻擊真正的殺傷力所在：因為 Agent（或審核流程）在初期審查時看到的是乾淨版本，一旦通過審查、被認定「已驗證」或「已信任」，後續的變更通常不會再被以同樣嚴格的標準重新檢視，攻擊者等於是用「先取得信任，再消費信任」的策略,繞過了原本該在第一次接入時就發生的把關。

地毯式撤除攻擊為什麼會出現，是什麼原因造成的？

核心原因是多數信任機制天生偏向「一次性審查」而非「持續驗證」——不管是人工審核一個新工具、還是系統把某個工具標記為已驗證，這個判斷通常發生在工具剛註冊或剛通過檢查的那個時間點，之後除非有明確觸發重新審查的機制，這個信任狀態會被視為長期有效。這個設計假設本身沒有錯，一次性審查是必要的第一道關卡，但它隱含了一個前提：工具的內容在通過審查之後不會再改變，而 MCP 這類開放生態系裡，發布者本來就有能力隨時更新自己發布的工具內容,這個前提在實務上並不成立。

另一個推力是攻擊者的成本效益計算——與其一開始就用明顯惡意的工具嘗試矇騙審查（成功率低，而且一旦被抓到，這個發布身分就直接報廢），不如先投入成本做出一個真正好用的工具，換取長期、多次使用的信任累積，再把這份累積的信任一次性兌現。這種策略在博弈上更划算，因為前期投入雖然較高，但事後被識破的機率也更低，攻擊視窗也更長。

地毯式撤除攻擊具體怎麼運作，實務上會出現哪些跡象？

典型的攻擊生命週期分成三個階段。第一階段是建立信譽：攻擊者發布一個確實有用的工具，可能是免費、開源、或明顯投入了心力打磨使用體驗，目的是被盡可能多的 Agent 系統或開發者採用，並通過任何存在的初步審查機制。第二階段是潛伏累積：工具正常運作一段時間，這段期間攻擊者什麼都不做，讓信任自然累積——工具可能被寫進常用清單、被其他自動化流程依賴、甚至獲得使用者的正面評價，這些都在無形中提高了「之後改壞也不會被立刻發現」的機率。第三階段是替換兌現：攻擊者更新工具版本，把說明文字或實際行為換成惡意版本，因為多數系統對「已經信任過的東西」缺乏持續重新驗證的機制，這次變更往往不會觸發任何警報，Agent 或使用者會繼續像過去一樣正常使用這個「已經熟悉」的工具，直到損害已經造成。

實務上可觀察的跡象包括：一個工具的版本更新沒有對應的公開變更說明、或變更說明的內容跟實際程式碼／說明文字的差異不成比例；工具的行為模式在某次更新後出現無法用「功能升級」合理解釋的變化；工具描述裡新增了跟原本功能定位無關的操作要求。這些跡象單獨看都可能有無害的解釋（例如正常的功能擴充），但值得留意的是——變化本身沒有問題，缺乏對變化的追蹤跟告警機制才是問題。

地毯式撤除攻擊對我有什麼影響，該怎麼防範？

如果你的 Agent 系統依賴任何第三方工具或 MCP 伺服器，這個風險代表「這個工具過去一直很安全」不能被當成「這個工具現在依然安全」的證據——時間拉得越長、依賴越深，一旦真的遭遇地毯式撤除，影響範圍通常也越大，因為更多下游流程已經建立在這個工具之上。這也是為什麼單純的「上線前審查」不足以應對這類威脅,審查只解決了信任建立的起點，沒有處理信任隨時間推移可能被消費掉的問題。

具體可行的防範方向包括：對工具描述內容做版本控管，任何變更都記錄差異並觸發告警，讓「內容變了」這件事本身變成可觀察的訊號，而不是無聲無息地生效；定期（而不是只在初次接入時）重新審查已經信任的工具，把審查頻率跟工具的使用重要性、影響範圍掛鉤——越關鍵的工具，重新審查的頻率應該越高；對工具的行為建立基準線監控，一旦行為模式出現統計上顯著的偏移，即使沒有明確證據證明是惡意變更，也值得先觸發人工複核，而不是等到損害發生才回頭追查。