Lazarus 之後，模型發布流程才是真正的安全邊界

微軟 2026 年 11 月 10 日公布的 Lazarus 研究展示了透過少量權重修改植入觸發式後門的可能性。安全公告明確表示，尚未觀察到該技術被武器化。這是研究結果，不是正在發生攻擊的證據。

對企業而言，更重要的問題不是每個模型是否都藏著威脅，而是能否確認某次重要操作究竟由哪個模型完成。助手名稱、排行榜名次和採購合約都不能回答這個問題。真正執行的智慧體，是某個具體版本、某組具體權限與不斷變化的執行環境的組合。

本文的判斷是：模型完整性應該進入發布治理，而不能只留在安全研究部門。否則，選擇模型的人與為模型行為負責的人之間，會出現無人承擔的管理空隙。

三個問題，需要三種證據

模型評測回答系統在指定任務中做了什麼；成品驗證回答實際部署的物件是否就是批准的物件；授權回答某項操作是否被允許。三者無法相互替代。

設想一個通過全部發票處理測試的採購助手。測試結果支持我們信任它在已測流程中的表現，卻不能證明明天載入的是哪個檔案、誰批准了替換，更不能批准一筆異常付款。用一個綠色的評測標記回答所有問題，實際上是把不同決策壓縮成了一個容易誤導的訊號。

這也意味著，不應該因為新風險而否定評測。評測仍然有價值，但必須有明確邊界。合格的報告應當標註測試版本與設定，而不是讓產品名稱變成永久通行證。部署物件變化後，需要有人判斷哪些既有證據仍然有效。

來源紀錄最終要變成發布決定

SLSA 的來源規範討論可驗證的成品來源資訊；Sigstore提供簽章與驗證工具。它們是可借鏡的基礎，並不意味著任何一個標準可以單獨認證模型行為。

我們建議的最小發布紀錄，應把精確的成品識別碼與供應方、獲准轉換、評測結果、發布負責人及回復目標連接起來。適配器或格式轉換不能因為產品名字沒有變化，就從紀錄裡消失。企業需要重建實際部署的組合，而不是僅僅認出其中最知名的元件。

擁有證據與執行證據，也不是一回事。如果登錄系統保存審批紀錄，正式環境卻仍可隨意載入替代版本，這些紀錄只是檔案，不是控制措施。發布關卡必須讓獲准身分真正約束部署。緊急例外則應有明確負責人、有效期和事後複核，避免臨時繞行悄悄變成日常做法。

簽章能夠建立身分關係，卻不能證明簽署者做出了正確決定。來源清楚的版本，也可能不適合特定業務。因此，採購時應把成品身分、供應商變更流程與客戶自己的驗收要求分開詢問。

權限決定失誤有多貴

NIST 零信任架構反對僅憑位置或所有權賦予隱含信任。把這一原則作為分析類比，模型在企業內部執行，並不意味著它天然應該獲得廣泛權限。

同一個助手可以有兩種部署方式：一種只提交資料庫修改建議，等待審核；另一種持有長期憑證，可以改寫正式環境紀錄並匯出客戶資料。即使模型層面的不確定性相同，兩者的潛在損失也完全不同。風險評估的單位應該是「模型與權限的組合」。

這給出一個實用的投入順序：先梳理有實質影響的能力，再決定每項能力需要什麼證據。唯讀檢索、可復原編輯和不可撤銷的對外承諾，不應適用完全相同的發布要求。高影響操作需要由模型之外的機制約束，模型不能給自己授權。

這不等於每一步都增加人工點擊。過長的審批佇列可能誘發機械批准或私下繞行。更合理的設計，是區分有明確邊界的常規操作與例外，並把例外壓縮到審核者能夠理解的範圍。

容易被忽略的成本，是處理例外

購買安全工具時，人們經常關注偵測準確率，但實際預算還包括調查、隔離版本、延期上線和復原。掃描器如果只發出警報，卻不給足背景資訊，就可能只是把工作從研究團隊轉移到已經擁擠的發布佇列。

買方應該問：誰調查警報？能拿到什麼證據？合法變更如何解除隔離？正式系統多久能夠恢復到已知版本？這些問題才能檢驗控制措施能否承受日常業務壓力，也會讓能連接模型紀錄、部署歷史與操作日誌的工具，比孤立的儀表板更有價值。

市場層面的推論是一個假設，而非營收預測：隨著智慧體權限擴大，可證明的發布控制可能與能力、價格一起成為採購條件。能夠解釋每一個交付變體的供應商，可能優於只提供籠統安全承諾的供應商。

一個值得做的管理測試

在擴大智慧體權限前，請團隊選出上週一次重要操作，指出對應的精確模型版本、權限、審批證據與復原路徑。如果答案依賴共同使用的模型暱稱，或者某個人的記憶，缺口就已經足夠具體，可以著手修復。

Lazarus 不應被解讀為所有模型都已遭入侵，也不意味著一次掃描就能解決信任。更持久的啟示是組織層面的：把能力證據、身分依據與操作授權分開，並分別指定負責人。企業不必先洞悉所有潛在隱藏行為，才停止把無法追溯的模型更新視為普通設定修改。