症狀：Agent 會呼叫工具、碰觸檔案或連向外部服務，單靠提示詞不能阻止越權操作。
最快解法：用 NVIDIA OpenShell 把檔案、網路與憑據存取納入可檢查的政策，再按實際 Agent 執行路徑逐項驗收；只有確認政策覆蓋所有工具後，才考慮上線。
正在評估 NVIDIA OpenShell 是否適合現有 Agent 專案的工程師與平台工程師，可依本文判斷部署前提及安全邊界。
若你只想替提示詞加上「不要讀取機密」等指令，這篇會說明為何那不是執行隔離。
最後更新於 2026 年 9 月 30 日；部署與架構資訊核對自 NVIDIA OpenShell 官方架構文件、Quickstart及各項政策文件。官方文件或支援矩陣更新時，請在實際採用前重新確認。
提示詞與執行政策的差異
提示詞是給模型的行為指令，不等於作業系統、檔案系統或網路層強制執行的存取控制。Agent 一旦透過工具執行程式碼或發出請求，真正要管理的是工具背後能接觸的資源，而不是模型是否記得某項規則。
常見風險至少有幾類：Agent 讀到工作目錄以外的設定檔；工具透過網路把資料送往未核准的目的地；執行環境可讀取不該交給模型的憑據；而測試失敗或程序異常退出後，操作者沒有足夠紀錄判斷政策是否生效。這些問題不會因為提示詞寫得更嚴格就自然消失。
NVIDIA OpenShell 是一般容器嗎？
它的用途是為 Agent 的執行設定受政策約束的邊界；容器則是更廣泛的作業系統隔離與封裝方式。兩者不能只看名稱便視為同一層防護，也不代表採用 OpenShell 就不必檢查主機權限、容器設定或應用程式本身。應根據官方架構文件確認實際部署路徑，再測試政策是否覆蓋 Agent 使用的工具。
| 選項 | 能處理的問題 | 你仍須自行確認 |
|---|---|---|
| 只靠提示詞 | 提醒模型遵守操作規範 | 不構成作業系統層的強制存取限制 |
| 一般容器 | 封裝執行環境並提供隔離設定 | 掛載目錄、網路及執行權限是否過寬 |
| OpenShell 政策化執行 | 依政策管理 Agent 的資源存取 | 實際工具路徑、有效政策與例外是否都納入驗收 |
NVIDIA 架構文件列出 CLI、Gateway 與 Supervisor 等元件；這些角色與執行路徑應以官方架構說明核對。這是可查證的部署事實，不是隔離效果的保證：政策是否有用，仍取決於它是否涵蓋你的 Agent 與工具。
NVIDIA OpenShell 部署前的環境檢查
部署前要準備哪些執行條件？
先確認支援的作業系統、計算驅動與所需元件，再確認 Agent 執行時如何啟動、會呼叫哪些工具，以及部署環境能否連線到必要服務。不同環境的支援組合可能不同，請依官方支援矩陣逐項核對，不要把某一台主機能運作，推論成團隊所有環境都相容。
著手部署前，先整理這些資料：
- 主機與驅動：記錄目前作業系統、計算驅動及安裝方式，與官方支援矩陣逐項比對。
- Agent 執行時：列出 Agent 的啟動方式、外掛、工具程序與子程序。只檢查主程式，容易漏掉實際執行檔案或網路操作的工具。
- 網路連線：標出模型服務、套件來源、內部 API 等必要目的地，並區分正常工作流與可選服務。
- 檔案範圍：記下工作目錄、輸入輸出位置，以及絕不可讀寫的憑據與系統路徑。
- 稽核方式：確認如何取得 OpenShell 相關記錄；依官方日誌文件了解可檢視的紀錄，再決定由誰負責複核。
Quickstart 適合用來對照官方部署流程與當前指令，但不要直接把範例設定複製到正式環境。先在隔離的測試環境依照官方 Quickstart完成啟動，再把實際採用的版本、執行時和政策設定記錄下來。若支援條件不符或依賴服務無法連線，先解決前提問題，不要以放寬權限換取「成功啟動」。
檔案與網路權限的收斂方法
OpenShell 如何限制 Agent 的檔案存取？
從任務必需的目錄開始授權，並明確列出禁止讀取或修改的路徑。政策語法與作用範圍請依官方政策概覽核對；不要自行猜測預設值，也不要假定未列出的路徑必然受到保護。
先測試正常任務能否讀取指定輸入、寫入指定輸出；再用負向測試要求 Agent 或工具讀取受限檔案、覆寫禁止位置。檢查結果時，同時看操作是否遭拒，以及記錄能否顯示相關政策決策。若只確認「任務跑完了」，卻沒有測試拒絕路徑，無法證明權限收斂有效。
網路規則應如何驗證？
先列出允許連線的網域與用途，再查閱官方網路規則說明，確認政策可表達的授權範圍。不要把「網路功能已設定」誤認為所有出站請求都會被預設封鎖或放行；實際行為須以目前版本的政策文件及測試結果為準。
測試時分別執行已授權目的地和未授權目的地的請求，記錄結果；若規則涉及請求方法或路徑，也要用不同請求確認允許條件是否符合預期。若 Agent 透過代理、外掛或子程序連線，這些路徑也須納入測試，否則驗收範圍可能只覆蓋表面上的主程式。
注意：將政策設得過寬，可能讓測試看似順利，卻失去隔離意義。遇到拒絕時，先確認該操作是否真為任務必需，再以最小範圍修訂，而不是一次開放整個目錄或任意出站連線。
憑據會不會被 Agent 直接看見？
不能只因為憑據由某個元件管理，就假設模型或工具程序接觸不到它。你需要查清楚憑據如何注入、何時可用、哪些程序能讀取，以及記錄是否會暴露機密內容。Provider Profiles 的設定與用途可參照官方文件；實際可見範圍仍要配合你採用的 Agent 與執行流程驗證。
優先使用符合架構的憑據管理方式，避免把長期密鑰寫進提示詞、原始碼或 Agent 可讀取的工作檔。測試時可以檢查程序環境、工具輸出與可取得的記錄，但不可把真實密鑰當作測試資料。若無法確認某個工具是否能取得憑據，先把它排除在正式工作流之外，直到完成明確驗證。
從測試結果判斷能否上線
怎樣確認 Agent 沙箱政策確實生效？
不要只用成功案例驗收。用受控測試同時確認正常任務能完成，且未授權操作會被拒絕，並保留可供複核的紀錄。以下步驟可逐項執行：
- 固定測試範圍：寫下 Agent、工具、工作目錄、允許網域及預期憑據來源；避免測試途中更換條件。
- 驗證正常操作：執行代表性任務，確認必要檔案和服務仍可使用。
- 測試檔案越權：嘗試讀取一個受限路徑，再嘗試修改一個禁止寫入的位置；確認兩者結果符合政策。
- 測試網路越權：分別測試未授權目的地，以及不符合預期方法或路徑的請求；比對實際結果與規則。
- 測試異常退出：讓測試程序以受控方式中斷，檢查是否能辨識原因、保留所需紀錄，並安全地重新執行。
- 複核與留檔：保存政策版本、測試條件、通過或失敗結果及例外核准人；政策變更後重新驗收受影響的項目。
OpenShell 的日誌可協助你追查執行狀況，但記錄本身不能取代測試。正式上線前，還要用接近真實業務的工具組合、資料流和網路依賴驗證；上線後也要在政策變更時重新檢查。若使用的工具不在測試範圍內，或出站路徑不明，這不是「已通過」，而是尚未完成驗收。
部署決策條件與取捨
依以下條件選擇，不要只因專案名稱含有「沙箱」就直接導入：
- 若你能列出 Agent 的檔案、網路與憑據需求，且可用受控測試驗證允許和拒絕的結果，則進入 OpenShell 試點，再根據真實工作流確認政策覆蓋範圍。
- 若執行環境符合官方支援條件，但工具使用方式或出站路徑尚不清楚，則先盤點工具與連線，再部署測試；不要先在正式主機上放寬權限。
- 若目前不能確認哪些程序取得憑據，或無法取得足以複核的執行記錄，則暫緩交付敏感任務，先補齊憑據邊界與稽核流程。
- 若你的主要需求是封裝一般應用、而非管理 Agent 的工具存取，則先比較既有容器與平台的權限能力；只有在政策化執行能解決明確缺口時，再增加 OpenShell 這層。
優點是可以把 Agent 的資源存取轉為可檢查的政策問題，讓驗收聚焦在具體允許和拒絕結果。限制則包括部署相容性需要對照支援矩陣、政策必須配合工具實際路徑維護，以及日誌複核與業務測試仍需投入人力。它不是絕對安全保證，也不會替你自動找出所有未盤點的外掛、代理連線或憑據洩漏方式。
如果你目前依賴共用伺服器直接跑 Agent，常見代價是權限邊界難以說清、政策變更容易漏測、憑據暴露面不易盤點；改用 OpenShell 也不能省略運行環境相容性與持續驗收。若你只是需要短期測試相容的 Agent 工作流，Kvmzen 雲端 Mac 可作為另一種遠端測試環境選項；但它不是 NVIDIA OpenShell 的替代品，也不應被假定為正式部署平台。你可以先比較 Kvmzen 雲端 Mac 租用方案與Mac 租用價格資訊，再依執行時、網路需求及是否需要 NVIDIA 支援環境決定：需要 OpenShell 特定能力時，以符合支援條件的部署環境完成驗收；只做短期相容性開發或測試時，再考慮租用遠端 Mac。