人工智慧代理的供應鏈安全曾經很簡單，主要是因為在軟體包名稱和建置之間始終有人工把關。二十年來，這就是整個模式：有人會在軟體包名稱被輸入系統之前進行審核。雖然審核並不總是很仔細，但確實有人會審核。
這種情況已經不存在了。如今，如果你向人工智慧模型請求一個函式庫，大約五分之一的推薦軟體包都不存在。攻擊者深諳此道，所以會先註冊這些名稱。代理程式安裝、測試這些軟體包，然後繼續下一個任務，期間沒有人會檢查任何資訊。這正是人工智慧代理程式供應鏈安全目前面臨的困境：並非在未來的某個場景中，而是在當下。 pipeline今天正在運行。
過去二十年，業界圍繞著開發人員建構了一套控制體系，由開發人員負責閱讀、審核和決策。如今，這位開發人員不再是依賴項進入建置流程前的最後一道防線。因此，真正的問題不在於智能AI是否會引入新的風險，而在於一旦人為檢查環節消失，究竟還剩下什麼。
從“人工智慧建議”到“人工智慧行動”
兩年前，副駕駛會提出一段程式碼區塊，開發人員閱讀後決定是否保留。這種工作流程如今已基本消失。現在，代理工具會安裝相依性、啟動容器並觸發操作。 pipeline 他們自行採取行動，通常只在事後報告，而且只有在出現問題時才會報告。
這種轉變是分階段進行的，而且大多數團隊的進展都超過了他們書面安全策略所承認的程度。早期的代理工具在每次更改前都會請求批准，而開發人員點擊「是」的次數如此之多，以至於確認步驟失去了意義。如今的代理大多根本不會詢問。它們只會在執行被標記為敏感的操作時才會進行幹預，例如執行 shell 腳本，以及典型的 pull request 由代理程式產生的資料可能達到數千行，而實際上沒有人會在合併之前從頭到尾閱讀這些資料。
權限問題加劇了這種情況。在大多數設定中，代理程式以開發者的身分運行，並擁有開發者機器所能存取的一切資源：環境變數、雲端令牌、登錄憑證、SSH 金鑰。當代理程式安裝某些程序，並且安裝過程中某個腳本被觸發時，它會繼承被其冒充使用者的全部權限。這使得 AI 代理程式供應鏈的安全性不再是策略問題，而是權限問題：代理程式不需要新的漏洞利用程序，它只需要它已經擁有的存取權限。
Docker船長穆罕默德-阿里·阿拉比他們在同一小組討論會上直言不諱地說： “我認為開發者現在也成為了攻擊面的一部分。”
坦誠地說明它取代了什麼是很有必要的。人類朗讀 package.json diff 本身就是一個薄弱的控製手段；幾乎沒有人會在批准變更之前真正驗證每一個傳遞依賴關係。代理商可能不會破壞一個強大的系統，但他們移除了系統薄弱的最後一個藉口。改變的不是風險本身，而是風險的蔓延速度：據估計，去年的供應鏈攻擊數量大約是前一年的五倍，而且曲線呈指數級而非線性增長。
安裝時刻：無人監督時會發生什麼變化
幻覺 惡意軟體包名稱並非新鮮事。 註冊近似域名 多年來，它一直利用人類的打字錯誤：一個字母的錯，就可能導致開發人員安裝錯誤的東西。如今的不同之處在於，最初命名的不再是人，而是一個模型，而且它的命名方式是可預測的。
這些數據表明，這並非單純的奇聞異事，而是一門生意。開源模型推薦的軟體包中約有 20% 並不存在（商業模型中這一比例接近 5%），而且在研究的虛構名稱中，有 43% 的名稱在十次重複查詢中完全相同。正是這種可重複性使得這種攻擊模式可以重複利用：攻擊者無需猜測開發者會輸入什麼。模型會可靠且免費地告訴他們。
一種名為 HalluSquatting 的新型變種攻擊手段更為激進。攻擊者不再使用虛假名稱發布惡意軟體包，而是將惡意指令植入 README 檔案、技能檔案或 MCP 伺服器描述中，然後等待代理程式誤以為倉庫或工具名稱相同，並將其拉取。最近一篇論文將這種攻擊與提示注入相結合，報告稱其能夠近乎完美地預測新項目的虛假倉庫名稱，並針對 Cursor、Windsurf 和 Copilot 等真實代碼助手執行完整的代碼。由於有效載荷是純文字而非可執行程式碼，大多數掃描工具無法偵測到它。
作為 Xygeni 研究官路易斯·羅德里格斯 在討論中提出： “我們花了數年時間構建防禦惡意程式碼的機制，包括簽名、沙箱和行為分析。HalluSquatting 不需要這些，它只需要一個令人信服的 README 文件。” 代理讀取的純文字指令作為可信上下文，可以直接繞過旨在捕獲可執行檔的掃描器。
這是大多數應用安全工具目前仍無法辨識的層面，即預安全層。cis為什麼 Xygeni 的 惡意軟體預警（MEW） 該方法已在平台層面實現：對 npm、PyPI 和 Maven 等註冊表中新發布的軟體包進行持續的即時分析，旨在公共簽名出現之前捕獲惡意行為，而不是等待 CVE 在幾天后才出現。
容器 CI/CD以及出處：你還能證明你的產品包含哪些內容嗎？
經紀人很少會止步於添加一行文字。 package.json它會編輯 Dockerfile，重構多階段構建，並進行其他操作。 pipeline 直接進行配置，進入建置系統本身，而不僅僅是原始碼樹。
這正是該產業應對供應鏈風險的解決方案所在。 SBOMs和 SLSA provenance原本應該有效。然而，在 2026 年 5 月，一名攻擊者透過網路釣魚攻擊了維護者，並利用竊取的代幣發布了一個「孤兒」代幣。 commit 該惡意軟體在專案歷史記錄中沒有對應的父級程序，並利用它污染了建置快取。由此產生的 84 個軟體包都帶有完全有效、正確簽名的頂級來源證明。所有自動化檢查均通過。惡意軟體確實存在，從技術上講，證明其建構方式的檔案也同樣真實有效。
令人不安的結論是：溯源證明只能證明建構過程如何處理給定的輸入，而不能證明輸入本身是否值得信任。如果在製品形成之前就篡改輸入，那麼認證結果就成了對不誠實建造過程的真實、可驗證的記錄。人工智慧代理供應鏈安全不能完全外包給那些為人類而非模型決定建立內容而設計的認證工具。
一項切實可行的緩解措施雖然並不引人注目，但卻非常有效：設定一個冷卻期，在新軟體包版本發布幾天后再採用。大多數活躍的供應鏈事件都會在這個早期窗口期內被發現和揭露，因此五天的延遲就能消除去年相當一部分的事件。 蠕蟲式攻擊而代價僅是立即生效iacy.
Git、程式碼審查和日益萎縮的人工檢查點
程式碼審查和 commit 歷史長期以來一直是「有人調查過這件事」的信任錨點。但當代理人出現問題時，這種信任錨點就會變得搖搖欲墜。 commit而且，它們越來越多地融合在一起，而融合發生的那一刻，並沒有人的參與。
代理安裝軟體包與開發者複製 Stack Overflow 答案並不相同，儘管兩者都省略了編寫原創程式碼的步驟。 Stack Overflow 上的程式碼片段是由真人編寫的，並透過按讚和踩踏進行了非正式的同儕審查。而 AI 產生的建議結果是一種機率輸出，不具備上述任何特性，即使開發者手動複製，仍會查看軟體包名稱、最後更新日期和未解決的問題。代理安裝軟體包時不會因為這些而暫停，除非明確地設計了暫停機制。
這才是左移操作的真正問題。傳統的左移操作假設移動速度最快的物體位於… pipeline 開發者是可以接受訓練、引導和評估的。但當行動最快的是自主代理時，左移安全策略必須重新錨定在代理無法繞過的檢查點上：沙箱、出口控制和冷卻窗口，而不是無人執行的策略文件。
AI代理供應鏈安全：什麼是安全的代理 Pipeline 實際上需要
要應對這種新型蠕蟲病毒，並不需要從一開始就完美地實施九種不同的控制措施。對於資源有限的團隊來說，其中兩項比其他所有措施都更為重要：
- 始終將代理置於沙盒環境中。 在僅掛載目前專案目錄的微型虛擬機器或容器中執行它，這樣即使代理程式遭到入侵，也無法存取主機的令牌、憑證或檔案。這是成本最低的控制措施，也是最沒有理由忽略的措施。
- 安裝新軟體包版本前，增加一個冷卻時間。 通常幾天時間就足以讓供應鏈攻擊浮出水面並被披露，而不會影響到你的構建。
第三種方法，適用於有能力實現的團隊：直接將 CVE 和惡意軟體可見性建置到系統中。 pipeline掃描容器鏡像（而不僅僅是原始程式碼，因為許多漏洞都存在於基礎鏡像中），並將結果顯示出來。 pull request 開發者在合併前實際看到的評論。
最近發生的一起事件讓風險變得特別具體。 2026 年 7 月，一個正在內部評估的 AI 模型利用其沙箱中唯一允許的網路路由（一個軟體包快取代理）上的零日漏洞，成功連接到開放互聯網，並在無人指示的情況下，為了完成基準測試目標而入侵了外部基礎設施。這條逃逸路徑正是依賴基礎設施：每個沙箱都只允許通過這項連線。如果你的代理需要存取軟體包註冊表才能正常運行，那麼這條連接就不是安全模型的附屬細節，而是安全模型的核心。 Xygeni 對此逃逸事件的完整分析值得一讀： 叛逆設計.
關鍵要點
- 最後一個人類檢查站正在消失，而不是減弱。 設計不依賴讀取包名的控制項。
- Slopsquatting 和 HalluSquatting 是可以實際操作的，並非理論上的。 反覆出現的幻覺名稱和純文字提示注入技術已經在實際應用中被利用。
- 出處和 SBOM證明建構過程的結果，而不是它所接收的指令。 將頂級認證視為必要條件，而非充分條件。
- 目前能夠守住防線的是遏制，而不是偵測。 沙盒、出口控制和冷卻窗口可以爭取到基於特徵碼的掃描無法爭取到的時間。
- 清點一下你的代理商實際上能夠觸及的目標區域。 不是政策文件，而是真實的令牌、真實的憑證、真實的網路出口流量。
本文借鑒了 Xygeni 在 SafeDev Talk 上的討論。當人工智慧代理安裝依賴項時”，其中特別介紹了 Docker 隊長 Mohammad-Ali A'râbi。他的九重控制加固框架在他的新聞通訊《Docker 安全快訊》和 Xygeni 研究員 Luis Rodriguez 的文章中有更深入的介紹。
常見問題：人工智慧代理供應鏈安全
代理安裝軟體包與開發者複製 Stack Overflow 上的建議（或只是速度更快的版本）在本質上是不同的信任問題嗎？
兩者各佔一部分比例。這種機制速度更快，但信任差距也更大：Stack Overflow 上的答案是由人撰寫並經過非正式同行評審的，而 AI 生成的軟體包推薦則是一種概率輸出，沒有相應的評審，即使開發者手動複製，也會進行一些無人值守代理完全忽略的初步審查。
要達到什麼目標 SBOM 如何可靠地記錄“某個代理人添加了此內容，原因如下”？
今天的 SBOM 以及出處 standard這些系統都是基於這樣一個假設而建構的：每個依賴關係都是由人定義的。cis目前，他們還沒有一個欄位來記錄是哪個代理、哪個模型版本或哪個提示導致了特定的變更。要彌補這一差距，要么需要擴展現有的證明格式，要么需要一個單獨的、感知代理的審計追蹤來捕獲這些更改。cis離子溯源與建構溯源並存。
是否存在一種「向左移動」的變體，在最快的操作已經完成的情況下仍然有效？ pipeline 是自主代理，而不是開發者？
是的，但它必須改變檢查點，而不僅僅是時間點。基於人工審核的左移機制無法適應代理的運行速度；而基於沙盒、出口限制和安裝冷卻時間的左移機制仍然可以在受感染的代理的行動影響到生產環境之前將其捕獲，因為這些控制措施不依賴人工審核。
