這篇文章你會看到什麼

看完這篇，你大概會掌握下面幾件事：

• OpenShell 的整體架構，還有三層防禦是怎麼運作的
• 從安裝到啟動 sandbox 的基本流程
• 怎麼用宣告式 YAML policy 做存取控制
• Privacy Router 怎麼管理 LLM 推論流量
• OpenShell 怎麼跟 Cisco AI Defense 一起做企業級部署

前言

但問題也很現實啦：如果 agent 不小心做了不該做的事怎麼辦？

例如亂改檔、亂連外、誤用憑證，甚至被 prompt injection 帶偏，那其實風險不小。

所以在 GTC 2026 上，NVIDIA 就端出了一個很明確的答案：OpenShell。

OpenShell 是一套專門給自律 AI agent使用的開源安全 runtime。它的核心概念很清楚，就是透過三層防禦機制來限制 agent 的行為：

• Sandbox 隔離
• Policy Engine 政策引擎
• Privacy Router 隱私路由器

這三層一起工作，讓 agent 就算可以自主執行很多事情，也還是在可控、安全的範圍內。

而且它是 Apache 2.0 授權，重點是可以直接套在既有 agent framework 上，不需要改程式碼，這點真的很香。

適合誰看

這篇特別適合下面幾種人：

• 正在開發或維運 AI agent 的工程師
• 想補強 agent 安全機制的團隊
• 已經在工作上使用 Claude Code、Codex、OpenClaw 的開發者

TL;DR

先講重點版：

• OpenShell 是專門給 AI agent 用的開源安全 runtime，採 Apache 2.0 授權
• 它用 Sandbox、Policy Engine、Privacy Router 三層防禦來控管 agent
• 採用 deny-by-default 設計，保護 檔案系統、網路、程序、推論 四個面向
• 可以直接搭配 Claude Code / Codex / OpenClaw 使用，不用改 agent 程式
• 宣告式 YAML policy 支援網路與推論規則熱更新
• 很適合拿來做企業級 AI agent 安全落地

OpenShell 到底是什麼？

OpenShell 是 NVIDIA 在 GTC 2026 發表的一套AI agent 專用安全 runtime。

如果說同場發表的 NemoClaw 比較像是「開發與管理 agent 的平台」，那 OpenShell 比較像是「讓 agent 安全執行的底層環境」。

也就是說，NemoClaw 負責把 agent 做出來、部署好；

而 OpenShell 負責確保這個 agent 在執行時不會亂跑、亂碰、亂送資料。

這兩個其實不是競爭關係，反而很互補。

它想解決什麼問題？

根據 NVIDIA 的技術觀點，長時間運作的自律 agent 通常同時需要三件事：

• 安全性
• 能力
• 自主性

麻煩的地方是，傳統做法常常只能同時顧到其中兩項，很難三個一起拿到。

你如果讓 agent 很有能力又很自由，安全就容易出事； 你如果安全鎖太死，agent 又會變得不夠好用。

OpenShell 的關鍵做法叫做：

out-of-process policy enforcement（程序外政策強制執行）

白話一點講，就是：

安全控制不是寫在 agent 自己裡面，而是放在 agent 外面。

這樣的好處是，就算 agent 本身被攻擊、被操控、或行為失常，它也沒辦法直接繞過外部的安全限制。這個設計概念其實很重要，因為它把「能不能做某件事」的決定權，從 agent 手上拿回到 runtime 這邊。

OpenShell 的 4 大元件

OpenShell 主要由四個核心元件組成：

元件角色Gateway控制平面 API，負責 sandbox 的生命週期管理與認證邊界Sandbox隔離容器 runtime，根據 policy 套用對外流量路由Policy Engine對檔案系統、網路、程序、推論四大領域做存取控制Privacy Router控制 LLM 推論請求，把敏感資料導向本地模型，其餘導向雲端模型

技術上比較有趣的是：

這整套元件其實是以 K3s Kubernetes 叢集形式，跑在單一 Docker container 裡。

也就是說，你不用額外先裝一整套 Kubernetes，就能把 OpenShell 跑起來，對很多開發者來說會省事很多。

deny-by-default：預設全不給，真的比較安全

OpenShell 的安全哲學很明確，就是 deny-by-default。

也就是說，預設情況下，agent 不會自動拿到一堆存取能力；

你要什麼權限，就要明確寫在 policy 裡授權。

這種設計比起「先全部開放、再慢慢補封鎖」來說，通常安全很多，也更適合拿來跑會自主行動的 agent。

四個防禦領域

OpenShell 的 Policy Engine 會在下面四個面向上做控制。

1. 檔案系統控制

它可以阻止 agent 對未授權路徑進行讀寫。

而且這類 filesystem policy 會在 sandbox 建立時就鎖定，執行中不能改。

這很合理，因為檔案權限如果能在執行中被隨便修改，風險就會很大。

