每日突破性工具推薦｜NVIDIA OpenShell

NVIDIA OpenShell：把 AI Agent 的安全邊界移出模型本身

NVIDIA OpenShell 是一套面向自主式 AI Agent 的開源安全 Runtime。它不是另一個 Agent orchestration framework，而是位於 Agent 與作業系統、網路、憑證、模型端點之間的執行層：讓 Agent 可以讀寫檔案、執行工具、呼叫 API 與使用憑證，同時避免把整台主機或完整網路權限直接交給模型。

OpenShell 在 2026 年 9 月 28 日隨 NVIDIA Open Agent Safety Platform 正式擴大發布；目前 0.1.x 已建立穩定版發布節奏與 API 變更政策。這次值得推薦的原因，是它把 Agent Security 從「Prompt、模型對齊與應用程式內檢查」推進到「模型無法自行繞過的 Runtime Enforcement」。

工具定位與適用情境

OpenShell 適合需要讓 Agent 真正執行動作的系統，例如：

• Coding Agent 執行 shell、安裝套件與修改 repository
• 長時間運作的 autonomous agent
• 需要存取內部 API、資料庫或 SaaS 的企業 Agent
• 需要使用 API key、OAuth token 或模型憑證的 Agent
• 多 Agent fleet 的集中式治理
• 私有雲、地端、Hybrid、Edge 或 air-gapped AI 環境
• 希望在 Kubernetes 上執行 Agent，但需要比 Pod 更細緻權限模型的團隊

它支援 Claude Code、Codex、GitHub Copilot CLI、Hermes、LangChain Deep Agents、OpenClaw、OpenCode 等 Agent，也能承載自訂 Agent。

突破性重點：安全機制不再依賴 Agent 配合

傳統 Agent Security 常把限制放在 system prompt、tool wrapper 或 Agent harness：

Model
  ↓
Agent Harness
  ↓
Tool Permission Check
  ↓
Operating System / Network

問題是 Agent 產生的程式碼、child process、第三方工具或遭 prompt injection 後的行為，可能跨過應用程式層原本預期的控制。

OpenShell 改成：

Model / Agent Harness
        ↓
   Agent Sandbox
        ↓
Kernel Enforcement
        ↓
    Supervisor
        ↓
Policy-controlled Network / Files / Credentials / Inference

政策執行位於 Agent process 外部，因此模型輸出本身不能要求 Runtime「忽略前面的安全規則」。

這是 OpenShell 最重要的架構轉變：限制 Agent 的環境，而不是要求 Agent 自己遵守限制。

核心架構與運作方式

1. Agent Sandbox

每個 Agent 都在獨立 Sandbox 執行。

OpenShell 透過 Kernel-level controls 限制：

• 可讀寫的檔案
• 可使用的 system call
• 可連線的網路目的地
• Agent process 與 child process 的行為

Sandbox 預設沒有直接網路存取，對外連線必須經過受控路徑。

2. Supervisor

Supervisor 位於 Agent workload 外部，負責攔截並判斷 outbound request 是否符合政策。

因此即使 Agent：

• 產生新的程式碼
• 啟動 child process
• 安裝新的 package
• 被 prompt injection
• 嘗試直接連線未知 endpoint

仍必須經過相同的 Runtime Policy。

3. Policy Prover

OpenShell 不只執行 policy，也在 policy 被修改之前分析「這次變更實際新增了哪些權限」。

Policy Prover 使用 formal verification 檢查新的 policy 是否超出既有 access boundary，例如：

• 新增了原本不能連線的 host
• 允許 credentials 被送往新的 endpoint
• 開放新的 API method
• 擴張 Agent 原有權限範圍

高風險變更可以因此停下等待人工審核，而不是讓 Agent 自己擴權後立即執行。

4. Credential Brokering

Agent 不需要直接取得真正的 credential。

OpenShell 可以在 request 確認要送往核准 endpoint 後，再由 Runtime 注入 credential。

這降低了 Agent 把 token：

• 印到 log
• 寫進檔案
• 傳往其他 domain
• 交給惡意工具

的風險。

5. Policy-aware Inference Routing

模型呼叫同樣可以被納入治理。

OpenShell 的 inference router 可以限制哪些 request 可以送到哪些模型 endpoint，讓敏感資料不必因為 Agent 自己選擇模型而離開允許的環境。

6. Gateway

Gateway 是集中式 control plane，負責管理 sandbox、policy、inference routing 與執行狀態。

OpenShell 可部署在：

• Docker
• Podman
• Kubernetes
• VM isolation
• 本機開發環境

Kubernetes 環境則提供 Helm deployment。

與 Docker / Kubernetes 的差異

Docker 與 Kubernetes 解決的是：

這個 workload 要在哪裡執行？

OpenShell 更關心：

這個 Agent 在執行期間究竟允許做什麼？

Docker / Kubernetes 本身仍然可以作為 OpenShell 的底層 Runtime，但 OpenShell 額外提供：

• Agent-specific sandbox supervision
• Policy-enforced egress
• Credential handling
• Inference routing
• Policy verification
• Gateway coordination
• Agent activity logs

因此它不是 Kubernetes 的替代品，而是建立在既有 Runtime substrate 上的 Agent-specific control layer。

與一般 Agent Sandbox 的差異

一般 Sandbox 通常著重「隔離」。

