NVIDIA 于 2026 年 9 月 28 日介绍 OpenShell 0.1.0，一个在现有 AI agent 外层加入可执行权限控制的开源 runtime。核心概念是：agent 可以继续解读指令、选择工具和调整工作方法，但文件、网络、credential、API 和 process 的边界由 runtime 在 agent workload 之外执行。
OpenShell 的架构包括 Gateway、Supervisor 和 Sandbox。Gateway 管理多个 sandbox 的生命周期和 policy；每个 sandbox 由在 workload 外运行的 Supervisor 检查 outbound request；Sandbox 则用 kernel-level controls 限制文件和 process，并让网络只能经过 Supervisor。这种分层设计把控制点由 prompt 或 agent 自己的解释，移到可以被 runtime 强制的地方。
NVIDIA 表示，Supervisor 可以检查 HTTP、GraphQL 和 Model Context Protocol traffic，不只是判断「能不能连接到某服务」，还可以允许同一个 API 的 read、封锁 write。控制在 agent 启动 shell、执行生成代码、启动 child process 或委派 sub-agent 后仍然有效；policy decision 会记录在 OCSF audit trail。
credential protection 也是 OpenShell 的重点。Agent 只拿到 placeholder，Supervisor 在批准的 endpoint 和 provider profile 下，于 workload 外替换真正的 credential；如果 agent 把 placeholder 送到不在批准范围的目的地，OpenShell 会拒绝。这可把「credential 可用」和「agent 可以如何使用 credential」分成两道控制。
当 agent 发现需要新的服务或数据来源时，policy advisor 可以提出狭窄的 network 或 file policy change，但提案默认要等待人工批准，agent 不能批准自己的要求。NVIDIA 也介绍 formal policy prover，用来检查 policy 的 permission model 是否越过 operator 设定的界线，并找出可能越界的具体动作。
NVIDIA 说 Cadence、Slack 和 Gecko Robotics 正在不同场景采用 OpenShell，包括 chip design、enterprise automation 和 physical robotics governance。这些是供应商列出的 adoption examples，不是独立成效评估；实际部署仍需要检查 compute driver、身份中介、policy 维护、audit retention 和故障时的 recovery path。
对企业 agent 而言，OpenShell 所代表的方向是把安全由「提醒 agent 不要做某件事」推向「即使 agent 生成了指令，也要在 runtime 层阻止未授权动作」。这不能取代 threat model、最小权限、人工 approval 和 end-to-end 测试，但能为长时间、可调用工具的 agent 提供更清晰的 enforcement boundary。
