你把 coding agent 放進沙盒，看見陌生網站被擋住，於是以為資料出站已經管住了。等你開啟 OpenShell Auto-Approval，原本被拒絕的公開主機卻可能在規則自動批准後變得可達。這篇教你用四組無害測例，自己驗收「誰能替沙盒放行新目的地」。
本文寫給第一次管理 Agent 沙盒、會照著指令操作終端機的讀者。你會建立一個獨立測試沙盒，用假資料和自己控制的收件端，記下政策、提案、日誌與回滾結果。文中的「預期」是驗收標準，並非 AlphaLab 已經替你的環境跑出的結果。
先說結論：批准模式也是網路權限
一句話記住：有效出站權限＝目前已載入的規則＋誰有權批准下一條規則。沙盒預設拒絕，像大樓大門上鎖；自動批准則像把「新增訪客名單」交給一套審核機制。門鎖仍在，但名單可能在執行中改變。
截至 2026 年 9 月 30 日，NVIDIA OpenShell v0.1.2 的 Policy Advisor 文件說明：提案只新增網路規則；預設由人審核。改為 auto 後，風險檢查無發現且目的地無安全標記的提案會自動批准。官方也明說：對未綁定提供者憑證的新公開主機，這些檢查不把「新主機」本身列為風險。連系統從被擋連線產生的草案，也可能走同一條自動批准路徑。
OpenShell Auto-Approval 到底改了什麼？
OpenShell 的網路規則通常同時指定目的主機、連接埠、實際開連線的程式，以及可檢查的 HTTP 方法和路徑。網路規則可在沙盒執行中載入，所以一個「剛剛還被擋住」的請求，批准後重試可能變成允許。官方 Network Rules把程式與端點的配對方式列得很清楚。
你要分清三張收據：請求收據說明連線被允許或拒絕；批准收據說明規則由誰批准，以及 auto:true 是否出現；載入收據說明新規則是否真的成為有效政策。只看到 HTTP 錯誤碼，可能是服務端回覆、DNS 失敗或沙盒拒絕；只看到「批准」，也不能跳過有效政策和重試的核對。
準備區：先把測試範圍縮小
- 準備已可運作的 OpenShell CLI／gateway；依官方第一條網路政策教學建立沒有自動附加 provider 的沙盒：
openshell sandbox create --name approval-lab --no-auto-providers。沙盒名稱若已存在，換一個新的短名稱。 - 準備一個你控制的 HTTPS 測試站，能記錄收到的路徑、方法、查詢字串與標頭。本文稱它為
lab.example.test；這是佔位名稱，操作時必須換成你自己的可解析主機。只放CANARY-TEST-01這種假字串。 - 在宿主機先執行
openshell settings get approval-lab、openshell policy get approval-lab --base與openshell policy get approval-lab --full，保存輸出。--full會把 provider 帶入的有效規則算進來；後續每次變更都拿它比較。 - 用
openshell logs approval-lab --since 10m --source sandbox查政策事件。官方提醒：--level warn會藏掉部分政策事件，做驗收時不要加。若沙盒日誌缺少批准事件，再查提案歷史與 gateway 日誌，不要把「沒看到」當成「沒發生」。
若手邊沒有可觀察的自有收件端，先完成前三張本地收據，再把「對端實際收到」留空；這一格空白就代表外傳路徑尚未驗收。不要拿真實金鑰、客戶資料或同事帳號當 canary。
OpenShell Auto-Approval 四組驗收測例
① 陌生公開主機：人工與自動批准各跑一次
痛點：「預設拒絕」會不會在第一次碰到新網站後悄悄變成允許？先在宿主機把批准模式設為人工：openshell settings set approval-lab --key proposal_approval_mode --value manual。進入沙盒：openshell sandbox connect approval-lab，用 curl -i https://lab.example.test/ping 嘗試連線，再離開。回到宿主機查 openshell rule get approval-lab --status pending、openshell policy get approval-lab --full 與日誌：記下請求是否被擋、是否出現待審草案、有效政策是否仍不含該端點。
接著在另一個乾淨沙盒，或清除這次草案並恢復起始政策後，改設 openshell settings set approval-lab --key proposal_approval_mode --value auto，對另一個你控制的公開主機重跑。查 openshell rule get approval-lab --status approved、有效政策與日誌中的 CONFIG:APPROVED、CONFIG:LOADED。重試連線，最後核對測試站收件紀錄。若 gateway 有全域設定，官方文件說全域值優先；以 settings get 顯示的來源為準，不能只看你剛設定的沙盒值。
第三方 Sorami 原始測試資料記錄，在其 2026 年 9 月 29 日、OpenShell v0.1.2、單台 Apple Silicon microVM 設定下，新公開主機的自動批准相關測例為 12/12；私有位址與高風險連接埠則留待人工審核。這是那一組設定的觀察，不是所有部署的通過率，也不是繞過官方控制的證據。
② 唯讀規則：GET 可達，不等於假資料不能出去
痛點：把某個 API 設成唯讀，就能擋住外傳嗎？在獨立沙盒，以官方語法新增只許 curl 讀取自有測試站的規則：openshell policy update approval-lab --rule-name lab_readonly --binary /usr/bin/curl --add-endpoint lab.example.test:443:read-only:rest:enforce --wait。先用 openshell policy list approval-lab 和 --full 確認最新修訂版已載入。
在沙盒內對自有站送 GET /ping?note=CANARY-TEST-01，再送一個只含假字串的 POST /ping。預期的對照是：GET 可能被允許，而且查詢字串可能到達你的站；POST 應被 read-only 的方法規則拒絕。官方教學用同一種唯讀政策示範 GET／POST 差異。Sorami 在自己的 v0.1.2 測試裡，也觀察到 GET 查詢字串與標頭可攜帶假 canary；因此「禁止寫入方法」和「禁止任何資料外送」是不同驗收題。
③ 寫入規則：只開你真的要用的方法與路徑
痛點：任務需要上傳結果時，read-write 可能比需求寬。先記下允許的主機、執行檔、方法、路徑，再依官方政策管理範例，對同一規則加一條指定路徑的允許項：openshell policy update approval-lab --rule-name lab_readonly --binary /usr/bin/curl --add-allow 'lab.example.test:443:POST:/upload-test' --wait。這會把原本的唯讀預設展成等效明確規則，再加入指定 POST；操作前後都保存完整政策。
在沙盒對 /upload-test 發送假 canary 的 POST，再對 /other-path 發送同樣內容。到站的一筆與被政策擋下的一筆，連同方法、路徑和政策修訂號，才算驗收完成。若你改用 read-write、audit 或未指定執行檔，驗收範圍就不同，必須重畫權限表；官方 Network Rules解釋 audit 是記錄違規但不阻擋。
④ 撤銷與回滾：模式關掉，已批准規則還在嗎？
痛點：把批准模式設回 manual，是否就收回先前新增的網路規則？兩件事要分開做。先用 openshell settings set approval-lab --key proposal_approval_mode --value manual 阻止後續自動批准，再用 openshell policy get approval-lab --base、--full 和 openshell policy list approval-lab 找到已載入的規則與修訂號。依實際規則名稱執行 openshell policy update approval-lab --remove-rule <rule-name> --wait；若要回到較早的整份政策，依官方回滾步驟取出先前的 base 版本，再用 openshell policy set approval-lab --policy previous-base.yaml --wait 套成新修訂版。
最後重試同一筆假資料請求，確認沙盒拒絕，測試站也沒有新增收件紀錄。若規則來自 provider 或全域政策，單改沙盒 base 政策可能無法收回有效權限；回看 --full 與設定來源。關閉模式是防止下一次自動批准，撤銷規則才是處理已開的門。
上線前驗收表：每一列都要有證據
- 權限表：列出每個可達主機、port、程式路徑、HTTP 方法與路徑，以及規則來源（沙盒、provider、全域）。
- 批准表：記下
proposal_approval_mode的實際值與來源；每條草案的提出者、風險發現、批准者／auto:true、載入修訂號。 - 對照表：每個測例保存沙盒請求結果、OpenShell 政策日誌、有效政策，以及自有站實際收件紀錄。這四處若不一致，先查 DNS、執行檔路徑、全域設定與 provider 規則。
- 回滾表：先定義如何改回人工審核、刪除新增規則、重試阻擋請求。把已開連線與新連線分開觀察；官方說政策更新時會關閉舊規則下的連線，客戶端需重連。
一個常見誤判是把 CONFIG:APPROVED 當成「已完成外傳」；另一個是把 HTTP 403 當成「OpenShell 擋住」。看完整事件鏈，再看收件端。若你的沙盒日誌看不到批准事件，Sorami 的 microVM 測試曾在 gateway 日誌與規則歷史找到紀錄；請標成觀測缺口，補查該環境的控制面日誌。
常見問題：八個直接答案
Auto-Approval 開啟後，陌生公開主機一定會放行嗎？
不一定。提案還要通過官方風險檢查，且沒有目的地安全標記；你的全域設定、provider 與有效政策也會影響結果。驗收要看提案狀態、載入修訂版和實際重試。
關閉 Policy Advisor，還會出現草案嗎？
會。官方文件指出，OpenShell 仍會從被擋連線產生系統草案；自動批准模式也適用於這些草案。Advisor 開關控制的是 Agent 提交提案的介面，不是所有草案的生成。
唯讀規則等於不能外傳資料嗎？
不等於。GET 仍可帶查詢字串與標頭；若允許的目的地由對方接收，資料可能離開沙盒。用自有站的假 canary 驗證你允許的路徑。
為什麼要查 --full，不是只查 --base？
--full 顯示 provider 規則加入後的有效政策；它回答沙盒實際能連哪裡。--base 則適合當作你要編修的沙盒政策底稿。
把模式改回 manual，就完成撤銷了嗎？
尚未。那只改變後續提案的批准方式。再找出已載入的新規則、移除或回滾，並以同一假請求確認阻擋。
可以拿真實密鑰當 canary 嗎？
不要。只用可辨識但毫無價值的假字串，並讓測試站由你控制；這樣就算放行，也只留下可核對的測試證據。
為什麼我看見 curl 失敗，收件端也沒有紀錄？
先分辨是 DNS 沒解析、端點拒絕、工具路徑不符，還是 OpenShell 的 policy_denied。把客戶端錯誤、沙盒日誌、有效政策放在同一時間線。
什麼情況才適合開自動批准？
當你已接受「無憑證的新公開主機可能不經人工核准」這個邊界、能留存完整批准與收件證據，且有可執行的回滾程序時，才把它納入特定沙盒的權限設計。若任務只需固定 API，先維持人工審核並寫窄規則。
給新手的三個重點
- 看有效政策，也看誰能新增政策；
manual／auto是權限決策的一部分。 - 用你控制的假資料做「被擋、批准、載入、重試、收件」五段對照，別用單一錯誤碼猜結論。
- 回滾要同時處理批准模式與已載入規則，最後再用同一請求驗收。
下一步：先跑人工審核的第一張收據
從一個全新、沒有真實憑證的沙盒開始，記下 settings get、policy get --full 和陌生主機的第一次拒絕。等你能清楚說出「誰批准、哪一條規則載入、哪一筆假資料到站」，再決定是否把批准交給自動模式。想把這套驗收擴展到完整 Agent 工作流，也可以從 AlphaLab 課程繼續學。