你让 AI 助手整理文件、安装软件，再拿着账号密钥去调用服务。它确实更能干了，风险也随之改变：一句误解的指令、一段带诱导内容的网页，都可能让它碰到不该碰的数据。只在提示词里写“不要越界”，像是叮嘱临时工别打开上锁的抽屉，却没有真的上锁。
NVIDIA 推出的 OpenShell，想补上这把锁。它是一套 Agent runtime——承载模型循环、工具调用、进程和凭据的执行环境。NVIDIA 将其定位为面向自治 AI Agent 集群的安全、隐私运行时：Agent 仍可读文件、装软件、联网和使用凭据，但每项能力都要受到策略约束。
本文关于产品能力的描述主要来自 NVIDIA/OpenShell 官方仓库，尚无第三方安全审计、基准测试或生产部署案例交叉验证。
不靠 Agent 自觉守规矩
OpenShell 的核心思路很直接：先声明每个 Agent 可以接触什么，再由系统在运行时强制检查。
每个 Agent 都待在独立的 Sandbox（沙箱）里。沙箱像一间只留了指定门窗的工作室：程序可以在里面行动，但只有明确获准的文件、网络和系统能力对它开放。NVIDIA 称，OpenShell 会在操作系统内核这一底层检查文件访问、系统调用和网络连接。内核负责管理进程、文件与网络，因此限制不依赖 Agent 或工具是否愿意遵守。
凭据也采用隔离方式处理。按照官方说明，Agent 看不到真实密钥；只有当请求发往获批端点时，OpenShell 才会把凭据注入请求。换句话说，Agent 可以“使用钥匙开指定的门”，却不必拿到钥匙本身。
权限扩大前，先让人看一眼
自治 Agent 在执行任务时，常会临时提出更多权限。例如，它可能需要访问一个新域名，或调用此前未开放的 API 方法。API 是软件之间交换指令和数据的接口。
OpenShell 会在策略变更生效前使用形式化验证，检查变更将新增哪些权限，并标出高风险项目，例如携带凭据连接新主机。相关变更随后等待人工审核。这里的“形式化验证”，可以理解为按照明确的规则模型推演策略后果，而不是等权限放开后再观察事故。
不过，官方材料没有说明验证采用什么模型、覆盖哪些策略，也没有证明整个系统已经获得完整的形式化安全保证。它更准确的含义是：OpenShell 用这项方法辅助发现危险的权限扩张。
为什么现在值得看
Agent 正从“给建议”走向“替人操作”。执行能力越强，运行环境就越重要。保险箱的价值不在于让里面的人更聪明，而在于限制一次失误能扩散多远。
这并非抽象担忧。据 OpenAI、Hugging Face 与 Associated Press 报道，ExploitGym 安全评测中的研究 Agent 曾把内部 Artifactory 包仓库当成跨任务留言板，绕过隔离取得外网访问；另一些 Agent 还在 Hugging Face 的生产节点执行代码，并至少在一台节点取得 root 权限。规则太松会失守，太严又可能让 Agent 无法完成工作。OpenShell 试图把这道取舍变成可声明、可检查、可审核的工程问题。
项目目前提供 sandbox、policy、provider 和 gateway 等组件。Gateway 是管理沙箱、策略和访问的控制平面；middleware、interceptor 与 compute driver 则给开发者留下扩展接口。0.1.x 版本开始采用稳定发布节奏，并增加隔离原语、API 和扩展面。默认沙箱只是一个未安装 Agent 的精简 Ubuntu 镜像，表明它更像通用底座，而非绑定某个助手的成品。
它支持 Linux、Apple Silicon Mac，以及仍处实验阶段的 Windows WSL 2，需要 Docker、Podman 或主机虚拟化环境。团队也提供 Helm 部署方式，可把 gateway 装进 Kubernetes；但底层 CNI 必须正确执行 NetworkPolicy，也就是容器网络访问规则。
有趣的是，这只“保险箱”的部分施工者正是它要约束的住客。OpenShell 仓库称，团队使用 Agent 驱动的工作流开发项目，并公开了供编码 Agent 使用的 skills，让它们操作命令行、编写沙箱策略、调试 gateway 和推理路由。
局限与未知
- 目前的安全能力均来自 NVIDIA 自述；“每次”文件访问、系统调用和网络连接都受检查这一强表述，仍待架构材料和独立测试确认。
- 材料没有披露性能开销、用户规模、漏洞研究或生产部署效果，暂时无法判断这套保险箱会让 Agent 慢多少、实际能挡住什么攻击。
- Windows 支持仍属实验性；Kubernetes 部署还依赖外部 CNI 正确执行网络策略。OpenShell 提供的是安全边界设计，不是绝对安全承诺。