讓 AI 助理存取 Proxmox：界線應該設在哪裡

這裡存在一個真實而略令人沮喪的不對稱。閱讀兩千行記錄、找出出問題的那一行，正是語言模型擅長的事。但這也正是大多數人無法讓它做的工作，原因在於存取權限的授予方式。

問題不在於模型該不該碰伺服器，而在於界線設在哪裡，而現今這條界線通常設錯了地方。

常見做法為何令人不安

把助理接上 Proxmox 有兩種常見方式：給它一個 SSH 工作階段，或給它一個具備完整權限的 API 權杖。兩者其實是同一回事。從那一刻起，模型與硬體之間再也沒有任何阻隔，所有防護都只存在於提示詞的措辭之中。

提示詞不是界線。它只是一個請求，提出的對象是一個設計上力求幫上忙的系統，使用的是一種沒有任何強制力的語言。

風險在於缺乏脈絡，而非惡意

這是最常被誤判的部分。失敗的模式很少是模型決定刻意造成損害，而是模型根據不完整的全貌做出了正確的動作。

一顆看似空著的磁碟。模型讀到一個沒有掛載檔案系統的裝置，就把它當成可用空間。但這個裝置其實屬於一台只是處於關機狀態的虛擬機器。

一個降級的儲存池。模型讀到降級狀態，便提議重建整個陣列。正確的步驟其實是更換一顆硬碟，而重建正是讓剩餘資料遺失的做法。

一個顯示為未執行的服務。它沒有在執行，是因為它依排程執行而且已經結束。重新啟動它無傷大雅；但因為它老是停下來就把它停用，就不是這麼回事了。

在這三個例子中，指令本身都寫得正確，錯的是前提。而建立在錯誤前提上的正確指令，事後看來與蓄意破壞毫無分別。

唯讀有幫助，但並非完整的答案

顯而易見的做法是只授予唯讀存取，這確實能排除最糟的結果。但仍有兩件事沒有解決。

讀取並非沒有代價。設定、記錄與稽核記錄中包含主機名稱、位址、使用者名稱，有時還有被貼到不該出現之處的權杖。一個擁有完整讀取範圍的唯讀助理，等同於整套基礎架構的匯出檔。

只診斷不行動，會停在半路。如果有用的答案是重新啟動某一個服務，唯讀架構就得把發現交還給人再輸入一次。這沒有問題，但這也正是人們日後悄悄放寬權限的原因。

因此，唯讀是好的起點，卻是差勁的終點。終點應該是範圍狹窄的寫入權限，並通過與人相同的關卡。

界線真正該在的位置

不在提示詞裡，也不在模型內部，而在負責執行的那一層，因為那是唯一能夠拒絕的地方。

有三項特性讓這樣的一層值得信任，而且三項都可以實際驗證，而非只是承諾。

權限來自原本就掌管權限的系統。如果助理以一個既有帳號連線，那麼該帳號能碰的範圍，就正好是助理能碰的範圍。不另外發明第二套權限模型，因此沒有需要保持同步的東西，兩者也不可能互相矛盾。

破壞性操作要通過與人相同的關卡。如果刪除磁碟時會要求人確認，那麼由模型發出請求時也必須要求確認。一條對人安全、對自動化卻敞開的路徑不是界線，而是一條取了好聽名字的捷徑。

每一個步驟都寫入稽核記錄。誰、做了什麼、何時、對什麼、結果如何。少了這些，事故之後最有用的問題，也就是這件事是不是助理做的，便無從回答；而無法回答本身，就是不授予存取權限的理由。

面對任何這類工具都該問的問題

該問的不是安不安全，而是由什麼負責拒絕，它又位在哪裡？

如果答案是模型被指示不要這麼做，那就沒有界線。如果答案是執行層會檢查帳號的權限，並對破壞性步驟設下關卡，那就有界線，而且可以實際測試：以受限帳號連線，確認拒絕確實發生。

Atlas 的做法

⚠️ 這一層仍在規劃中，尚未推出。以下是它正依循建構的設計，之所以寫在這裡，是因為上面的問題值得一個誠實的答案，而不是行銷式的答案。

構想是讓助理接上 Atlas，而不是直接接上 Proxmox。Proxmox 位於底層，模型永遠不會直接觸及它；它只能使用 Atlas 本身能做的事，也就是說，所有既有的關卡都留在路徑上。

界線由 Proxmox 權限劃定，這正是上述的第一項特性：連線帳號能碰到什麼，助理就只碰到那麼多，不會出現新的權限概念。破壞性操作保留原有的確認步驟，而稽核記錄早已為每一項特權操作記下誰、做了什麼、何時、對什麼與結果如何，包括被拒絕的操作。

它也預計作為獨立元件，而非安裝的一部分：不需要它的主機，就永遠不會有它存在。這一點之所以重要，理由與本文其餘部分相同。對於一項尚未選擇要用的功能，最安全的界線就是它根本不存在。