227 條懸空安裝指令：llms.txt 檔案如何讓企業文件變成攻擊面

2026 年 8 月 27 日，Ars Technica 資深資安主編 Dan Goodin 發表了一篇報導，其反派角色很不尋常：沒有人。它描述的威脅不是某個駭客組織或國家級工具，而是 227 條靜靜躺在企業文件裡的安裝指令，指向沒有任何人的套件與網域。任何人都可以認領它們。而在某些全球最大企業的內部，AI 編碼代理已經在執行這些指令。

這項研究由以色列一個新創團隊（包括研究員 Alon Hertz）執行，掃描了 6,214 個屬於國防承包商、財星 500 大企業與大型科技公司的活躍網域。目標不是應用程式碼或網路基礎設施，而是 llms.txt 與 llms-full.txt 檔案——一個仿效 robots.txt 的新興慣例，網站透過它發布供 AI 代理讀取的機器可讀摘要與安裝說明。

他們的發現為代理時代重新定義了一個經典的供應鏈弱點。而其概念驗證——在一小時內就收到真實財星 500 大企業網路的回呼——證明問題不是理論，至少一個野外惡意套件已經被抓到。

研究人員發現了什麼

在掃描網域中發現的 8,265 個 llms.txt 與 llms-full.txt 檔案裡，有 120 個檔案（各來自不同網站）引用了至少一個未註冊的套件或無人認領的網域。這些設定錯誤的檔案總共包含 227 條指令，叫讀者安裝 PyPI 或 npm 上不存在的套件，或造訪沒人註冊的網域。

典型的條目看起來毫無殺傷力：「Installation: pip install [已隱藏]」或「npm install [已隱藏]」。有個檔案引用了一個架在任意人都能購買之網域上的測試框架。這些條目之所以是陷阱，不是因為惡意，而是因為懸空——指向原發布者從未認領的命名空間的孤兒引用。

這些失效條目的來源不一。有些完全早於 AI 時代，是從較舊的非 LLM 檔案複製過來、由人工撰寫的。其他很可能由 AI 工具自己生成——幻覺出來的套件名稱，或從不可信來源抓取、連生成模型都無法與正當指令區分的內容。兩者的結果完全相同：一份權威十足的檔案，透過 HTTPS 從公司官方網域送出，叫代理去抓一段沒人認領的位置上的程式碼。

概念驗證：在財星 500 大企業內執行程式碼

找到懸空引用是一回事，證明真實代理會照做又是另一回事。研究人員註冊了其中幾個無人認領的名稱，並架設了執行後會向研究人員伺服器回報的套件。

一小時內，他們收到第一個回呼——來自一家財星 500 大企業。 接下來幾天又收到數十個，其中包括更多財星 500 大網路與多家新創公司。信標還記錄了每次安裝背後的父程序鏈，揭露了執行者：在這些企業網路內運作的編碼代理，包括 Anthropic 的 Claude、OpenAI 的 Codex，以及 Nous Research 的 Hermes。

在報導刊出前，Anthropic、OpenAI 與 Nous Research 都未回應 Ars Technica 的置評請求。

研究人員的診斷很直白：「信任模型已經失效。代理把廠商文件視為真理，毫不質疑——監督它們的人類也一樣。代理式 AI 的使用正在爆炸性成長，代理滲透到每一層——SaaS、雲端、端點。它們越多，供應鏈攻擊面就越大，而現有的防護根本沒覆蓋到。」

野外實例：透過 npx 散布的 clerk.com 惡意套件

整個發現中最可怕的並非概念驗證，而是至少一個真實攻擊已經用過這個模式。

研究人員在知名身分驗證廠商 Clerk 的官方網站上發現一個 LLM 檔案，內含指令 npx clerk-next-fix-auth-protection。npx 工具在此格外危險：與傳統安裝不同，它會把套件抓進 npm 快取並立即執行其公開的二進位檔，不會把任何東西加進專案的依賴清單——也就是說，這個動作留下的稽核軌跡更淡。