2. 網路控制

OpenShell 也會攔截未經授權的外部連線。

所有 outbound 連線都會先經過 Policy Engine，再做下面三種判定：

• Allow：目標位址與發起程式符合 policy，就放行
• Route：如果是推論請求，會先移除呼叫端原始憑證，再注入後端受控憑證，轉送到指定模型服務
• Deny：如果不符合 policy，就直接擋下來，並且留下記錄

這邊很棒的一點是：網路 policy 支援熱更新。

也就是說，你不用重啟 sandbox，就能調整可連線目標或路由規則，對營運很方便。

3. 程序控制

程序控制主要是在防止：

• 權限提升
• 危險 system call
• 不該被啟動的程序行為

這一類 policy 跟檔案系統一樣，也是在 sandbox 建立時就鎖住。

4. 推論控制

OpenShell 不只是管 OS 層面的事，它連 模型 API 呼叫都能管。

這層控制會把 agent 的推論請求導向受控後端，而不是讓 agent 自己隨便決定往哪裡送。

而且 inference policy 也支援熱更新，所以你可以在系統運作中切換模型、修改限制、變更推論路由。

四大防禦領域整理

領域保護內容套用時機檔案系統防止讀寫未授權路徑建立時鎖定網路阻擋未授權外部連線可熱更新程序阻止權限提升與危險 syscall建立時鎖定推論控管模型 API 呼叫可熱更新

這個切法其實蠻聰明的。

因為檔案系統跟程序屬於比較底層、比較不能亂動的安全邊界，所以在建立時就鎖死； 網路跟推論則比較需要隨營運狀況調整，所以支援動態更新。

安裝與基本設定

前置條件

要跑 OpenShell，基本上需要：

• 已經啟動的 Docker Desktop 或 Docker daemon
• 如果要用 GPU：
• • NVIDIA driver
  • NVIDIA Container Toolkit

安裝方式

OpenShell 支援兩種常見安裝方式。

直接用安裝腳本：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

透過 PyPI 安裝（需要 uv）：

uv tool install -U openshell

建立並啟動 Sandbox

OpenShell 很強的一點是，你可以直接用一條指令把 agent 丟進 sandbox 裡跑。

# 在 sandbox 中啟動 Claude Codeopenshell sandbox create -- claude# 在 sandbox 中啟動 Codexopenshell sandbox create -- codex# 使用 OpenClaw 社群映像openshell sandbox create --from openclaw# 建立支援 GPU 的 sandboxopenshell sandbox create --gpu --from gpu-enabled-sandbox -- claude

Sandbox 預設內建工具

OpenShell 預設提供一些實用工具，方便你直接在裡面工作：

• Python 3.13
• Node 22
• git、gh
• vim、nano
• 常見網路工具：
• • ping
  • dig
  • nslookup
  • nc
  • traceroute
  • netstat

這代表它不只是安全殼層而已，也是一個可以直接拿來跑 agent workflow 的工作環境。

常用管理指令

# 查看 sandbox 清單openshell sandbox list# SSH 連進 sandboxopenshell sandbox connect my-sandbox# 即時看 logsopenshell logs my-sandbox --tail# 開啟 dashboard UIopenshell term

Policy 設定：OpenShell 的核心靈魂

OpenShell 最核心的東西之一，就是它的宣告式 YAML policy。

因為系統是 deny-by-default，所以預設只會開放最基本、最小限度的 outbound 存取。

你想讓 agent 做什麼，就必須在 policy 檔裡明確寫出來。

這種方式的好處是：

• 權限範圍清楚
• 易於審查
• 比較適合團隊協作與企業治理

套用 Policy

# 套用 policyopenshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait# 取得目前 policyopenshell policy get demo

Policy 的兩種類型

OpenShell 的 policy 分成兩大塊：

• 靜態區段（filesystem、process）
• • sandbox 建立時鎖定
  • 執行中不可更改
• 動態區段（network、inference）
• • 執行期間可熱更新
  • 不需要重啟 sandbox

這樣的設計真的很實際。

底層安全邊界先在啟動時固定住； 需要因應營運調整的部分，再交給動態政策處理。

憑證怎麼管？

OpenShell 會把認證資料整理成 Provider，也就是「具名憑證組合」。

這些 Provider 會在 sandbox 建立時，以環境變數方式注入。

例如：

Agent環境變數Claude CodeANTHROPIC_API_KEYCodexOPENAI_API_KEYOpenCodeOPENAI_API_KEY 或 OPENROUTER_API_KEY

比較值得注意的是：

這些憑證不會被寫進 sandbox 的檔案系統，而是只透過環境變數提供。

這樣做是為了降低 prompt injection 導致憑證外洩的風險。

也就是說，就算 agent 嘗試把某些秘密寫到檔案、或讓惡意工具去掃檔案內容，也比較不容易直接把金鑰撈出來。

