<summary>LM Studio 的 Bionic 新增 Auto Review，以 Shell Judge 先做 AST 靜態分析，再由 Shell Reviewer 補足判斷，目的是降低 AI 代理執行 Shell 指令時的風險與人工確認成本，但仍無法完全消除提示注入與環境竄改帶來的安全盲點
LM Studio 為其 AI 代理應用 Bionic 新增 Shell 指令自動審查功能 Auto Review，核心目標是讓 AI 代理在準備執行 Shell 指令時，先經過安全判斷再決定是否放行。這套設計的重點，不是單純攔截危險字串，而是把指令拆解後逐步評估，盡量減少使用者逐一確認每一條命令的負擔。
Auto Review 採兩階段流程：第一階段由 Shell Judge 進行程式分析，若無法完整判斷，才交由第二階段的 Shell Reviewer 審查代理處理。LM Studio 公布的觀察結果顯示，Shell Judge 在其開發人員實際使用情境中，最高可直接核准約 82% 的 AI 代理指令，但官方也明確說明，這只是經驗性觀察，不是正式基準測試。
Shell Judge 的設計重點在於不依賴大型語言模型，而是先把 Shell 指令解析成抽象語法樹（AST），再分析指令可能執行的程式、讀寫的檔案與參數，並與預先建立的安全規則比對。系統目前可分析 sh、bash、zsh 與 PowerShell 等命令列環境，顯示其目標是涵蓋常見的互動式與自動化執行場景。
這種作法的價值，在於它不只看指令名稱，而會進一步檢查參數、變數可能帶入的內容，以及檔案存取範圍。也就是說，同一個指令在不同參數下可能有完全不同的結果，Shell Judge 必須確認「實際會做什麼」，而不是僅判斷「它是什麼指令」。只有當操作行為能被完整判斷時，系統才會自動核准；無法確認者，才進入 Shell Reviewer。
第二階段的 Shell Reviewer 則負責處理第一階段無法消化的情境。它會分別評估操作風險與使用者授權狀態，也會檢查指令本身是否有明顯錯誤。對高風險操作，系統需要有使用者明確授權依據；若判定可能造成過度破壞，即使使用者曾允許，也不會自動執行。這表示審查邏輯不只是「有沒有允許」，還包含「允許的內容是否仍在安全可接受範圍內」。
LM Studio 也特別處理提示注入風險。審查代理會參考先前對話內容，以判斷使用者是否曾同意相關操作，但不會讀取工具執行後回傳的內容，藉此降低外部內容夾帶惡意指示、干擾 AI 判斷的機會。不過，LM Studio 同時指出，這類設計只能降低風險，無法完全阻止提示注入。
另一個值得注意的限制，是 Auto Review 與沙箱屬於不同層次的防護。Shell Judge 的判斷建立在電腦環境與執行程式本身可信的前提下，例如系統中的 Git 確實是正常程式、相關設定也未遭惡意修改。若執行檔或軟體設定本身已被竄改，單靠 Shell 指令分析仍無法辨識相關風險。換言之，Auto Review 是「執行前判斷」，不是「環境完整性驗證」。
這項更新最直接影響的是使用 Bionic 進行程式開發、文件處理與自動化工作流的使用者。當 AI 代理需要操作 Shell 時，系統可以先過濾掉大量明顯安全的命令，減少反覆彈出確認視窗的摩擦，讓代理工作更接近「半自動」而非「每步都人工審核」。
對開發團隊而言，Auto Review 的價值在於提升代理式工具的可用性，讓安全控制不再完全仰賴人工。對資安團隊而言，這則案例則提醒：AI 代理的風險控制已從單純提示詞管理，進入到命令語意分析、授權脈絡判定與上下文隔離的綜合階段。
但它同時也反映出新的攻擊面。只要代理會讀取對話、調用工具、依上下文做決策，就可能受到提示注入、上下文污染與工具回傳內容干擾。即使 Shell Judge 能擋下多數命令，真正危險的未必是單一指令本身，而是整個執行環境是否可信、是否已被預先植入偏差資訊。
若組織正在導入類似 Bionic 的 AI 代理工具，建議將 Auto Review 視為輔助控制，而非唯一防線。第一步應是把命令審查、使用者授權、工作流程權限與主機完整性檢查分層處理，避免只靠單一模型或單一規則集決定是否放行。
第二步，對高風險命令建立更明確的授權門檻。凡是可能造成大量刪除、覆寫、外部傳輸或環境變更的操作，都應要求明確、可追溯的使用者授權，並保留審核紀錄，以便事後回溯。
第三步，縮小代理可見的上下文與工具輸出範圍。既然審查代理不讀取工具回傳內容是為了降低提示注入風險，那麼在實務上也應該限制工具回傳的敏感資料量，避免惡意內容透過輸出回滲到決策鏈。
第四步，確保執行環境與常用工具的完整性。因為 Shell Judge 預設系統程式與設定可信，所以若主機已遭竄改，前端審查再精細也可能失效。環境基線、程式簽章、設定異動監控與權限分離，仍是不可替代的底層條件。
第五步，把 Auto Review 納入紅隊測試與安全驗證流程。特別要檢查變數展開、巢狀命令、不同 Shell 語意差異，以及對話歷史被污染後的判斷偏移，才能真正了解這類防線在真實攻擊面下的韌性。
5步驟修補清單