导语：会动手的 AI，也需要一间“带门锁的工作间”
你让一个 AI Agent 帮你改代码、查接口、跑命令。它确实更像助理了：能读文件，能联网，能调用工具。问题也随之变得很现实：它不该看的文件，能不能看到？它拿到的 API key，会不会被带出环境？它联网时，能不能随便往外发请求？
OpenShell 想解决的就是这个边界问题。按 NVIDIA/OpenShell 官方 README 的说法，它是面向 autonomous AI agents（自主 Agent）的 safe, private runtime。runtime，也就是程序真正执行任务时所处的软件环境。OpenShell 把 Agent 放进 sandbox（沙箱，隔离执行环境）里，再用 declarative YAML policies（声明式 YAML 策略，用配置写清允许和禁止的行为）管理文件、网络、进程和模型调用。换句话说，它不是让 Agent 少做事，而是给 Agent 一间有规则的工作间。
需要先说清信源：本篇事实均来自 NVIDIA/OpenShell 官方仓库材料，尚缺少第三方审计、基准测试或独立安全评估。因此文中涉及安全能力的表述，都应理解为项目自述，而不是已经被外部验证的结论。
它到底管住什么？
OpenShell 的核心设计是：Agent 运行在受控沙箱中，外部由一个 gateway（网关，负责协调沙箱生命周期的控制平面）管理。每个 sandbox 默认只有最小的 outbound access（对外访问权限）。如果要放开更多网络访问，就写一段 YAML policy，由 proxy 在 HTTP method 和 path 层面执行规则，而且不需要重启。
官方 README 给了一个很直观的例子。默认状态下，沙箱里执行 curl https://api.github.com/zen，会被 proxy 以 HTTP 403 拦下。应用一个只读 GitHub API policy 之后，GET 请求可以通过；但 POST 到 GitHub issue 的请求会被 L7（应用层）策略拒绝，返回 policy_denied。这说明 OpenShell 想管的不是“能不能联网”这么粗的开关，而是“能访问哪个服务、用什么方法、访问哪条路径”。
文件和凭据也在它的管辖范围里。官方材料称，OpenShell 用策略防止 unauthorized file access（未授权文件访问）、data exfiltration（数据外泄，把敏感文件、密钥或内部信息传到不该去的地方）和 uncontrolled network activity（不受控网络活动）。它还把 credentials（凭据，比如 API keys、tokens、service accounts）作为 provider 管理，在创建沙箱时注入。README 称，凭据不会泄露到沙箱文件系统，而是以运行时环境变量注入。
为什么这件事现在值得看？
过去很多 Agent demo 的默认前提是：开发者在本机给它权限，让它自己跑。这个阶段最重要的是“能不能做成”。但当 Agent 开始接近真实工作流，问题会换成“能不能可控地做”。
OpenShell 的入选意义在这里。NVIDIA 把 Agent 的运行环境明确描述成一个安全、私有的系统边界。这说明 Agent 基础设施的竞争，正在从模型调用和工具编排，推进到执行环境本身：谁来隔离？谁来给权限？谁来记录和阻断越界行为？
从官方材料看，OpenShell 已经把这个边界拆成几个层次。Filesystem 策略限制文件读写，Network 策略限制对外连接，Process 策略限制提权和危险 syscall，Inference 策略把模型 API 调用重新路由到受控后端。静态部分，例如文件系统和进程策略，在沙箱创建时锁定；动态部分，例如网络和推理策略，可以在运行中的沙箱上热更新。
它支持的主机环境包括 macOS、Windows with WSL 2 和 Linux。本地运行需要 Docker、Podman，或启用 host virtualization 来支持 MicroVM-backed sandboxes。README 还称可以创建沙箱运行 claude、opencode、codex、copilot 等 Agent；默认 sandbox container 包含 python(3.14)、node(22)、gh、git、vim、nano，以及 ping、dig、nslookup、nc、traceroute、netstat 等工具。
部署路径也已经露出基础设施化的方向。OpenShell 可用安装脚本或 PyPI 安装；PyPI 方式要求 uv。二进制安装和 PyPI 安装默认安装 latest stable release，也可以通过 OPENSHELL_VERSION 或 uv pin 指定版本。它还提供 Helm chart，可从 GHCR 的 OCI chart 部署 gateway 到 Kubernetes 集群。不过官方同时标注 Kubernetes deployment path 是 Experimental，仍在 active development，可能有 rough edges 和 breaking changes。
先从个人环境跑起来
OpenShell 当前并没有把自己包装成成熟企业平台。官方 README 明确写着 Alpha software / proof-of-life，定位是 single-player mode：one developer、one environment、one gateway。也就是说，它现在更像一个可以跑起来、可以试验边界模型的早期系统，而不是已经面向大规模组织稳定落地的成品。
这反而是它有意思的地方。很多安全系统一上来就讲企业管控，但 Agent 的真实风险往往先发生在个人开发环境里：一个本地助理拿着你的 shell、repo、token 和网络权限。OpenShell 的起点是把这个个人环境先装进沙箱，再逐步走向 multi-tenant enterprise deployments（多租户企业部署）。
局限与未知
- 目前材料只有 NVIDIA/OpenShell 官方信源，安全能力缺少第三方审计、漏洞评估或独立复现实验支撑。
- 项目仍是 Alpha / proof-of-life，Kubernetes 和 GPU passthrough 等路径被标为 Experimental，不宜理解成企业级稳定可用。
- README 披露了架构组件和策略层级，但没有给出性能开销、真实攻击场景测试或大规模部署案例。