本文探討 AI 程式設計助理如何因幻覺而生成出一些看似合理但實際上卻不存在的套件名稱，進而衍生能讓駭客預先設下陷阱的「slopsquatting」攻擊。此外，本文也提供一些企業可用來保護開發流程的實務策略。
主要重點
- Slopsquatting 是現代化 AI 驅動軟體開發流程的一項供應鏈威脅，起因於 AI 程式設計代理因為幻覺而生成一些看似合理但實際上卻不存在的套件名稱，使得駭客有機會預先設下陷阱來散播惡意程式。
- 儘管進階程式設計代理與工作流程，如：Claude Code CLI、OpenAI Codex CLI 以及 Cursor AI 搭配 MCP 作後端驗證，有助於降低幽靈相依元件 (phantom dependencies) 的風險，但仍無法徹底根除，因為就算即時驗證也無法捕捉每一種邊緣案例。
- 常見的失敗情況包括：填補情境漏洞與模仿表面形式，也就是 AI 代理根據使用者的意圖與符合統計的慣例而捏造出看似合理的套件名稱，卻沒有確實檢查套件名稱是否真的存在。
- 防範這類威脅需要從多重管道下手，結合最佳實務原則 (例如透過軟體物料清單來追蹤源頭)、自動化漏洞掃描、在沙盒模擬環境內測試安裝、即時驗證套件，以及人員監督，如此才能真正保護 AI 驅動的開發流程。
想像一下這樣的情境：您的開發時程相當緊迫，但您擁有一套可靠的 AI 程式設計助理來自動幫您完成函式撰寫、推薦可用相依元件，甚至幫您即時呼叫 pip 安裝指令。您正深深沉醉在所謂的「氛圍程式設計」(vibe coding) 開發流程當中，在 AI 的協助下，您的點子幾乎豪不費力就變成了程式碼，感覺就好像在變魔術一樣，直到一切突然停止運作。
在研究過程當中，我們曾看到一個進階 AI 代理自豪地無中生有了一個看似完全合理的套件名稱，但隨後卻在程式實際組建時發生「找不到模組」的窘境。然而更令人擔憂的是，這些幽靈套件說不定已經存在於 PyPI 當中，因為某個駭客已經註冊了這些套件名稱，等著開發人員上鉤，自己將惡意程式碼帶入工作流程當中。
對 AI 開發人員來說，這些暫時性的錯誤不單只是造成不便而已，而是一種新式供應鏈攻擊的機會之窗。當 AI 代理幻想出不存在的相依元件或安裝未經檢查的套件時，就等於為slopsquatting 創造了機會，因為駭客會在公開登錄上預先註冊這些幻想出來的名稱。
本文探討這些幻覺是如何出現在進階 AI 代理當中，並說明其潛在的影響，提供企業一些維護開發流程安全以防範類似威脅的行動建議。
何謂 slopsquatting？
「slopsquatting」是一種利用AI 幻覺的攻擊，是經典的「 typosquatting」打字錯誤攻擊的進化版。只不過，駭客利用的不是人類打錯字的情況，而是 AI 出現幻覺的情況。當 AI 程式設計代理可能無中生有地捏造出一個相依元件，例如「starlette-reverse-proxy」，駭客也有可能在網路上發布一個名稱完全相同的惡意套件。萬一開發人員在不知情的狀況下執行了 AI 生成的安裝指令時，就可能不小心下載到駭客發布的惡意套件來執行。
善用進階代理功能
原始的大型語言模型 (LLM) 能生成看似合理的套件名稱，但它們卻缺乏內建檢查機制。反觀一些進階的程式設計代理，大多整合了額外的推理能力和工具來攔截幻覺，避免幻覺進入到程式碼當中。接下來，我們將討論一些最新的程式設計代理所提供的重要功能。
Anthropic：Claude Code CLI
使用工具來延伸思考
Claude Code CLI 能動態交錯運用內部推理與外部工具，例如，在生成程式碼的過程中即時搜尋網站並參考說明文件來確認套件是否真的存在。這種「延伸思考」的作法可確保其生成的套件名稱是根據即時的證據而非單純僅依賴統計。
程式碼庫記憶
藉由多層式記憶掃描，可讓 AI 代理回想先前曾經確認過的東西以及專案本身的命名習慣，讓它在推薦匯入函式庫之前，先交叉參考之前的相依元件檢查記憶。
OpenAI：Codex CLI
自動化測試與除錯
Codex CLI 會生成及循環執行測試案例，使用匯入失敗的情況和測試發生的錯誤作為回饋，將實際上不存在的函式庫從其建議中去除。
程式碼庫感應與自省
Codex 會藉由檢查現有的程式碼庫 (解析匯入函式、分析專案結構、參考本地端文件) 來確保其推薦的套件確實符合應用程式的特定情境，而非單純只仰賴語言先驗 (language priors)。
Cursor AI：使用 MCP 作後端驗證
針對 Cursor AI，我們運用了多個 Model Context Protocol (MCP) 伺服器來幫忙針對每一個候選的相依元件進行即時驗證。
- Context7：提供版本相關的最新 API 說明文件及範例。
- Sequential Thinking：用於分解工作來輔助解決問題。
- Custom Tavily Search：提供即時網站搜尋功能。
幻覺比較分析
為了評估不同的 AI 如何管理幽靈相依元件的問題，我們比較了三種不同模型、100 個真實網站開發工作所產生的幻覺套件數量。針對涵蓋不同程式設計代理與 Cursor AI 的測試自動化挑戰，我們手動執行了 10 個在基礎模型中出現幻覺比率最高的工作，記錄下每一次的幻覺，然後將結果彙整。
我們將結果整理在圖 4 當中，該圖顯示每個模型在每項工作中推薦的虛構套件名稱數量 (0–6)。完整的資料集我們放在 GitHub。
基礎模型
在所有 100 個工作中，基礎模型絕大多數的輸出都是零幻覺。然而，當他們被要求結合多個新的函式庫時，它們偶爾會突然冒出 2 至 4 個自己發明的名稱。
這種突然增加的現象，大多集中在一些高複雜性的提示，反映出模型在訓練資料缺乏最新的即時基礎知識時，傾向於拼接一些熟悉的詞素 (如： 「graph」 + 「orm」、 「wave」 + 「socket」) 來組合出看似合理但實際上不存在的套件名稱。
程式設計代理
進階程式設計代理可藉由加入思路鏈 (chain-of-thought) 推理並整合即時的網站搜尋，就能減少大約一半的幻覺出現率。但儘管如此，高複雜性的提示偶爾還是會突然冒出一、兩個幽靈名稱。通常會發生錯誤的情況包括：
- 填補情境漏洞
AI 代理會拼接語意上相關的詞素 (如 WebSocket、ORM、serverless) 來符合使用者的意圖 (即使不是百分之百符合)。 - 模仿表面形式
AI 代理會依賴統計上最常用的命名習慣 (而非即時的索引) 來當作驗證，這會產生「非常接近但錯誤」的字串，但卻符合一般常見的命名習慣 (例如像 opentelemetry-instrumentation- 這樣的前綴詞，或者像 -requirements 這樣的後綴詞)，這反映的是統計上的規律而非真實的名稱。
Cursor AI 搭配 MCP 作後端的氛圍程式設計
如果使用三個 MCP 伺服器來改善氛圍程式設計流程，就可以將幻覺數量降至最低。即時驗證可有效過濾掉其他程式設計代理出現的大部分幻覺，但在遇到沒有實際登錄存在的邊緣案例時，仍可能出現少量的幻想名稱。
- 跨生態系「名稱借用」
氛圍程式設計匯集了搜尋程式碼片段 (snippet) 與來自多種語言社群的 GitHub README。當某個詞彙存在時，比方說存在於 JavaScript 生態系內 (例如一個名為 serverless-python-requirements 的 npm 擴充元件) 或者存在於某個廠商說明文件內，AI 代理會將它拿來套用在 Python 的情境而不會實際檢查一下 PyPI，因而產生看似合理、但其實是存在於另一個環境的套件名稱。 - 經驗式詞素拼接邏輯
如果找不到直接相符的名稱，Cursor AI 就會將它先前曾經遇過連在一起的兩個敘述性 token 拼接在一起 (例如：graphit + orm 或 morpher) 來填補語意空缺 (如「graph database ORM」或「data transformer」)。其結果就是在統計上合理，但完全是憑空想像。
結論與建議
本研究示範了套件幻覺依然是所有 AI 程式設計典範當中的真實供應鏈威脅。當基礎模型被要求結合多個函式庫時，就會經常產生看似合理、但卻實際上不存在的相依元件名稱。儘管經由推理的強化大概可讓 AI 代理減少一半的幽靈建議，但卻無法徹底消除。儘管氛圍程式設計工作流程搭配即時 MCP 驗證確實能將這類情況降至最低，但遇到邊緣案例時還是容易出錯。
很重要的一點是，如果單靠 PyPI 查詢，很可能會給開發人員一種虛假的安全感，因為駭客有可能已預先註冊了那些幻覺產生的套件名稱，甚至就算是正常的套件，也可能本身就含有未修補的漏洞。當企業將相依元件解析當成一項嚴格、可稽核的流程來執行，而非單純只是為了方便時，就能大幅減少遭遇 slopsquatting 和其他供應鏈漏洞攻擊的機會。
建議
- 採用軟體物料清單 (SBOM) 來追蹤源頭
每次組建程式時都產生 SBOM 並且使用加密方式加以簽署，如此可確保每一個相依元件的來源與版本都可被稽核。 - 自動化漏洞掃描
將 Safety CLI 或 OWASP dep-scan 這類工具整合至 CI/CD 流程，如此可在程式碼晉升 (promote) 之前預先偵測新增或現有套件當中的已知 CVE 漏洞。 - 隔離的安裝環境
在臨時的 Docker 容器或虛擬機器 (VM) 當中執行所有 AI 生成的 pip 安裝指令。唯有通過沙盒擬環境驗證的檔案才能晉升至營運環境。 - 提示驅動的循環驗證
設計一些 AI 提示來加入在線式 (inline) 存在性檢查 (例如：pip index versions)，並要求在輸出最終程式碼時必須執行即時查詢。 - 開發人員訓練與政策
透過教育訓練讓工程團隊了解有關 slopsquatting 的風險，並強制實施政策要求執行相依元件審查、簽章驗證，以及常態性事件回應演練。
當自動化安裝套件無可避免時，強制實行嚴格的沙盒模擬控管，可有助於防範潛在威脅：
- 容器化沙盒模擬
在拋棄式容器或輕量化 VM 當中執行 AI 建議的安裝來隔離並防止主機遭到入侵。 - 託管式雲端沙盒模擬環境
使用具備網路與資源強制管制的代管式執行時期環境，並設定在每次作業階段完成之後便自行銷毀。 - 每次執行之後就重設環境
在每次執行完畢之後就重設沙盒模擬環境來清除可能常駐的惡意檔案。 - 對外連線管制
僅將經過核准的登錄項目列入白名單，封鎖未經授權的對外出口來切斷幕後操縱 (CC) 管道。 - 執行前漏洞掃描
在安裝前預先掃描推薦的相依元件清單，檢查是否存在著高嚴重性 CVE 漏洞，並標記或封鎖任何危險的套件。 - 稽核、記錄和監控
利用記錄檔來擷取詳細的安裝指令、檔案操作以及網路呼叫，部署執行時期監控機制來偵測異常行為並觸發自動拆解或警報。 - 在流程當中加入人員審核步驟
要求新增或不熟悉的套件必須經過手動審查，以便在自動化與安全監督之間取得平衡。 - 不可變更的基礎映像與政策更新
讓每個沙盒模擬環境都必須從乾淨的釘選版本基礎映像產生，並且持續更新資安政策、基礎映像以及防火牆規則來防範新興威脅。
原文出處：Slopsquatting:When AI Agents Hallucinate Malicious Packages 作者：Sean Park (首席威脅研究員)