我在 Hugging Face 上發現了被植入後門的 AI 模型——而每個認真查過的人也都發現了
那是一個週二的晚上，我正看著我的一位工程師做一件本該是例行公事的事：把一個 Hugging Face 上的預訓練模型載入測試環境。標準流程。我們做過幾百次了。但這一次，我剛好才讀完 JFrog 在 2024 年 2 月發布的揭露報告——就是那份他們的資安研究員在 Hugging Face 上發現超過 100 個惡意模型的報告，其中有些帶著後門，你一載入，攻擊者就取得遠端存取權——而我沒辦法把視線從終端機上移開。
「等一下，」我說。「那個模型是什麼格式？」
Pickle。
我的心一沉。
就在那一刻我意識到，我們對待 AI 模型的方式，就像業界在 2014 年對待開源函式庫一樣——把它們當成本質上就值得信任的產出物，直接從網路上拉下來就執行。而我當下就明白了，那是一種只有在親眼看著自己的假設即時崩塌時才會有的確信：這將成為未來十年最具決定性的資安危機之一。
會偷偷回撥主控端的模型
以下是 Hugging Face 上實際發生的事。一位名叫「baller423」的使用者上傳了一個看起來完全正常的 PyTorch 模型。名稱合理、描述說得通、指標看起來也還不錯。但在它以 pickle 序列化的權重裡，埋著一段酬載（payload）：只要有人一執行 torch.load()，它就會向一個屬於 Korea Research Environment Open Network 的 IP 位址開啟一個反向 shell。
這不是理論上的攻擊。不是概念驗證。這是一個活生生、已被武器化的模型，就擺在全世界最熱門的 AI 模型平台上，等著有人把它下載下來。
而「baller423」並不孤單。JFrog 找到了大約 100 個這樣的模型——每一個都是偽裝成好用預訓練成果的特洛伊木馬。
當你對一個 pickle 檔案執行 torch.load() 時，你不是在載入資料。你是在執行程式碼。而在為時已晚之前，你完全不知道那段程式碼會做什麼。
我必須解釋為什麼這件事如此危險，因為大多數人——甚至大多數工程師——都不了解 pickle 到底是什麼。Python 的 pickle 格式不只是一種資料序列化方法。它是一台以堆疊為基礎的虛擬機。它可以在反序列化的過程中執行任意的 Python 函式。當你的資料科學家載入模型時，pickle 可以無聲無息地呼叫 os.system() 或 subprocess.run()，而且全在背景進行。模型運作得好好的。預測看起來也很正常。而與此同時，地球另一端的某個人，已經在你的伺服器上拿到了一個 shell。
這不是一個臭蟲。這就是 pickle 當初被設計出來的樣子。我們只是從來沒認真想過：當這些檔案來自網路上的陌生人時，那代表什麼。
為什麼掃描器沒有攔下它？
這正是那一晚讓我睡不著的部分。我們有資安工具。業界有 PickleScan，那是審查模型檔案的標準工具。Hugging Face 自己也在跑它。這麼明目張膽的東西，掃描器總該抓得到吧？
沒有。而且情況還更糟。
JFrog 後來在 PickleScan 本身找到三個零日漏洞——其中一個登記為 CVE-2025-10155——攻擊者只要操弄副檔名，或利用 ZIP 壓縮檔的解析差異，就能完全繞過偵測。一個惡意模型，可能被那個原本設計來保護你的工具標記為「安全」。
統計數字很慘澹：目前掃描器的警報中，高達 96% 是誤報。想想這對一個資安團隊會造成什麼影響。在第一百次假警報之後，你就不再細看了。你開始反射性地點下「核准」。而真正的威脅，正是在這個時候走進門來。
我為這件事和我的一位團隊主管激烈爭論過。他認為我們反應過度。「我們只從已驗證的組織拉模型，」他說。我把 JFrog 的資料拿給他看。我還讓他看到，就連比較新的「安全」格式，例如專門為了避開 pickle 問題而設計的 GGUF，也被發現在中繼資料裡藏著惡意的 Jinja 樣板——它們在推論時執行，而不是在載入時執行。掃描器永遠看不到，因為攻擊發生在更後面，在模型已經跑起來的時候。
他沉默了很久。然後他說：「那我們到底能信什麼？」
這才是對的問題。
當你的 AI 裡面住著一個潛伏特工，會發生什麼事？
Hugging Face 事件講的是粗糙、可偵測的酬載——反向 shell、明顯的程式碼執行。但更深層的威脅，那個真正讓我害怕的，是資料下毒（data poisoning）。而這方面的研究，令人不寒而慄。
NVIDIA 的 AI 紅隊結合 Anthropic 的研究發現證明：你可以在一個 130 億參數的模型中永久植入一個隱藏行為，而所需要的，只是污染 訓練資料的 0.00016%——大約是數百萬份文件中的 250 份而已。
讓這個數字沉澱一下。兩百五十份文件。
被下毒的模型能通過每一項基準測試。在標準測試上，它的表現和乾淨模型完全一樣。但當它遇到特定的觸發條件——某一段特定文字、某種影像圖樣，甚至是對輸入資料做位元層級的操弄——它就會切換行為。它可能繞過身分驗證。它可能外洩資料。它可能產生惡意程式碼，然後被灌進下游系統。
被下毒的 AI 模型是完美的潛伏特工：它通過每一項測試，在每一項基準上都拿高分，然後耐心地等待一個只有攻擊者知道的觸發條件。
而數學上最讓人揪心的一擊是：加入更多乾淨資料並不能修好它。一旦後門達到某個門檻——通常是訓練過程中觸發條件出現 50 到 100 次——它就被永久地烘進權重裡了。你訓練不掉它。你也稀釋不掉它。
NVIDIA 把這一切形式化為他們所稱的 AI Kill Chain（AI 攻擊鏈）：偵察（Recon）、下毒（Poison）、劫持（Hijack）、潛伏（Persist）、衝擊（Impact）五個階段，描繪出攻擊者如何有系統地入侵機器學習系統。我在 我們的互動式研究總覽 中寫過這個框架，以及完整的攻擊向量光譜；我會鼓勵任何要把模型部署到生產環境的人，花點時間好好讀一讀。
對任何用自家資料微調模型的企業來說，這個含意很赤裸：就算你的專有資料集乾乾淨淨，你從公開儲存庫下載的基礎模型，可能早就已經被入侵了。你正在一個你看不進去內部的地基上蓋房子。
沒有人想談的 Shadow AI 問題
我曾和一家中型金融服務公司的資安長（CISO）共進晚餐。她幾乎是不經意地告訴我，她的團隊最近在公司各處的生產環境中，發現了 47 個不同的 AI 模型正在運行。而她的 AI 治理政策，只涵蓋其中三個。
這就是 Shadow AI（影子 AI），而且它已經成為一場流行病。數據令人震驚：企業內 90% 的 AI 使用行為，發生在 IT 與資安團隊的視線之外。 開發人員與業務單位從公開儲存庫拉取未經審查的模型，因為官方流程太慢。他們把專有程式碼與客戶資料貼進公開的 AI 工具——有 77% 的員工被觀察到做過這件事。而這些未經授權的模型，每一個都是從未被任何掃描器碰過的潛在後門。
財務衝擊並不抽象。牽涉到未經審查 AI 工具的資安事件，會讓一次資料外洩的成本平均增加 $670,000。這就是你為了在沒有治理的情況下「快速前進」所付出的溢價。
我懂那種衝動。我真的懂。當你是一個想趕快把功能上線的工程師，而資安審查流程要花三週，你當然會忍不住直接從 Hugging Face 拉一個模型接上去。那種誘惑我自己也感受過。但 JFrog 的揭露報告本該終結那個時代。我們現在已經有實證上的確定性：公開的模型平台上就是有被武器化的產出物。把它們當成可信來源，在 AI 領域裡就等同於在生產環境中執行 curl | bash，而且來源還是某個隨機的 GitHub gist。
為什麼大家還在盲目飛行？
NIST 在 2024 年發布了 AI 100-2 指引——一份針對對抗式機器學習攻擊與緩解措施的完整分類體系。這是很好的成果。它給了業界一套談論這些威脅的共同語言。而幾乎沒有人真的把它落實。
數字很難看：
- 只有 17% 的組織具備自動化的 AI 安全控制措施
- 只有 12% 的組織有完整的 AI 治理機制到位
- 只有 14% 的組織對內部 AI 資料流具備可見度
- 83% 的組織，用 NIST 的說法，正在「盲目運作」
我近距離看過這個落差。組織把「有一份政策文件」和「有可運作的資安」混為一談。他們會拿出一份排版精美的 AI 治理 PDF 給你看，而同一時間，他們的開發人員正把未經簽章的 pickle 模型載入生產環境的 Kubernetes 叢集。文件存在。控制措施不存在。
83% 的企業對自己的 AI 供應鏈沒有任何自動化控制。那不是一道落差——那是一扇敞開的門。
我們如何開始把模型當成惡意程式碼看待
在那個週二晚上的頓悟之後，我在 Veriprajna 的團隊花了好幾週重新設計我們接收模型的方式。核心的觀念轉變很簡單，卻也很激進：在未經證明安全之前，把每一個 AI 模型都當成可能帶有惡意的可執行程式碼。
不是「應該沒問題」。不是「來自有信譽的來源」。是可能帶有惡意。就這樣，沒有例外。
機器學習物料清單（ML-BOM）
我們首先需要的是透明度。傳統的軟體物料清單（SBOM）追蹤函式庫與版本，但 AI 產出物需要更多東西：一份 ML-BOM——機器學習物料清單——記錄資料來源、模型血緣、框架相依性，以及密碼學證明。
訓練資料是從哪裡來的？是誰微調了這個模型，又是用什麼資料微調的？用的是哪一個版本的 PyTorch，它有沒有已知漏洞？我們能不能用密碼學方式驗證：我們正在載入的模型，就是由可信流水線產出的那一個產出物，而且在傳輸過程中沒有被竄改？
如果你回答不了這些問題，你就不知道自己在部署什麼。
殺掉 Pickle，為一切簽章
我們立刻做了兩個工程決定。第一：不再用 pickle。就這樣。我們流水線上的每一個模型都使用 SafeTensors——一種只儲存張量資料搭配 JSON 中繼資料、且在載入時無法執行程式碼的格式。它比 pickle 更不靈活，而這正是重點。
第二：模型的密碼學簽章。每一個模型產出物都有唯一的雜湊值，並以我們內部的 PKI 基礎設施簽章。我們的推論伺服器會跑一個准入控制器，在權重被反序列化進記憶體之前，對照我們的信任根驗證簽章。如果簽章對不上，模型就不會載入。沒有例外，不能覆寫，也沒有「可是這只是拿來測試的」。
我的一位工程師對此強烈反彈。「你這是在開發流程裡加摩擦力，」他說。他說得沒錯。我是故意加摩擦力的。因為另一條路——那條任何人都能從任何地方載入任何模型的無摩擦之路——正是你的推論伺服器上最後會跑著一個通往韓國的反向 shell 的原因。
執行時期監控：因為靜態掃描並不足夠
我們從 GGUF 樣板漏洞學到：靜態掃描只能涵蓋威脅面的一部分。一個模型可以在載入時是乾淨的，卻在推論時變成惡意的。所以我們加上了持續的執行時期監控：對照乾淨基準線的輸出驗證以偵測漂移、防止模型萃取攻擊的查詢節流，以及在查詢抵達核心模型之前先改寫查詢的輸入淨化層，用來打斷精心設計的對抗性酬載。
完整的技術架構——包括我們以硬體支援的可信執行環境（TEE）進行機密運算的做法——請見 我們研究論文中的技術深入剖析。那裡的實作細節深度，遠超過我在一篇隨筆裡所能涵蓋的範圍。
關於「Deep AI」與 API 包裝層的不舒服真相
我一再回到我所謂「Deep AI」——自行託管、經過微調、在架構上受控的 AI 系統——與市場上主流的 API 包裝層做法之間的區別，是有原因的。這不只是技術偏好。這是一個資安論證。
當你包裝一個公開 API，你就把自己的 AI 供應鏈外包給別人了。你對他們的模型來源、他們的訓練資料、他們的資安態勢完全沒有可見度。你是在相信 OpenAI 或 Anthropic 或 Google 已經做完了保護自家流水線的苦工。也許他們做了。但你無法驗證，而在資安領域，沒有驗證的信任，只是一廂情願的希望。
當你往深處建構——當你掌控模型權重、訓練流水線、推論基礎設施——你就承接了整條供應鏈的責任。這比較難。也比較貴。它需要我一直在描述的那種工程紀律。但這是通往可驗證資安的唯一路徑。
曾經有一位投資人告訴我：「直接用 GPT 的 API，專心做產品就好。」我告訴他，對我們服務的產業來說——在那裡，一個被入侵的模型可能意味著財務資料外洩、醫療診斷被操弄，或法律分析被汙染——「直接用 API 就好」是一種責任風險，不是一種策略。
AI 資安與軟體資安，現在已經是同一個問題
以下是讓一切在我腦中成形的洞見：AI 資安與軟體供應鏈資安已經不再是兩門分開的學問。它們不可能分開。AI 模型不是孤立運行的——它們是透過傳統軟體所使用的同一套 CI/CD 流水線、容器登錄庫與相依樹來建構和部署的。
如果你的模型有密碼學簽章，但它所依賴的 Python 函式庫已經被供應鏈攻擊入侵，那你就是被攻破了。如果你的訓練流水線跑在一個被汙染的容器映像檔裡，那不管你的訓練資料多乾淨，你的模型權重都不可信。
業界一直想要分別設立「AI 資安」團隊和「應用程式資安」團隊。那種組織上的切割本身就是一個漏洞。攻擊面是統一的，防禦也必須是統一的。
隨著 AI 生成的程式碼加快了開發速度，傳統由人工進行的程式碼審查流程，正在數量的重壓下崩潰。在期限壓力下，大型的、AI 生成的 pull request 很難仔細審查，於是形成一種「淺層審查」文化，把最後幾道人在迴路中的資安控制之一給拿掉了。在這樣的環境裡，以密碼學簽章與 ML-BOM 為根基的自動化、確定性驗證，不是選配。它是唯一能規模化的東西。
「但我們又不是目標」
人們總是會用這句話的某個版本來反駁。「我們做的事情沒敏感到需要這種等級的資安。」「我們的模型只是內部工具用的。」「不會有人特地去下毒一個模型來攻擊我們吧。」
2018 年，我聽過關於開源函式庫資安的一模一樣的說法。然後 SolarWinds 發生了。然後 Log4Shell 發生了。然後 XZ Utils 後門發生了——那是一場長達數年的社交工程行動，目標只是入侵一個壓縮函式庫，而全世界每一台 Linux 伺服器上的 SSH 都在用它。
AI 供應鏈正在走同一條軌跡，只是更快。攻擊面更大（模型權重是不透明的二進位資料塊，無法像原始碼那樣被稽核）、工具更不成熟（PickleScan 有零日漏洞），而治理落差也更寬（83% 的企業沒有任何自動化控制）。
你不需要成為目標，也能成為受害者。你只需要剛好在路徑上。
無聊的 AI 資安長什麼樣子
我的目標——這聽起來可能很奇怪——是讓 AI 部署變得無聊。不刺激、不前衛、不是「快速前進，打破一切」。無聊。可預測。可稽核。
無聊意味著每一個模型都有 ML-BOM。無聊意味著在載入時驗證密碼學簽章。無聊意味著永遠不用 pickle。無聊意味著執行時期監控，在漂移變成外洩事故之前就抓到它。無聊意味著一個集中的 AI 資產登記庫，其中每一個模型、資料集與相依項目都被追蹤、審查，並納入版本控制。
無聊意味著，當有人問「生產環境裡在跑哪些 AI 模型？」，你可以在五分鐘內回答，而且附上密碼學證明。
目標不是讓 AI 部署變得刺激。而是讓它變得無聊——可預測、可稽核、安全。刺激的 AI 資安，代表有什麼事情出錯了。
Hugging Face 上那 100 多個惡意模型並不是孤立事件。它們是一個症狀，反映出一個把驚人能力建立在盲目信任地基上的產業。我們下載模型的方式，就像當年從 LimeWire 下載 MP3 一樣——祈禱一切順利、無視明顯的風險，然後在出事時裝出一副驚訝的樣子。
那個時代結束了。能在下一波 AI 供應鏈攻擊中存活下來的組織，會是那些此時此刻就決定：不把自己的模型當成魔法盒子，而是當成可執行程式碼——連同它所隱含的完整攻擊面——的組織。那些選擇無聊、而不是選擇快的組織。那些看著終端機、看見 pickle 檔案正在載入，然後說：「等一下。那是什麼格式？」的組織。
