智能体（AI Agent）越来越能「自己干活」：读代码、调 API、跑实验、甚至跨天跨周地推进任务。能力越大，风险也越大——误改生产数据、泄露密钥、越权调用外部服务，都可能从「提示词里写了别这么做」变成「它真的这么做了」。
NVIDIA 在 2026 年 9 月发布了开源运行时 OpenShell 0.1.0，核心思路很干脆：不改写现有 Agent，也能在工作负载外侧强制执行权限。本文基于 NVIDIA 官方技术博文，并结合 OpenShell 文档与 GitHub，梳理它解决了什么问题、运行时控制长什么样，以及本地如何快速上手。
为什么「只靠提示词约束」不够
很多团队会在系统提示里写：只能读不能写、不要访问生产库、密钥别外泄。这对「听话的演示」有用，对「长期自主、会写代码、会起子进程」的 Agent 则很脆弱：
- 提示词不是强制边界。模型可能忽略、被诱导绕过，或在工具链里间接越权。
- Agent 会演化行为。它可能换工具、生成脚本、委派子 Agent，原先写在 prompt 里的「约定」跟不上实际调用路径。
- 密钥一旦进了工作负载，就可能被打印到日志、写进文件，或发往未授权端点。
- 审计与复盘困难。事后很难证明「当时到底允许了什么」，只能靠对话记录猜。
OpenShell 把权限下沉到运行时：文件系统与进程用内核级控制，出站流量经 Supervisor 对照策略检查，真实凭据留在工作负载外侧。Agent 仍可灵活选工具、改计划；越界请求会被拦下，而不是「希望它别越界」。
OpenShell 是什么
OpenShell 是面向自主 Agent 舰队的开源安全运行时，属于更广义的 NVIDIA Open Agent Safety Platform 中的运行时层。它把沙箱执行、服务访问控制、凭据管理与形式化策略分析组合在一起：你给任务所需的最小能力，由 OpenShell 在工作负载之外强制执行。
0.1.0 强调几类能力：多租户工作区与权限隔离、形式化策略校验、可扩展的安全与治理对接、凭据受保护的服务访问，以及跨容器 / VM / Kubernetes 的 CPU、GPU 执行。生态上，文档提到 Cadence（芯片设计）、Slack（企业自动化）、Gecko Robotics（实体机器人决策治理）等采用场景。Agent 侧可配合 Codex、Claude Code、Pi、Hermes 等框架，不必先把业务 Agent「重写一遍」才能上运行时控制。
运行时控制：四块拼图
1. Sandbox：内核级围栏
每个 Agent 跑在独立沙箱里。内核控制限制可读可写的文件、可用的系统调用与额外特权；出站网络默认没有直通路径，只能经 Supervisor。无论是起 shell、跑生成代码、拉起子进程，还是尝试把任务委派给子 Agent，这些围栏都在。
策略决策会记入 OCSF（Open Cybersecurity Schema Framework）审计轨迹。被拦截的请求可返回带说明的错误，方便 Agent 调整下一步，而不是静默失败。
2. Service Access：比「能不能连上」更细
很多系统只做到「允许访问某个域名」。OpenShell Supervisor 可对配置的 HTTP、GraphQL、MCP 流量做检查：同一 API 上可以允许读、禁止写。策略用 YAML 编写，再编译为 OPA/Rego，对每个出站请求求值。
博客里的演示很直观：先建一个无外网沙箱，curl GitHub 公共接口会失败；再热更新为只读策略后，GET 通过、POST 被拦——Agent 发同样请求时规则完全一样。
3. Credentials：占位符进沙箱，真密钥在外侧
Agent 往往需要模型 API 或私有服务。OpenShell 用 Provider 描述凭据、端点与允许的程序：沙箱内见到的是受控访问路径，真实凭据只在授权请求到达批准端点时，在工作负载外侧被替换注入。把占位符发到未批准目的地会被拒绝；即便真实密钥本身有写权限，只读 API 策略仍可挡住写操作——等于在服务方权限之上再加一层「Agent 可用范围」。
4. Policy Analysis：形式化证明「允许了什么」
策略「看起来严」不等于「没有旁路」。例如拦了一个工具的 GitHub 写操作，另一个允许的工具或生成代码仍可能用同一凭据写出。OpenShell 的 policy prover 用形式化逻辑检查策略（含 Provider 贡献的访问）是否落在运营者划定的边界内，或给出一条具体越界动作。结论来自策略模型，Agent 的自然语言辩解改不了证明结果。
博客还提到：在长时对抗实验中，削弱防护的前沿 Agent 会花很长时间试图说服 AI 审阅者放开权限；结合形式化分析与运行时控制后，受保护仓库未出现写入。运行中若需扩权，可启用 policy advisor：Agent 可提议窄范围策略变更，默认待人审，且不能自己批准自己的请求；通过后规则可热加载进运行中的沙箱。文件系统与进程限制在沙箱启动时确定，要改通常需新沙箱。
架构：Gateway / Supervisor / Sandbox
三个组件分工清晰：
| 组件 | 作用 |
|---|---|
| Gateway | 管理大量沙箱的生命周期与策略 |
| Supervisor | 与每个沙箱配对，在工作负载外检查出站请求 |
| Sandbox | 执行 Agent，内核级控制文件与进程，网络只经 Supervisor |
对开发者，这意味着：包装现有 Agent，而不是改写它。用指定镜像与策略创建沙箱，把 Agent 命令接在 -- 之后即可；权限、审计、凭据绑定由外侧运行时接管。本地可用 Docker / Podman / MicroVM；共享基础设施可用工作区与 SDK，计算驱动对接 Docker、Kubernetes 等，并可在请求路径上挂可信中间件对接身份与业务校验。
本地快速上手
环境要求：Linux、Apple Silicon 的 macOS，或实验性的 Windows WSL2；本机需 Docker、Podman 或支持虚拟化的 MicroVM。详见官方 Support Matrix。
安装 CLI 与本地 Gateway：
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell status默认安装当前稳定版；需要固定版本时可设置 OPENSHELL_VERSION。PyPI 上的 openshell 是 Python SDK，不安装 CLI。
创建沙箱（可直接挂 Agent）：
# 空沙箱（默认最小 Ubuntu，无预装 Agent）
openshell sandbox create --name demo
# 或直接启动常见编码 Agent（以本机已配置为前提）
openshell sandbox create -- claude # 亦可为 opencode、codex、copilot 等观察策略如何生效（博客演示思路）：
# 无外网策略的沙箱
openshell sandbox create --name policy-demo \
--no-auto-providers \
--policy examples/no-network.yaml
# 沙箱内：预期失败
curl -sS --max-time 10 https://api.github.com/zen
# 宿主机查看拦截日志
openshell logs policy-demo --since 5m
# 热更新为 GitHub REST 只读策略（示意片段）
openshell policy set policy-demo \
--policy examples/github-readonly.yaml --wait只读策略的关键意图类似：允许指定二进制（如 /usr/bin/curl）访问 api.github.com:443，protocol: rest 且 access: read-only，从而放行读、拦截写。完整 YAML 还需保留 filesystem_policy 等字段，因为 policy set 是整份替换；官方教程 Write Your First Sandbox Network Policy 有完整示例。
挂 Provider 再跑 Agent（凭据不进工作负载）：
openshell sandbox create \
--provider github \
-- codex更完整的「第一个 Agent」路径见文档 Run Your First Agent：导入 Provider Profile、创建 Provider、指定镜像与模型命令。被拒访问后可用 openshell rule get / approve / reject 审阅窄范围扩权提案。
社区可加入 CNCF Slack 的 #openshell-dev，代码与贡献见 NVIDIA/OpenShell。
给 Agent 建设者的实践建议
- 把「最小权限」写成可执行策略，而不是只写进 prompt。 Prompt 负责任务意图；文件系统、网络方法级权限、凭据绑定交给运行时。
- 默认拒绝，按任务增量放权。 先无网或极窄策略跑通，再用 advisor + 人工审批准扩权；避免一上来「全网可达 + 真密钥进容器」。
- 同一服务上区分读/写。 对 REST/GraphQL/MCP 做方法级控制，比「域名白名单」更贴近业务风险。
- 凭据走 Provider。 让真实密钥绑定批准端点；即使上游 Token 权限偏大，也可用策略收紧 Agent 侧用法。
- 用 prover 做变更评审。 策略合并、多工具旁路、多 Agent 权限叠加时，形式化检查比「读 YAML 感觉差不多」可靠。
- 本地沙箱 → 共享 Gateway。 开发期本机 Docker 即可；多用户/多团队再上工作区、Helm/Kubernetes 与中间件治理。
- Java / Spring 场景怎么接。 若 Agent 会调你们的内部 HTTP API、MCP 工具或 CI，可先把「只读查询 / 禁止变更」落成 OpenShell 网络策略，再在 Spring 服务侧保留原有鉴权——两侧叠加，而不是互相替代。业务 Agent（LangChain4j、自研编排等）通常只需换启动方式：镜像 + 策略 + Provider，而不是改业务代码结构。
小结
OpenShell 0.1.0 回答的是 Agent 工程里越来越尖锐的问题：自主能力与可强制边界如何并存。它用 Gateway、Supervisor、Sandbox 在外侧执行沙箱、服务访问、凭据与策略分析，让 Codex、Claude Code 等现有 Agent 可以「原样放进围栏」，而不必先为安全模型重写一遍。提示词仍然重要，但不应再是唯一防线。
若你正在给团队落地 Agent 平台，建议从官方博客与 Quickstart 走一遍策略演示，再对照自己的内部 API 画一张「允许读 / 禁止写 / 密钥不可出域」的权限表——那往往就是第一份值得提交评审的 OpenShell 策略。
参考链接
- Add Runtime Controls to AI Agents with NVIDIA OpenShell（NVIDIA Technical Blog）
- NVIDIA/OpenShell
- OpenShell 文档