让 Coding Agent 修一个 Bug，往往要给它读代码、改文件、装依赖、调用 API 的权限。任务交出去以后，又会惦记另一件事：它会不会读到不该读的文件，把密钥带进某个请求，或者连上一个根本用不着的服务？
把这些要求写进提示词，执行时仍然需要有人或程序把关。
这两天， Github 有一个 NVIDIA 开源的项目爆火了，就是解决这些问题的。
你用策略规定 Agent 能碰哪些文件、访问哪些服务，OpenShell 在实际操作发生时执行这些规则。
它适合用来运行需要读写文件、执行命令的 Agent。Agent 继续负责理解任务和调用工具，OpenShell 负责约束这些工具在环境里能做什么。
项目地址：github.com/NVIDIA/Open...
一次联网请求，先经过谁？
假设 Agent 正在处理一个代码仓库，需要连接外部服务。按 OpenShell 的实现，请求先经过沙箱，由沙箱识别是哪个程序发起，再交给沙箱外的 Supervisor 检查。
Supervisor 会核对策略，允许后才建立真正的外部连接；需要凭据的请求，还要检查它有没有资格使用对应密钥。
是否放行由沙箱外的组件判断：Agent 和它启动的程序在受限制的一侧，负责判断是否放行的 Supervisor 在另一侧。Agent 不能靠自己说一句"这个请求很安全"获得访问权。
用 Docker 或 Podman 运行时，工作负载容器会关闭网络，通过专用通道连接 Supervisor。部署到 Kubernetes 时，则依靠 NetworkPolicy 限制出站流量，需要集群的网络插件实际执行这套规则。
文件访问也有对应的限制。当前 Linux 后端用 Landlock 约束文件系统访问，工作负载以非 root 身份运行，不带 Linux capabilities。哪些目录能读、哪些能写，要在策略中明确。
文件策略默认采用 best_effort：当列出的路径全部无法应用，或 Landlock 无法执行这些规则时，沙箱可能不应用这些文件规则而继续运行，并记录高严重性告警。设为 hard_requirement 后，这类情况会导致启动失败；但两种模式都会跳过个别缺失或无法打开的路径。这个区别不影响 Landlock ABI v3 等强制内核要求。
文件限制正常生效时，你给 Agent 开放的可写目录仍然可能被它改错。代码审查、测试和版本管理还有各自要做的事。
密钥可以用，但不必直接交给 Agent
Agent 调用模型 API，通常需要一个 API Key。把真实 Key 直接塞进它的环境变量，进程就有机会读到这段字符串。
OpenShell 提供了 Provider 来管理凭据。交给 Provider 管理后，Agent 环境里拿到的是占位令牌，代理在转发请求前才把它替换成真实凭据。
能联网和能带上密钥，是两次独立检查：请求的程序与目的地要符合网络策略，目标主机、端口和路径还要符合凭据绑定范围。
官方给了一个例子：GitHub Provider 的凭据绑定在指定的 GitHub 端点上。即使另外允许沙箱访问 uploads.example.com:443，把 GitHub 的占位令牌发到那里，代理仍会以 credential_endpoint_mismatch 拒绝请求。
所以，批准访问一个网站，并不等于顺手把 GitHub Token 也交给了它。
这套保护有明确的适用条件。凭据替换需要代理按 HTTP 处理请求，跳过检查的原始 TLS 隧道和非 HTTP 隧道不支持这种替换。自己放在项目文件、提示词或其他位置的密钥，也不能指望 Provider 自动接管。
另外，请求获准发送给云端模型后，其中的内容仍会到达模型服务商。沙箱限制访问权限，不会把云端推理变成本地推理。
请求被拦了，按需要补权限
比如 Agent 需要安装依赖，当前策略却没有允许访问对应的软件源，请求会被拒绝。
OpenShell 能从被拦截的连接中起草规则，把范围收在具体的程序、主机和端口。人在宿主机查看待处理提案，确认它确实属于当前任务，再批准；新规则会加载到正在运行的沙箱，Agent 可以重试，不必重启整个环境。
还有一种更主动的用法：开启 Policy Advisor，让 Agent 读取拒绝记录，自己提交需要的网络规则。对于 HTTP API，提案还可以进一步限定请求方法和路径。
两种流程容易混淆。系统根据连接拒绝记录起草规则，不要求开启 Policy Advisor；让 Agent 主动提案的功能默认关闭，需要另外启用。提案默认等待人审核，自动批准也是单独开启的选项。
Agent 提案只能新增网络规则，不能借此修改文件访问、Landlock 或进程设置。
提交规则之后，OpenShell 会检查新增的访问风险。Policy Prover 使用 SMT 求解器分析策略，例如有没有增加携带凭据访问新目的地的能力；系统还会标记私有网络地址、通配主机等风险项。
开启自动批准后，不涉及 Provider 凭据的新公网访问，只要通过其余风险检查，也可能直接获批，包括系统根据拒绝记录生成的规则。想逐项确认新增访问范围，就保留人工审批。
这里的"形式化验证"有范围限制，只对模型覆盖的策略特性和行为提供保证。独立的策略上限检查遇到目前不支持的 GraphQL、MCP 规则，会报告无法检查。通过检查，也不代表 Agent 接下来写出的代码一定正确，或每个业务操作都值得批准。
我会保留人工审批，先观察它为一个小任务申请了哪些权限。能看到具体哪个程序要访问哪里，比面对一个笼统的"允许所有操作"更容易判断。
官方还把执行请求的数据平面和管理沙箱的控制平面分开画了出来，下图标出了两部分各自的扩展位置。
先用一个空沙箱确认环境
本文对照 OpenShell 0.1.2 文档，未做本地部署实测。官方平台表列出 Debian / Ubuntu 的 x86_64、arm64，以及使用 Docker Desktop 的 Apple Silicon Mac；Windows 的实验支持覆盖 x86_64，需要 WSL 2 和 Docker Desktop。运行时还支持符合条件的 Linux Podman 和 MicroVM；MicroVM 在 macOS 上使用 Hypervisor.framework，在 Linux 上使用 KVM。
走 Docker 路线，需要 Docker Desktop 或 Docker Engine 28.0 及以上版本。Linux 沙箱还依赖 Landlock、seccomp 等内核能力，内核版本号本身不足以保证能运行；不满足必要条件时，启动检查会拒绝放行。
下面是官方安装与最小启动命令。安装脚本会按平台安装软件包并启动本地 Gateway 服务，创建沙箱时还可能拉取镜像：
bash
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell status
openshell sandbox create --name demoopenshell status 中的 Status: Connected 表示网关健康检查可达，还要看 Authentication: Authenticated，确认凭据通过认证，再确认 demo 沙箱创建成功。默认工作负载镜像是 nvcr.io/nvidia/base/ubuntu:24.04，不附带 Agent CLI；得到空沙箱是正常结果。
要运行真正的 Agent，还需要准备包含它和所需工具的镜像，配置 Provider，再把 Agent 命令传给沙箱。
官方的首个 Agent 教程用 OpenCode 加 OpenRouter 演示了这条流程，包含凭据配置、镜像选择，以及遇到网络拒绝后如何审批。
地址： docs.nvidia.com/openshell/l...
首次尝试可以沿用这个示例，再拿一个没有敏感数据的小项目验证：所需工具能否运行、网络规则是否够用、被拒绝的请求是否容易判断。等这条流程走通，再考虑接入日常仓库。
总结
你可以把 OpenShell 理解成一个专门给 AI Agent 准备的工作环境。Agent 在里面读代码、改文件、跑命令，OpenShell 就按你设好的规则，管住它能访问哪些文件、连接哪些服务，以及怎么使用托管的密钥。想让 Agent 多干点活，又不想一下子把所有权限都交出去，可以看看这个项目。