NVIDIA OpenShell，把 Agent 的权限写进策略

NVIDIA/OpenShell 这两天被放到了很多 Agent 工程师的视野里。它关注的是已经能读文件、装依赖、调用 API 的 Agent 如何被划出一条可执行的边界：哪些路径能读写，哪个二进制能连到哪个服务，凭证又能在什么请求里生效。

我会借 OpenShell 的设计，把“给 Agent 一个沙箱”到底意味着什么梳理出来，也看看它为什么会在新版本发布后出现在热门榜。希望对准备把 Agent 从本机试验推进到真实仓库和真实凭证的团队有所帮助。

OpenShell 目前在 GitHub 上约有 10,446 个 stars 与 1,409 个 forks。

把权限从提示词里拿出来

很多 Agent 的“权限控制”还停在提示词、容器挂载或环境变量上。这些方法都很有用，但都不等于运行时授权：Agent 一旦能执行任意命令，或者进程拿到了真实的云端 token，边界很容易变成“希望它不要越界”。

OpenShell 的核心对象是一份 YAML policy。官方文档把它拆成文件系统、进程、网络和网络中间件几类控制项：文件系统规则由内核的 Landlock LSM 执行，网络规则则对每一条外连默认拒绝。策略可以限定某个二进制只能访问特定 host 和端口，进一步约束 HTTP 请求的读写范围。

version: 1
filesystem_policy:
  read:
    - /workspace
network_policies:
  - name: github-read
    binaries:
      - /usr/bin/gh
    endpoints:
      - host: api.github.com
        port: 443
        access: read-only

上面的片段只是帮助理解结构，不应直接视作可用生产策略。真正值得注意的是它的默认立场：未被 policy 允许的外连被拒绝，而不是先让 Agent 通网、再靠日志回看问题。这对“给 Agent GitHub token，然后让它自行修 bug”这类场景很关键，因为读 issue、拉取仓库和创建 PR 本来就该是三个不同的权限。

凭证不进入 Agent 进程

OpenShell 的另一层设计是 provider。Agent 需要访问模型 API、GitHub 或内部服务时，凭证并不作为普通环境变量交给工作负载。按照 README 和 provider 文档，系统只会在经过批准的 endpoint 上把凭证加入出站请求；沙箱本身看不到真实 provider credential。

这让问题从“token 有没有泄漏”变成更具体的授权问题：哪个 sandbox、哪个进程、哪一个目的地、什么请求方法可以使用哪种凭证。策略变化还可以先进入人工审查。项目把这部分称为 policy prover：在批准前比较新旧策略，标出它额外放开的 host、凭证或 API 方法。

flowchart LR
  A[Agent process] --> B[Sandbox policy]
  B -->|allowed request| C[Supervisor / Gateway]
  C --> D[Approved provider endpoint]
  C -->|credential injection| D
  B -->|anything else| E[Denied]

这里的差异不在于“容器比宿主机安全”这样笼统的判断，而是把网络和凭证的最小权限放到一个可观察、可更新的控制面里。官方也明确提示，文件系统、Landlock 和进程设置在 sandbox 启动时固定；网络规则和中间件才可能在运行中更新。这个边界需要在部署设计时就说清楚。

为什么是现在

OpenShell 创建于 2 月 24 日，并非刚出现的演示仓库。它近期升温有两个可以核对的原因：一是项目以 NVIDIA 名义维护，并在 GitHub Today 上出现了明确的增长窗口；二是 0.1 系列把稳定发布节奏、隔离原语和扩展 API 写进了升级说明，最新的 v0.1.2 release 又补上了网络代理、Homebrew 迁移和 sandbox 回收相关修复。

更重要的是，Coding Agent 开始从“读代码并给建议”走向“连接外部服务并持续执行”。这时大家遇到的难题不再只是模型能不能完成任务，还包括它被允许做什么、发生异常时谁能看见、撤销权限会不会真的停止后续访问。OpenShell 把这些问题做成了 gateway、supervisor、sandbox 和 policy 的组合，而不是只新增一个 prompt 模板。

项目也把自己的操作方式封装成多个 Agent Skills。仓库中的 公开 skills 目录 包含 CLI 操作、生成 sandbox policy、诊断集群和诊断 inference 四类指导，README 提供 npx skills add NVIDIA/OpenShell 的安装入口。这是一个挺直白的信号：运行时本身要求严谨，交给 Agent 使用时也需要把命令、审查和排障路径写清楚。

先在受控环境里试

OpenShell 适合的第一个场景不是把本机开发目录和所有云端密钥一次性放进去，而是挑一条窄路径跑通。例如给一个只读的代码检索 Agent 分配单独 workspace，只允许它访问 GitHub API 的读取端点和一个模型提供商；确认 policy deny 日志、provider attach 和撤销流程都符合预期，再扩大能力。

试用前至少核实三件事：你的运行时是否在 支持矩阵 内，现有容器或 Kubernetes 网络策略是否会与它的 gateway 叠加，以及 provider profile 是否把权限严格收在真实调用的 endpoint 上。README 当前列出的本地前提包括 Linux、Apple Silicon macOS 或实验性的 WSL 2，以及 Docker、Podman 或宿主虚拟化。

对已经让 Agent 触碰代码托管、模型 API 或内部服务的团队来说，OpenShell 的价值不在于多开一个隔离环境，而在于让“这一次 Agent 被放行了什么”成为一条能审查、能收回、也能排错的策略记录。

---

• 仓库：github.com/NVIDIA/OpenShell
• 文档：NVIDIA OpenShell Docs