AI

OpenShell：NVIDIA 開源 AI Agent 安全執行環境，Agent 永遠拿不到真正的金鑰

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

這個月我們介紹了二十多個 Agent 工具，幾乎每一篇的「風險」章節都在重複同一件事：Agent 能讀你的檔案、能執行指令、能拿著你的 API 金鑰對外連線——一旦被 prompt injection 或自己判斷錯誤，後果就落在你身上。OpenShell（NVIDIA/OpenShell）想從執行環境這一層解決這個問題，它的定位是「自主 AI Agent 的安全、隱私執行環境」。專案目前約 20.1k stars，在 10 月 25、26 日的 AI 開源趨勢報告中，被多份報告列為「Agent 安全與沙盒化」的代表專案。

1. 專案背景與定位

OpenShell 由 NVIDIA 開源，Apache-2.0 授權，主要以 Rust 開發，並提供 Python、TypeScript、Go、Rust 四種 SDK。它不是 Agent，而是 Agent 跑在裡面的環境：Agent 照樣可以讀檔、安裝套件、呼叫 API、使用憑證，但 OpenShell 會限制它能碰到哪些資料、哪些秘密、哪些網路位置。

目前版本為 0.1.x，支援 Linux 與 Apple Silicon 的 macOS；Windows 則透過 WSL 2（實驗性）或 Microsoft MXC。官方強調自己是「agent-first」打造的專案，連安裝 Skill（npx skills add NVIDIA/OpenShell）都是為了讓 Coding Agent 學會操作 OpenShell CLI、撰寫政策與除錯。

2. 技術架構與核心設計

  • 沙盒隔離：每個 Agent 跑在獨立的沙盒中，由核心層控制它能存取哪些檔案、能呼叫哪些系統呼叫。
  • 網路政策：每一個對外連線在離開沙盒前都要通過政策檢查。
  • 憑證永不外露：Agent 看不到真正的憑證。OpenShell 只在請求要送往核准的端點時才把憑證注入——即使 Agent 被誘導把「它手上的金鑰」寄出去，也沒有真的金鑰可以洩漏。這個機制同樣適用於模型推論的 API 金鑰。
  • 政策變更的形式化驗證：當政策變更引入新的風險（例如對新主機開放憑證、允許新的 API 方法），系統會透過形式化驗證標記出來，等待人工審核後才生效。政策分為檔案系統、網路、程序三類，並有 advisor 與 prover 協助檢查。
  • 三層元件：Gateway（控制平面）、Supervisor 與 Sandbox。
  • 彈性的沙盒：可設定映像檔、runtime、GPU 與生命週期；支援 middleware、interceptor 與 compute driver 擴充。
  • 部署選項：本機 Docker、Podman 或主機虛擬化；也能用 Helm 部署到 Kubernetes（需要能執行 NetworkPolicy 的 CNI）。
  • 快速開始：執行安裝腳本後，openshell sandbox create --name demo 就能建立沙盒；官方範例是在沙盒中用 OpenCode 搭配 OpenRouter 的免費模型。

3. 社群熱度與生態採用

約 20.1k stars、2.0k forks、1,870 commits，有 384 個 issue 與 204 個 PR，社群相當活躍。趨勢報告也點出一個現象：Rust 正悄悄成為 Agent 基礎設施的主要語言，OpenShell 就是代表之一。由 NVIDIA 這樣的大廠維護，也讓它比個人專案更容易進入企業的評估名單。

4. 局限性與潛在風險

  • 仍是早期版本：0.1.x 版本，API 與政策格式可能變動；README 沒有明確標示 alpha 或 beta 狀態。
  • 沙盒不等於萬無一失：任何隔離機制都可能有漏洞，OpenShell 降低的是風險的「面積」，不是把風險歸零；對外部輸入的 prompt injection 仍要有其他防線。
  • 政策寫得好才有用：如果政策開得太寬（例如允許所有對外連線），沙盒的保護就大打折扣。政策設計需要對 Agent 的工作內容有清楚的理解。
  • 核准的端點仍可被濫用：憑證只注入到核准的端點，但 Agent 若被操控，仍可能透過這些合法端點做出不該做的事（例如用核准的 API 刪除資料）。最小權限的 API token 依然必要。
  • 平台支援限制：WSL 2 為實驗性、原生 Windows 有已知限制；Kubernetes 部署需要特定的網路元件支援。
  • 預設沒有 Agent：預設沙盒映像只有最小化的 Ubuntu，需要自行安裝與設定 Agent。
  • Telemetry：會收集匿名的運作類別與計數（官方表示不含沙盒名稱、主機名稱、檔案路徑、prompt、憑證或使用者內容），可用 OPENSHELL_TELEMETRY_ENABLED=false 關閉，或在編譯時移除。

5. 應用價值與適用場景

最適合正準備讓 Agent 長時間自主執行的團隊：例如在 CI 中跑 Coding Agent、讓 Agent 處理外部來源的資料（網頁、Email、客戶上傳的檔案）、或是多人共用的 Agent 平台。憑證注入機制對任何需要讓 Agent 呼叫付費 API 或內部系統的場景都特別有價值。Kubernetes 支援也讓它能成為企業 Agent 平台的底層 runtime。

Monday 的觀點與架構建議

  • OpenShell 最重要的設計是「Agent 永遠拿不到真正的金鑰」。這把「保護憑證」從靠 prompt 約束 Agent，變成靠架構保證——前者總有被繞過的一天，後者才可靠。這和 Cloudflare OS 的 Gatekeepers 是同一個思路。
  • 「高風險政策變更要經人工審核」把權限擴張變成一個需要明確批准的事件，避免政策在不知不覺中越開越寬。
  • 建議的分層防禦：OpenShell 負責執行環境的隔離與憑證保護；Agent 層用最小權限的 token；應用層對有副作用的操作加上人工確認；再用 iFixAi 這類工具定期稽核行為。
  • 回顧這個月，Agent 生態從「讓 Agent 能做更多事」逐漸轉向「讓 Agent 安全地做事」。當 NVIDIA、Cloudflare 這類基礎設施廠商都開始投入 Agent 沙盒，安全執行環境很可能會像容器一樣，成為 Agent 部署的標準配備。

參考來源