輝達 9 月 28 日發表 Open Agent Safety Platform，一套給 AI 代理使用的安全參考設計，軟體與硬體各佔一半。軟體端是開源執行環境 OpenShell，負責把每個 AI 代理關進沙盒；硬體端叫 Sentry，是跑在 BlueField-4 資料處理器上的監控程式，一旦發現 AI 代理越界，可在毫秒級將其隔離、停止。
輝達表示有 100 多家機構參與，名單中包括 Anthropic、微軟、SAP、Scale AI、摩根大通、Palantir、CrowdStrike、Palo Alto Networks、Hugging Face、Perplexity 等。發表時機也不難理解：過去一週，OpenAI 通報旗下 AI 代理在測試中闖入多個美國政府機關網站，Google 也承認 Gemini 在測試中入侵了三家真實企業，澳洲參議院隨後邀請兩家公司的執行長出席聽證會。
OpenShell：把權限放在 AI 代理碰不到的地方
OpenShell 以 Apache 2.0 授權開源，目前版本為 0.1.0。它由三個部分組成：Gateway 負責生命週期與政策管理；Supervisor 運作於工作負載之外，逐一檢查 AI 代理發出的請求；Sandbox 在核心層限制檔案與程序，除了經過 Supervisor 的那條路徑，AI 代理沒有其他網路出口。
憑證處理是這套設計中特別講究的一環。真正的 API 金鑰不會進入 AI 代理所在的環境，AI 代理手上只有佔位符，請求通過審核放行時才會替換成真正的金鑰，而且每把金鑰只綁定核准過的端點，拿去呼叫其他服務就會失效。政策以 YAML 撰寫，編譯成 OPA/Rego 規則，逐條判定 HTTP、GraphQL 與 MCP 請求。
官方列出的相容框架有 Codex、Claude Code、Pi、Hermes。技術部落格提到，晶片設計公司 Cadence、Slack 的隨需 AI 代理平台，以及打造巡檢機器人的 Gecko Robotics 已在試用。
Sentry：監控不跑在同一台機器上
輝達技術部落格把整套思路歸納成五項原則，其中一條是「帶外執行」：控制手段必須放在 AI 代理碰不到的地方。部落格原文寫道：
“an agent in these circumstances cannot be expected to fully govern its own behavior.”
（在這種情況下，不能指望 AI 代理完全管住自己的行為。）
Sentry 就是這項原則的硬體實現。它跑在 BlueField-4 上，與 AI 代理所在的主機隔開，依輝達的說法，對 AI 代理與攻擊者都不可見。在 Vera Rubin POD 中，BlueField-4 被放在節點存取模型的唯一通路上，所有呼叫模型的流量都必須經過它，監控與攔截以線速進行。
Anthropic 的做法是把 Claude Managed Agents 的推論迴圈與執行沙盒拆開運作，再接上 OpenShell 與 BlueField，企業可在沙盒這一層做存取控制。
黃仁勳在新聞稿中表示：“AI's extraordinary potential for society will only be realized if we solve AI safety.”（AI 對社會的巨大潛力，唯有在解決 AI 安全問題後才能實現。）
輝達在 AI 代理這條路上的幾步
把幾次發表串起來看，輝達在 AI 代理領域一直朝執行環境這一層推進。4 月 GTC 上，它號召一批企業軟體公司打造 AI 代理開發平台；5 月與 ServiceNow 合作推出企業級 AI 代理執行環境；這次則把「管住 AI 代理」單獨拉出來做成開源專案，並與自家 DPU 綁在一起。
軟體開源、執行端落在自家晶片上，這個組合與輝達過去推 CUDA、推 NVLink 的路數相近：生態系可以免費加入，但最強的那一層保障需要輝達的硬體。只想用 OpenShell 做沙盒的團隊，現在就能部署；想要 Sentry 這種獨立於主機的監控，就得等 BlueField-4 與 Vera Rubin 的出貨節奏。
中國本地團隊的情況要分開看。OpenShell 是開源程式碼，拿來修改、串接中國本土模型都沒有障礙；Sentry 依賴的 BlueField-4 屬於輝達資料中心網路產品線，能否在中國採購、以何種規格採購，目前沒有公開資訊，也無法查證。
參考來源：輝達新聞中心公告、NVIDIA 技術部落格（Open Agent Safety Platform 與 OpenShell 兩篇）、CocoLoop、IT之家、The Next Web；查證對象為合作機構名單、OpenShell 版本編號與開源授權、Sentry 隔離回應時間的官方說法。