Privacy Router：推論也要分流

OpenShell 的 Privacy Router 專門負責管理 LLM 推論請求。

它的概念很像這樣：

• 含有敏感內容、機密上下文的請求
  → 送到本地開源模型處理
• 一般性的請求
  → 才送去雲端 frontier model，例如 Claude、GPT

也就是說，模型路由的決策權不在 agent 手上，而是在組織 policy 手上。

這一點對企業特別重要，因為它把成本、合規、隱私考量都拉回到治理層來管理。

範例指令：

# 設定推論 provider 與模型openshell inference set --provider local --model llama-3.3

企業整合：Cisco AI Defense

NVIDIA 也在推 OpenShell 與多家資安廠商整合，像是 Cisco、CrowdStrike、Google、Microsoft Security、TrendAI 等。

其中比較受矚目的，是跟 Cisco AI Defense 的結合。

這個組合可以看成是一個雙層安全模型：

層級負責者角色基礎設施限制OpenShellSandbox 隔離、deny-by-default、網路 policy、隱私路由行為驗證Cisco AI Defense供應鏈風險管理、MCP 工具呼叫檢查、審計追蹤

Cisco 的說法很直白，也很好懂：

• OpenShell 負責限制 agent「能做什麼」
• Cisco AI Defense 負責驗證 agent「實際做了什麼」

這樣的分工其實很合理。

OpenShell 是預防型控制；Cisco AI Defense 比較像監督與驗證層。

具體整合能力

這類整合可以帶來幾個很實際的功能：

• 供應鏈驗證
  工具、MCP server、skills 在使用前先掃描
• MCP 呼叫檢查
  即時偵測惡意 payload 或 prompt injection
• 審計追蹤
  完整記錄推論步驟、工具呼叫與決策過程

對企業來說，這很重要，因為 AI agent 一旦要進正式環境，大家不只會問「它能不能做」，還會問「出了事怎麼追」。

支援哪些 Agent？生態系有多大？

OpenShell 目前主打可以在不改程式碼的前提下支援下面這些 agent：

• Anthropic Claude Code
• OpenAI Codex
• OpenClaw
• 其他相容的 coding agents

另外，NVIDIA Agent Toolkit 生態系也已經有不少夥伴加入，包含：

• Adobe
• Atlassian
• Amdocs
• Box
• Cadence
• Cisco
• Cohesity
• CrowdStrike
• Dassault Systèmes
• IQVIA
• Red Hat
• SAP
• Salesforce
• Siemens
• ServiceNow
• Synopsys
  等等超過 16 家公司。

這意味著 OpenShell 並不是只做給 demo 用的，而是明顯朝企業落地方向在走。

可以部署在哪裡？

OpenShell 的部署範圍很廣，從個人開發者到企業都能用：

• NVIDIA DGX Spark / DGX Station
• 搭載 NVIDIA RTX 的 PC
• On-premises 基礎設施
• 雲端環境

所以不管你是自己在本機測 agent，還是要在企業內網或雲端正式部署，理論上都找得到適合的落點。

OpenShell 和 NemoClaw 差在哪？

這兩個都在 GTC 2026 很受關注，但定位不同。

NemoClaw

比較像是 agent 開發平台，負責：

• 建構 agent
• 部署 agent
• 管理 agent

OpenShell

比較像是 agent 執行環境的安全 runtime，負責：

• 提供 sandbox
• 強制執行 policy
• 控管推論與外部連線
• 保護執行期安全

所以比較合理的理解方式是：

你可以用 NemoClaw 把 agent 建好，再用 OpenShell 把它安全地跑起來。

這兩者是互補，不是互斥。

總結

整體來看，OpenShell 是一個非常明確、很有現實感的 AI agent 安全方案。

它的重點可以整理成幾句話：

• OpenShell 是專門給 AI agent 用的開源安全 runtime
• 它透過 Sandbox、Policy Engine、Privacy Router 三層防禦來控制 agent 行為
• 採 deny-by-default 設計，覆蓋檔案系統、網路、程序、推論四大面向
• 支援 Claude Code / Codex / OpenClaw 等主要 agent，而且不需要修改 agent 程式
• 宣告式 YAML policy 讓網路與推論規則可熱更新
• 搭配 Cisco AI Defense 後，可以進一步做到企業級審計、檢查與驗證
• 採 Apache 2.0 授權，適合開發者與企業評估導入

老實說，隨著 AI agent 越來越能自己做事，runtime 層級的安全控制只會越來越重要。

以前我們比較常在意 model 能不能用、agent 聰不聰明；但接下來，大家一定會越來越在意：它到底能做哪些事、不能做哪些事、出事了能不能追。

如果你的團隊已經在考慮導入自律 agent，OpenShell 這種做法真的很值得早一點研究看看。