AIREITER能夠修改檔案、安裝套件和呼叫 API 的 coding agent，不能只靠 system prompt 裡的一句警告來限制權限。NVIDIA OpenShell 把這些權限移到 agent 之外，交由政策控管的沙盒執行；但實際使用時，你仍得自行補上完整政策，並驗證整套部署是否真的符合預期。
先講結論：OpenShell 是 runtime 邊界，不是 agent framework
NVIDIA OpenShell 是一套開源的 autonomous agent runtime。它在 0.1.x 文件中提供 Gateway、每個沙盒各自的 Supervisor、由核心強制執行的檔案系統與程序控管、網路中介、憑證繫結，以及政策審查工具。根據 NVIDIA 2026 年 9 月 28 日發布的技術部落格（NVIDIA Technical Blog），OpenShell 的設計目標是包裝 Codex、Claude Code 等 agent，不必改寫它們。
真正需要分清楚的是「隔離」與「智慧」：OpenShell 可以擋下未獲授權的檔案寫入或網路請求，卻無法讓一套不完整的政策自動理解，哪些不同路徑最後可能導向同一個業務動作。我會把它用在受控的 coding 與 agent 基礎架構上進行試點，但不會把「有沙盒」直接當成 production agent 已經安全的證明。
OpenShell 實際控管的是哪些東西？
OpenShell 將整個 agent fleet 的管理工作與實際 workload 分開。Gateway 負責管理沙盒與政策，Supervisor 介入處理 workload 對外發出的請求，而 Sandbox 則在作業系統限制下執行 agent（NVIDIA Technical Blog）。
| 層級 | 保護對象 | 執行期間能否變更？ |
|---|---|---|
| 檔案系統 | 檔案與目錄 | 不能；必須重新建立沙盒 |
| 程序 | 權限與系統呼叫行為 | 不能；必須重新建立沙盒 |
| 網路 | 主機、連接埠、執行檔與特定 API 操作 | 可以 |
| Provider 憑證 | 在核准端點使用的密 secrets | 可以 |
OpenShell 在應用程式層以下執行政策控管，並把可重複使用的憑證放在 agent 之外，只在核准的請求中附加這些憑證（OpenShell README）。
「OpenShell 是一套安全、私有的 runtime，用來執行大規模 autonomous AI agents。」— NVIDIA OpenShell README（來源）
安全模型在邊界控管上最有力，真正的弱點則在政策設計
OpenShell 文件所描述的控管機制之所以實用，是因為它們在多個基礎架構邊界採取 fail-closed 設計。不過，這些機制不能取代你對 agent 可組合哪些動作的完整建模。
把檔案、程序與網路控管放在同一張運作藍圖裡
最新的安全性指南說明，OpenShell 使用 Landlock 控制檔案存取、透過 seccomp 與降低權限限制程序，並以搭配 OPA 政策評估的 CONNECT proxy 管理對外流量（OpenShell Security Best Practices）。未列出的檔案系統路徑無法存取；對外流量預設拒絕；網路規則也能把存取權限綁定到特定執行檔的身分。
網路規則不只看主機與連接埠。REST 政策可以檢查 method 和 path；GraphQL 政策可以檢查 operation 與 root field；WebSocket 政策則能檢查握手與訊息。取捨也很直接：規則放寬比較容易維持功能，規則收窄則比較容易進行防禦與審查。
檔案系統與程序限制會在沙盒啟動時固定下來。網路權限可以在沙盒執行期間更新，但一旦核准，就會成為該沙盒實例的一次持久政策修訂。換句話說，政策迭代很方便，但並不是所有控管都能隨時修改。
憑證是被中介管理，不代表會自動變得無害
憑證中介可以縮小暴露範圍，卻無法把權限過寬的端點變安全。唯讀 API 政策可以限制一組技術上具備寫入權限的憑證；但如果政策本身已經允許破壞性操作，它就無法替你補救。
安全性指南建議先以 audit 模式啟用 L7 規則，檢視實際請求後，再切換到 enforce。Audit 模式會記錄違規，但仍會轉送請求，因此它是探索與校準階段，不是 production block。
如何評估 OpenShell，避免把 demo 當成安全性結果
NVIDIA 的官方教學使用 curl 與未經驗證的 GitHub REST API，示範拒絕存取、唯讀規則和即時替換政策；它是一條學習路徑，不是獨立的 benchmark（NVIDIA Technical Blog）。
你可以先用這份教學回答三個部署問題：
- 你的 agent 能否在完全沒有網路存取權的情況下啟動，之後只取得真正需要的端點？
- 你能否在 API 政策中清楚區分讀取與寫入操作？
- 你的維運團隊能否在不授予 agent 自行核准請求權限的前提下，檢視拒絕事件與政策修訂？
真正進行試點時，還要加入對抗性案例：符號連結與路徑穿越嘗試、套件安裝、shell 子程序、替代執行檔、送往錯誤主機的憑證 placeholder，以及多個單獨看似允許、組合後卻可能越過業務邊界的動作。公開資料沒有提供延遲、啟動額外負擔或獨立逃逸率測量，因此請在自己的環境中收集這些數字，不要把產品的架構主張直接當成測試結果。
哪些因素可能讓 production 決策卡關？
做 production 決策時，至少要把三項限制放進考量：
- 成熟度與相容性。 Repository 列出 Linux、Apple Silicon macOS，以及透過實驗性 WSL 2 支援的 Windows；執行方式則包括 Docker、Podman 或主機虛擬化。Kubernetes 必須使用能夠強制執行
NetworkPolicy的 CNI；Kubernetes user namespaces 也需要較新的 kernel、Kubernetes 與 runtime 版本，而這種組合的 GPU 相容性尚未驗證（OpenShell README；Security Best Practices）。 - 政策組合。 真實使用者 @liyun0016 的測試指出，明確的 deny 測試都能通過，但編輯 repository、修改 CI，再觸發 CI，可能組合出一條未獲授權的 production 路徑（貼文）。OpenShell 會強制執行你寫下的規則，卻不會替你定義那些被遺漏的業務層規則。
- 證據品質。 NVIDIA 表示曾進行長時間的對抗性實驗，沒有發生受保護 repository 被寫入的情況；但引用的技術資料並未公開模型數量、基準線、誤報率或獨立重現結果。請把這視為 vendor evidence，而不是 certification。
「OpenShell 顯然很擅長強制執行你交給它的規則。但……真正的瓶頸似乎在 policy layer。」— @liyun0016（來源）
現在適合使用 NVIDIA OpenShell 的人？
| 情境 | 建議 |
|---|---|
| 擁有敏感檔案的本機 coding agent | 如果 Linux/macOS runtime 需求符合，且政策從嚴格限制開始，值得進行試點 |
| 擁有多個 workspace 的團隊 agent fleet | 當團隊需要隔離 workspace、共用政策審查與憑證中介時，適合使用 |
| 大量使用 GPU 的 Kubernetes 部署 | 請謹慎試點；user namespace 與 GPU 相容性需要另外驗證 |
| 擁有廣泛業務權限、無人值守的 production agent | 不要只依賴 OpenShell；還需要業務核准、動作層級控管、記錄與 rollback |
| 只需要簡單的 Python code sandbox | 請比較專門打造的 sandbox；OpenShell 可能比你的實際需求更偏向 control plane |
我的建議是進行有邊界的試點，而不是全面遷移：選定一個 agent、一個 workspace、一套 deny-by-default 網路政策，以及一小組可逆任務。接著量測被阻擋請求的雜訊、啟動時間、政策維護成本，以及多個獲准動作串在一起時，是否可能跨越業務邊界。
NVIDIA OpenShell FAQ
NVIDIA OpenShell 需要 NVIDIA GPU 嗎？
README 同時記載 CPU 與 GPU 執行路徑，並列出 Docker、Podman 及主機虛擬化。這套 runtime 並未被描述為必須使用 NVIDIA GPU，但你仍應驗證實際需要的 driver 與部署組合。
OpenShell 已經適合 production 使用嗎？
OpenShell 0.1.x 已有文件化的 release line，但官方資料沒有提供獨立安全性認證或廣泛的效能 benchmark。請把它當成需要放進自身威脅模型驗證的基礎架構，而不是任何情境都能保證 production 安全的方案。Repository 列出的授權為 Apache License 2.0；你仍需自行編列 compute、Gateway 維運、政策維護與安全性測試的成本（OpenShell README）。
總評：Pass。
OpenShell 能執行 Claude Code 或 Codex 嗎？
NVIDIA 的技術部落格將 Claude Code 與 Codex 列為相容 agent。這套 runtime 的定位是包裝現有的 agent workload，而不是要求你重新改寫 agent。
檔案系統規則可以在不重建沙盒的情況下變更嗎？
不能。安全性指南將檔案系統與程序控管列為靜態設定。網路政策與 provider 指派則可以在沙盒執行期間變更。
OpenShell 與 Docker 有什麼不同？
Docker 提供 containerization primitive；OpenShell 則增加一層以 agent 為核心的政策控管，涵蓋檔案系統、程序、網路、API 操作、憑證與政策審查。兩者也可以同時出現在同一套部署中。