OpenShell 則把隔離進一步延伸成「可治理的能力授權」。

例如 Agent 可以被允許：

讀取 repository
✓

修改 src/
✓

讀取 ~/.ssh
✗

連線 api.github.com
✓

連線任意網域
✗

使用 GitHub credential 呼叫指定 endpoint
✓

取得 GitHub credential 明文
✗

這種 Capability-oriented model 更符合 autonomous agent 的實際風險模型。

與 NVIDIA Sentry 的關係

OpenShell 是軟體 Runtime Boundary。

NVIDIA Open Agent Safety Platform 進一步加入 Sentry，讓 BlueField-4 DPU 在 Host 之外持續監控 Agent 行為。

整體概念變成：

Agent
  ↓
OpenShell
  ↓
OS / CPU
  ↓
Sentry / BlueField-4
  ↓
Network / Model / Infrastructure

即使 Host 本身受到影響，獨立的 out-of-band security domain 仍可監控與執行政策。

不過 Sentry 與 BlueField 並不是使用 OpenShell 的必要條件；OpenShell 本身是開源軟體，也設計成可擴展至 NVIDIA 以外的 compute platform。

主要優勢

Default-deny

OpenShell 的基本安全模型不是「先全部允許再封鎖危險行為」，而是沒有明確授權就拒絕。

Enforcement 與模型推理分離

安全政策不需要依賴 LLM 是否理解、記住或願意遵守規則。

Model / Harness Agnostic

不用因為 Claude、Codex、自架模型或 Agent framework 不同，就重新設計整套 Runtime Security。

Credential 不必暴露給 Agent

Runtime 可以在核准 request 離開 sandbox 時才注入真正 credential。

Formal Policy Verification

在權限變更真正生效前分析新增能力，比單純 YAML policy validation 更進一步。

Deployment 彈性

Local、on-prem、cloud、hybrid、air-gapped 與 Kubernetes 都是目標環境。

開源

OpenShell 採 Apache License 2.0，可自行檢查、修改與部署安全 Runtime。

相較同類型方案的優點

相較只靠 Prompt / Tool Permission 的 Agent framework，OpenShell 的 enforcement 位於 Agent process 外，因此更難被 prompt injection 或 generated code 繞過。

相較純 Container Sandbox，它增加了 Agent-specific 的 Network Policy、Credential Brokering、Inference Routing 與 Policy Verification。

相較完全綁定特定 SaaS 的 Agent Sandbox，OpenShell 可以自架，也不限定模型與 Agent harness。

相較只做 application-layer policy engine 的方案，它能把 enforcement 延伸至 kernel、network 與 process boundary。

缺點與限制

架構複雜度提高

導入 OpenShell 代表系統多出 Gateway、Supervisor、Sandbox Policy 與 Runtime 管理層。對簡單聊天機器人可能完全沒有必要。

Policy 需要設計

Default-deny 很安全，但也意味著團隊必須理解 Agent 真正需要哪些檔案、網路與 API 能力。

Policy 過緊會阻礙 Agent，過寬則失去安全價值。

新生態仍在快速變動

0.1.x 才剛建立 stable cadence。雖然官方已開始進行 conformance、upgrade、breaking API 與 security testing，但仍遠比 Docker、Kubernetes 等基礎設施年輕。

完整 Hardware Enforcement 依賴 NVIDIA Infrastructure

OpenShell 本身可以跨硬體使用，但 Open Agent Safety Platform 最完整的 Sentry / in-silicon enforcement 路徑仍與 BlueField-4、DOCA 等 NVIDIA 基礎設施緊密相關。

無法消除所有 Agent 風險

Runtime Policy 能限制 Agent「能做什麼」，但不能保證 Agent「做的是正確事情」。

Business logic error、合法權限內的錯誤操作、資料品質與模型判斷錯誤仍需要應用層防護。

適合的使用者與專案

特別適合：

• 正在部署 Coding Agent 的團隊
• Agent Platform / AI Infrastructure 團隊
• 需要自主 Agent 存取企業內部資源的系統
• Multi-agent SaaS
• Security-sensitive AI workload
• 自架 Agent
• Kubernetes Agent Fleet
• 長時間背景 Agent
• Agent 需要真正 shell / filesystem / network 權限的產品

不適合的使用者與專案

不太適合：

• 純聊天、完全沒有 Tool Calling 的 LLM App
• Agent 只能呼叫少數無副作用 API 的簡單系統
• 沒有能力維護 Runtime / Policy Infrastructure 的小型專案
• 希望零設定、完全託管 Sandbox 的團隊
• 不需要 autonomous execution 的一般 Web Application

簡短結論

OpenShell 的突破點不是又提供一種 Sandbox，而是把 Agent Security 重新定義成 Runtime Infrastructure 問題。

當 Agent 開始能執行 shell、寫程式、安裝 package、使用 credential、呼叫內部 API，單靠 Prompt 或 Tool Wrapper 已經不足以形成可信任的安全邊界。

OpenShell 提出的答案是：

不要求 Agent 永遠做對，而是建立一個即使 Agent 做錯，也無法越過的執行邊界。

如果 autonomous agent 持續從「聊天功能」演變成真正可以操作企業基礎設施的軟體執行者，這類 Agent-native Runtime Security 很可能會成為下一層必要的基礎設施。