一項資安調查將 Claude、OpenAI Codex，以及 Nous Research 的 Hermes 程式編碼代理，與企業環境中安裝未被認領的軟體套件聯繫起來。當研究人員測試那些指引代理前往目前沒有任何組織擁有之套件與網域的文件檔案時，這項活動浮現出來。

這些發現之所以重要，是因為這些命令看起來就像一般開發者的設定指令，而且在多個案例中還來自合法的企業網站。研究人員表示，他們在為概念驗證測試註冊一些被棄置的套件與網域名稱後的一小時內，就收到了來自一家 Fortune 500 公司的 callback。證據並未證實大規模入侵，但它顯示出具備 shell 存取權的 AI 代理，如何把過時文件變成軟體供應鏈的 प्रवेश點。

研究人員發現了什麼

根據 Ars Technica AI，一家位於以色列的隱密資安新創公司掃描了 6,214 個與國防承包商、Fortune 500 公司以及大型科技企業相關的線上網域。團隊辨識出 8,265 個使用新興 llms.txt 與 llms-full.txt 慣例的檔案，這些網站用它們來為 AI 系統提供機器可讀的描述與導覽。

在這些檔案中，有 120 個託管於不同網站，參照了一個或多個未註冊的套件名稱或未被認領的網域。整體而言，研究人員統計出 227 個用於安裝套件或存取當時不屬於任何人的網域的命令。許多參照涉及常見套件生態系統，包括 PyPI 與 npm。

為了測試風險，研究人員註冊了其中幾個被棄置的名稱，並架設了設計成在執行時會連線到其伺服器的套件。所產生的 beacon 識別出與 Claude、Codex 和 Hermes 相關的上層程序。研究人員在測試套件被處理後，也收到了來自數十個組織的 callbacks，其中包括一些 Fortune 500 公司與新創公司。

這項調查並未顯示這些公司遭到惡意軟體感染。它顯示的是，他們的環境執行了概念驗證程式碼，或以其他方式連到了研究人員的基礎設施。根據 Ars Technica AI，發稿時 Anthropic、OpenAI 與 Nous Research 尚未回覆置評請求。

文件問題如何變成執行風險

這種曝險源自 AI 程式編碼代理 如何結合瀏覽、檢索與命令執行。代理可能讀取供應商文件，將其內容視為權威，接著在本機或企業環境中執行設定命令。若所參照的套件從未被註冊過，攻擊者之後就能搶先認領該名稱，並以此發布惡意程式碼。

一種被記錄下來的模式，是對不存在的套件使用 pip install 或 npm install 指令。另一種則參照了不存在的測試框架網域。因此，這個資安問題不僅限於惡意網站或刻意投毒的提示詞。文件作者可能在多年前就輸入了錯誤、過時或幻覺生成的相依性，讓該參照留給他人認領。

研究人員還描述了與 Clerk 網站有關的一個案例。某個 llms.txt 檔案包含了一個 npx 命令，該命令所對應的套件名稱之後被他人認領並用來散布實際運作中的惡意軟體。由於 npx 可以在不將其加入專案相依性清單的情況下抓取並執行套件二進位檔，這條命令形成了一條特別直接的執行路徑。

Clerk 隨後修正了該文件問題。該公司表示，已經安裝相關套件 @clerk/eslint-plugin 的使用者，在它所描述的情況下並未暴露於該惡意套件之下。Clerk 的混亂是否造成真實感染，仍不清楚。

為什麼傳統防禦可能看漏訊號

這項調查凸顯了危險決策發生的時間點與企業資安工具通常尋找濫用的時間點之間的落差。執行 pip 或 npm 來處理知名套件倉庫的程式編碼代理，可能看起來就像一般開發活動。端點偵測與回應工具可能會看到一個獲准的 AI 助理，透過允許的網路連線啟動熟悉的套件管理器。

問題在於文件與相依性之間未經驗證的關係。代理也許能確認檔案來自官方 HTTPS 網域，且命令使用的是標準 registry，但卻無法確認套件所有權、發行者身分、來源，或該相依性是否為專案預期的一部分。這些檢查未必是代理預設工作流程的一部分。

這與 prompt injection 有關，但在一個重要面向上更廣泛。prompt injection 通常指刻意植入、用來操控模型的指令。在研究人員描述的情境中，最初的指令本身可以是真實且無害的。危險是在之後才出現，當被棄置的套件或網域變得可供攻擊者利用時。

這對 AI 建構者與企業團隊意味著什麼

對 AI 代理開發者而言，這些發現強化了應將檢索到的文件視為不受信任輸入，而非使用者命令延伸的理由。能執行 shell 命令的代理，應將閱讀指示與授權執行分開，對新相依性要求確認，並在安裝前檢查套件所有權與來源。當這些檢查失效時，沙箱化與受限網路存取可降低後果。

在企業內部署程式編碼代理的產品團隊，面臨一個更迫切的治理問題：助理是否應該同時對內部儲存庫、套件 registry、憑證與接近 production 的系統擁有不受限的存取權。實用的部署政策可以允許在隔離環境中進行程式碼生成與測試，同時封鎖任意套件安裝，或要求一份核准的相依性清單。

資安團隊應稽核自家網域上的 llms.txt 與 llms-full.txt 檔案，但風險並不只限於這些格式。代理也會讀取 README 檔、供應商 SDK 指南、issue 討論串、範例與第三方文件。組織需要在整個檢索路徑上建立相依性驗證與來源控管，包括可信合作夥伴與社群專案。

市場上的意涵比起投機更偏向實務。AI 程式編碼助理正被賦予更多行動權限，而軟體供應鏈防禦仍主要是圍繞人類開發者與傳統建置系統來設計。代理越常自動安裝工具，就越需要記錄為什麼選擇了某個相依性，以及是哪個來源授權了它。

接下來要觀察什麼

第一個訊號將是 Anthropic、OpenAI 或 Nous Research 是否披露其代理在處理安裝命令、未註冊套件與檢索到的指示時的變更。資安研究人員與企業使用者也應留意會標示被棄置名稱重用的套件 registry 控制，以及在執行前加入來源驗證的代理平台。

第二個訊號是企業是否稽核並修正其機器可讀文件。研究人員的掃描顯示，某些錯誤條目早於 AI 時代，這表示單靠清理可能無法解決問題。團隊需要隨時間監控套件所有權，而不只是當文件首次發布時驗證相依性。

最後，事件應變人員可能會尋找在受控測試之外也發生過類似 callbacks 或套件認領的證據。當前報導證明了曝險，以及至少一個與文件參照相關的實際惡意軟體案例，但並未量化受影響組織中已確認的感染數量。

Creati.ai 觀點

這起事件是對權限的警示，而不只是對模型準確度的警示。AI 代理可以對套件 registry 發出技術上正確的請求，但仍可能是在依據不安全的指示行事。當命令來自官方供應商網域時，這種差異很容易被忽略。

對企業而言，合理的回應不是放棄程式編碼助理，而是縮小它們能執行的範圍，並要求可驗證的相依性來源。在代理能可靠地辨識參考資料與授權之前，任何自動安裝都應被視為安全敏感動作。