NVIDIA 以 OpenShell 0.1.0 開源 AI 代理的執行階段控制
NVIDIA 已釋出 OpenShell 0.1.0，這是一個開源執行階段，為 AI 代理新增可強制執行的權限、沙箱隔離與憑證控制。
NVIDIA 推出了 OpenShell 0.1.0，這是一個開源執行階段，旨在控制 AI 代理在部署後可以存取什麼、以及可以做什麼。該系統將沙箱隔離、服務控制、憑證管理與政策強制放在代理的工作負載之外，讓團隊可以在不重寫代理本身的情況下加入安全防護。
這次釋出鎖定的是一個日益嚴重的營運問題：能夠寫程式、使用工具、存取公司系統，並在新資訊持續到來時繼續行動的代理，雖然對長時間工作很有幫助，但也可能更改生產資料、洩露機密資訊，或超出其被指派的任務範圍。NVIDIA 表示，OpenShell 的目的是為這些動作在企業自動化、研究、機器人和其他部署中提供一個執行階段邊界。
NVIDIA OpenShell 改變了什麼
NVIDIA OpenShell 被定位為控制層，而不是新的代理框架。它的設計可與現有系統搭配運作，包括 Codex、Claude Code、Pi 和 Hermes，同時控管它們對工作區、運算資源、資料、憑證與外部服務的存取。
這種分離是產品設計的核心。代理仍然可以解讀指令、選擇工具並調整做法，但周圍的執行階段會決定請求的操作是否被允許。這可讓平台團隊對由不同開發者打造、或基於不同模型建立的代理套用一致的控制。
NVIDIA 表示，OpenShell 0.1.0 支援沙箱操作、治理整合、憑證保護、政策驗證與彈性運算。它可先在本機透過沙箱使用，之後再使用 Docker 或 Kubernetes 的運算驅動程式、工作區與身分中介軟體部署到共享基礎架構上。
這個執行階段是 NVIDIA 更廣泛的 Open Agent Safety Platform 的一部分，該公司將其描述為涵蓋應用程式、執行階段與基礎架構層。OpenShell 專門處理執行階段層，也就是可以檢查與限制代理對外請求及其與執行環境互動的地方。
執行階段如何強制執行權限
OpenShell 使用三個主要元件。OpenShell Gateway 負責管理跨多個代理的沙箱生命週期與政策。OpenShell Supervisor 與每個沙箱一起執行，位於代理工作負載之外，並根據適用政策檢查對外請求。沙箱則在核心層級對代理的檔案系統與程序套用控制。
這種架構旨在防止代理僅僅修改自己的控制。權限可以在工作負載之外管理，而團隊則可為單一沙箱或代理群組分配不同能力。這對於營運代理艦隊的組織尤其重要，因為若只有一套過於寬鬆的權限，可能讓某個工作流程中的錯誤影響到無關的系統。
NVIDIA 也強調憑證保護。OpenShell 不會直接向代理暴露憑證，而是可以中介對服務的存取，並限制代理可執行的 API 操作。該公司表示，這讓團隊能在保留敏感憑證於代理工作負載之外的同時，提供任務所需的能力。
該系統包含一個基於形式邏輯的政策證明器。NVIDIA 表示，它可以驗證模型化的權限是否仍在定義邊界內，並找出跨越這些邊界的行動。這比單純依賴提示或指令更強，但結果的有效性取決於組織是否完整地建模其系統、API、身分與允許的行動。
這次釋出的證據與主張
本報導中的產品細節來自 NVIDIA 自家的 Developer Blog 公告，因此屬於供應商報告。來源並未提供獨立測試結果、入侵防範測量、延遲數據、營運成本比較，或第三方對政策證明器的評估。
NVIDIA 表示，包括 Cadence、Slack 與 Gecko Robotics 在內的組織正在採用 OpenShell。該公司將這些範例連結到不同使用情境：Cadence 正將它用於晶片設計的 ChipStack Autonomous RTL Design Engineer，Slack 正在 OpenShell 上打造按需代理平台以進行任務自動化，而 Gecko Robotics 則用它來治理會對實體機器人做出決策的代理。
這些範例顯示了 NVIDIA 正在推進的部署範圍，但並不能證明採用規模、正式上線可用性或可衡量的商業成果。公告並未說明涉及的代理、使用者、工作負載或站點數量。因此，在各組織公布更多實作細節之前，建置者與買家應將這些採用訊號視為公司的主張。
0.1.0 版本也顯示這個執行階段仍處於早期。以開源形式提供，讓開發者有機會檢視程式碼、貢獻與測試控制，但這本身並不能證明其已成熟到足以應付高風險的生產環境。組織仍需評估專案的營運穩定性、整合負擔，以及其對故障情境的回應。
對建置者與企業團隊的影響
對 AI 建置者而言，OpenShell 可能減少將每一項安全控制都嵌入代理程式碼或提示中的需要。當底層模型、框架或代理指令改變時，執行階段邊界可以重複使用。這對正在實驗多個AI 代理或頻繁更新模型的團隊尤其相關。
對企業 AI 團隊來說，實務上的問題在於執行階段政策是否能順利對應到既有的身分、存取與治理系統。實用的部署必須回答諸如哪個代理可存取特定資料庫、哪些 API 方法被允許、請求是否需要人工核准，以及政策變更如何審查與記錄等問題。
這種做法對長時間運作的代理可能特別重要。短暫存在、用來起草文字的助理，與可能花上數天調查軟體故障、執行實驗、修改檔案或在實體環境中採取行動的代理，其風險輪廓並不相同。透過將控制放在工作負載之外，OpenShell 旨在限制代理不斷演變的決策所帶來的後果，同時不移除其跨多個步驟工作的能力。
這也伴隨取捨。嚴格的政策可能降低有用的自主性，或在合法任務需要新權限時造成營運摩擦。過於寬鬆或不完整的政策，即使執行階段運作正常，也可能留下缺口。政策證明器或許能幫助找出模型化的衝突，但無法驗證團隊未在政策或基礎架構模型中表達的假設。
接下來要觀察什麼
下一步的訊號將是生產文件、獨立評估，以及 OpenShell 在失敗或攻擊情境下的表現證據。開發者應留意政策語法、稽核日誌、核准流程、回復程序，以及超出 NVIDIA 公告範例之外的身分系統支援細節。
企業買家也應關注 Cadence、Slack 或 Gecko Robotics 是否公布具體部署成果，包括其代理艦隊的規模、受控動作的類型，以及落實這些政策的營運成本。專案的 GitHub 活動、發布節奏、議題處理，以及與 Docker、Kubernetes 和治理工具的整合，將提供更多成熟度 संकेत。
最後，OpenShell 與更廣泛的 Open Agent Safety Platform 之間的關係也很重要。NVIDIA 目前的公告聚焦於執行階段控制；買家會想了解這些控制如何連結到應用層級的防護、基礎架構安全、監控與人工監督。
Creati.ai 觀點
NVIDIA 的 OpenShell 釋出解決了一個真實的部署缺口：讓代理能夠存取有用的系統，但不把代理本身當作可信任的管理員。其最關鍵的想法，是將代理行為與支配執行的權限分離。
即便如此，這次釋出仍應被視為早期版本的基礎架構，而不是完整的安全解決方案。對建置者與企業而言，它的價值將取決於政策品質、與既有控制的整合、獨立測試，以及能否在不讓自主工作流程變得難以管理的前提下維持執行階段的可靠性。
