模型准入需要未決狀態

AI模型准入決策必須說明允許工件推進的證據是什麼。當一次加載未產生任何被阻止的事件，但靜態檢查仍識別出危險全局對象時，批准操作會將兩個不同的發現壓縮成一個令人安心的單一答案。我希望未決的發現能夠貫穿整個決策過程並保留下來，同時清楚說明仍需確立的事項。

我們圍繞這一區別構建了Crucible，即我們的本地Model Vetting Firewall演示。它使用合成工件，其中包括一個簽名掃描器未標記但加載時嘗試執行數據庫操作的文件，以及另一個包含未執行條件分支的文件。第一個案例證明了為什麼觀察到的嘗試至關重要。第二個案例揭示了更困難的設計問題：當現有的檢查結果不一致時，如何在不假裝分歧已解決的情況下決定下一步該怎麼做。

證據改變決策

在合成數據庫示例中，PickleScan並未標記該工件。在加載期間，配置的CPython審計鉤子記錄並阻止了一次嘗試執行的SQLite數據庫操作。本地流水線返回QUARANTINE且未簽發簽名。數據庫操作並未成功；有價值的證據在於嘗試的效果及其被記錄的阻止。

這為准入決策提供了一個乾淨掃描器結果無法給出的理由。團隊可以指出被禁止的操作，而不是要求掃描器的標籤來回答關於加載的每一個問題。掃描器作為對照仍然有用，但沒有標記並不意味著可以抵消已觀察到的被阻止嘗試。

我更傾向於這種分離，因為這使決策具有可審查性。審查人員應當能夠追溯發現與結果之間的關係。「配置的鉤子阻止了該數據庫操作嘗試」是一個邊界明確的陳述。它指明了證據、機制以及本地裁定的原因。寬泛的安全標籤則會將這些關係隱藏起來。

觀察也創造了其自身的信任邊界。在此處，工作進程在Python子進程中嘗試加載並監測配置的審計事件。這是帶有進程隔離的演示儀器，而不是操作系統級或容器級的包容隔離。生產設計需要在向觀察工作進程託付不受信任的工件之前，確定該工作進程本身是如何隔離的。增加行為證據並不能免除審查收集證據之環境的責任。

靜默加載留下更棘手的問題

條件分支合成固件得出了不同的結果。靜態檢查發現了builtins.eval，這是該演示所配置的危險清單中的一個全局對象。由於在此環境中未執行條件分支，因此觀察到的加載未記錄到被阻止的危險事件。流水線將該工件路由至REVIEW，未簽發任何簽名。該路徑尚未完成任何人工作業調查。

有三種合理的應對策略值得考慮，每種策略付出的代價各不相同。批准意味著接受不確定性。拒絕避免使用該工件，但可能會放棄更深入調查本可解釋的內容。進一步審查則會推遲決策，並要求明確哪些額外證據能夠改變決策。

針對這種情況，我更傾向於審查，因為不確定性是具體的。存在明確識別出的靜態隱患和明確識別出的觀察盲區。靜默運行並未解釋為什麼存在危險全局對象，也未解釋如果觸發該分支會發生什麼。批准將意味著必須接受這一盲區。立即拒絕可能是一種合理的組織策略，但這將是基於未解決的靜態證據排除工件的選擇，而不是證明禁止的後果已經發生的證據。

當團隊制定准入策略時，這種區別至關重要。未觀察到某種後果不應默默演變成該後果不可能發生的結論。同樣，懷疑也不應默默演變成攻擊成功的證據。REVIEW提供了一個可以同時保留這兩項事實的機制，同時讓組織選擇其能夠接受多少不確定性。

REVIEW需要退出標準

單憑審查狀態可能會變成代價高昂的滯留區。只有當記錄說明了未解決的問題以及下一步必須做出的決策時，它才有存在的意義。在此示例中，問題涉及靜態全局對象和未執行的分支。在不改變調查內容的情況下重複相同的靜默加載，只會增加另一次觀察，而無法回答該問題。

在假設的企業流程中，團隊可能會檢查該分支、向工件供應商尋求可靠的解釋，或者選擇加載路徑更易審查的替代工件。這些都是提議的應對措施，而不是本演示所完成的工作流。每種方案都有其代價：更深入的檢查需要專業知識，供應商證據需要自身的驗證，而替換則可能犧牲所需的功能。選擇取決於團隊能夠獲得哪些證據，以及其策略允許何種不確定性。

我希望這種選擇是明確的。如果團隊在現有約束下沒有可行的調查能夠解決疑慮，那麼拒絕該工件可能是審查的合理終點。REVIEW不應承諾每個文件最終都能獲得批准。其目的是防止未解決的問題在裁定中消失，並使最終決策對既定策略負責。

同樣的準則也適用於AI解釋。在演示中，分析師與挑戰者的聯合建議可以增加審慎考量並將基準ALLOW結果轉為REVIEW；但它無法解除QUARANTINE。記錄的演示結合使用了緩存的Codex建議與新配置的檢查。一個合成參考記錄說明了將敘述視為權威的危險性：其建議建議簽署並推進，而最終結構化結果是REVIEW且未簽發簽名。

因此，准入使用者應當閱讀結構化裁定、門禁理由和實際簽名字段。有益的描述可以解釋決策，但描述絕不能成為向前推進工件的第二項衝突許可。倘若審查流程信任建議語句勝過最終門禁，就失去了其本應保留的界限。

批准同樣具有邊界

合成乾淨權重字典獲得ALLOW以及使用本地開發密鑰對其模型名稱、工件哈希和清單負載進行的簽名。其訓練數據來源和微調歷史記錄仍為UNKNOWN。只有ALLOW能獲得該簽名；REVIEW和QUARANTINE則不能。

這對於退出審查與乾淨路徑同樣重要。解決加載疑慮本身並不能確立訓練歷史。當上游問題仍未得到解答時，簽名可以在本地針對其密鑰驗證指定的負載。團隊應分別評估准入證據是否足以支持加載決策，以及缺失的來源對於預期用途是否可以接受。一項獲批的檢查不應平息其從未調查過的問題。

這份Crucible說明文件展示了這些本地示例及其證據。註冊表集成、企業准入執行和生產簽名保管仍然是本演示之外的工作。它的價值在於使決策邊界清晰可見，而不是聲稱本地實現提供了企業所需的所有控制措施。

以下是展示本地合成模型審查演示的創始人視頻。

對於正在評估准入設計的平台團隊，我建議從證據無法清晰吻合的案例入手。追問是什麼讓未決的發現保持可見，誰來決定更深入的調查是否值得其代價，以及什麼證據可以改變結果。一條乾淨的路徑很容易描述。未決的路徑才能揭示系統是否能將不確定性保留足夠長的時間，從而做出負責任的決策。