有人已經認領了那個一度空著的套件位置，並用它架設了活的惡意軟體。Clerk 事後已解決問題，並表示已安裝正牌 @clerk/eslint-plugin 二進位檔的代理不會受到這個相似名稱套件的影響。至於惡意套件是否真的感染了任何人，目前仍不清楚。

為什麼每一層信任會同時失效

這類攻擊真正新穎之處，在於它不是利用漏洞擊敗防禦，而是把「正確行為」武器化。研究人員逐一說明為什麼沒有任何安全層會觸發警報：

• 對代理而言，檔案透過 HTTPS 從公司官方網域送出，採用公司自己發布的標準化 AI 格式。「檔案就是權威——這正是它存在的目的，」他們寫道。當檔案說 pip install internal-tool，代理不會停下來確認 internal-tool 是否屬於這家公司、不會去 PyPI 驗證命名空間、不會注意到文件連結指向一個三個月前到期的網域。「它就是照檔案說的做。」
• 對端點而言，這看起來就像開發者在跑合法的套件管理器——從 pypi.org 執行 pip install（每個企業代理伺服器都放行的網域），父程序是公司特意安裝的編碼代理。「沒有異常。沒有警報。失敗發生在上游，在指令與執行之間的縫隙裡。」
• 信任鏈是可傳遞的。 llms.txt 不需要放在財星 500 大企業自己的網站上。如果代理信任合作夥伴的文件、廠商的 SDK 參考或社群安裝指南，而那個第三方的檔案指向未認領的套件，整條鏈的運作方式完全相同。

舊邊界崩塌的新名字

資安研究人員花了兩年記錄提示注入（prompt injection）——攻擊者刻意在 AI 會讀的內容裡植入惡意指令。這項研究顯示，威脅在結構上比對抗性注入更廣。

「在提示注入裡，有人刻意植入惡意指令，」Hertz 告訴 Ars。「這裡的指令本身完全可以是良性的、來自合法來源——某家真實公司自己的文件——撰寫當下沒有任何惡意行為者參與。危險在之後才出現：當它指向的套件或網域被棄置、被別人認領的時候。」

正如研究人員所言：「代理不區分頁面和指令。它讀到的一切都是輸入，而每個輸入都是潛在的指令。這意味著代理如今所消費的整個已發布資料集，已經默默變成執行面——而其中幾乎沒有任何一部分，承載著我們套用在真正程式碼上的完整性保證。」

資料與程式碼之間的界線——編譯器、沙箱與程式碼簽章體系守護了數十年的邊界——在 LLM 內部並不存在。「Clerk 案例是最乾淨的證明，」他們寫道。「那條指令看起來就像廠商自己會出貨的東西——因為它就在廠商自己的指令檔裡。唯一缺少的是註冊表裡的那個名字。每一層信任都完好無缺，除了沒人想到要檢查的那一層。」

該怎麼辦

這些發現對任何操作具備 shell 權限代理的人都有直接的行動建議：

1. 執行前驗證命名空間。 代理（或其執行環境）在安裝第三方文件引用的套件前，應先確認該套件確實屬於發布組織——註冊所有權、下載歷史、發布者身分。
2. 稽核自己的 llms.txt。 如果你的公司發布 AI 指令檔，裡面的每一條安裝指令與網域引用，都是一則關於供應鏈所有權的承諾。把它們當正式程式碼對待，而非行銷文案。
3. 別讓代理無人監督地對不可信文件執行 npx/pip install。 正如 Hertz 所言，監督這些代理的人類，往往也投射了同樣不加置疑的信任。
4. 把註冊表監控當作防禦基礎設施。 監看有無人註冊出現在你公開文件中的名稱，能讓這種攻擊從免費變昂貴。

對一個正把代理接進所有東西的產業來說，更深層的教訓並不舒服。Slopsquatting——攻擊者註冊幻覺套件名稱——在模型生成假依賴時就已經是已知風險。這項研究顯示，同樣的攻擊在模型僅僅閱讀文件時也能成立，而且是生態系規模，文件本身還是由信任鏈中最受信任的一方發布的。代理消費的語料庫默默地變成了執行面。能讓它安全的防護大多還不存在——在它們出現之前，指令與執行之間的縫隙，就是下一代供應鏈攻擊的棲身之所。