当开发者让 Coding Agent 修复 Bug、运行命令或安装依赖时，通常也要把读代码、改文件、访问网络和调用 API 的权限一并交出去。问题随之而来：它是否会读到不该读的文件，把密钥带进不必要的请求，或连接与任务无关的服务？NVIDIA 近期在 GitHub 上开源了 OpenShell，试图为这类 Agent 提供一个受控执行环境。
从项目介绍看，OpenShell 的定位不是替代 Agent，而是给 Agent 加一层运行时约束。开发者先用策略声明 Agent 可以接触哪些文件、访问哪些服务，OpenShell 再在实际操作发生时执行这些规则。Agent 仍然负责理解任务、调用工具，但工具能在环境里做什么，由 OpenShell 控制。
网络访问要过沙箱外的“守门人”
按照 OpenShell 的设计，如果 Agent 在处理代码仓库时需要连接外部服务，请求会先进入沙箱。沙箱负责识别发起请求的程序，然后把检查请求交给沙箱外部的 Supervisor。Supervisor 核对策略后，才会允许真正的外部连接建立；如果请求需要凭据，还要继续检查该程序是否有资格使用对应密钥。
这里的关键是判断权不在 Agent 一侧。Agent 和它启动的程序运行在受限制的环境中，负责放行的 Supervisor 位于另一侧。也就是说，Agent 不能仅凭自身声明“这个请求很安全”就获得访问权。
部署方式上，如果使用 Docker 或 Podman，工作负载容器会关闭网络，并通过专用通道连接 Supervisor。如果部署到 Kubernetes，则依靠 NetworkPolicy 限制出站流量，并需要集群网络插件实际执行这套规则。
文件权限、密钥托管与凭据边界
文件访问同样被纳入策略管理。OpenShell 当前的 Linux 后端使用 Landlock 约束文件系统访问，工作负载以非 root 身份运行，且不附带 Linux capabilities。哪些目录可读、哪些目录可写，都需要在策略中明确列出。
- 文件策略默认为 best_effort：如果列出的路径全部无法应用，或 Landlock 无法执行这些规则，沙箱可能不应用文件规则而继续运行，并记录高严重性告警。
- 如果设为 hard_requirement，同类情况会直接导致启动失败。
- 无论哪种模式，都会跳过个别缺失或无法打开的路径。
不过，文件限制生效并不意味着 Agent 不会改错代码。官方说明也提到，开放给 Agent 的可写目录仍可能被错误修改，代码审查、测试和版本管理仍是必要环节。
在密钥管理上，OpenShell 提供了 Provider 机制。开发者不把真实 API Key 直接放入 Agent 环境变量，而是交给 Provider 管理。Agent 环境中只能拿到占位令牌，代理在转发请求前才将其替换为真实凭据。
网络访问和密钥使用是两次独立检查。请求发起程序与目的地要符合网络策略，目标主机、端口和路径还要符合凭据绑定范围。官方示例中，GitHub Provider 的凭据绑定在指定 GitHub 端点上。即使沙箱被允许访问 uploads.example.com:443，把 GitHub 占位令牌发到该地址，代理仍会以 credential_endpoint_mismatch 拒绝请求。换言之，批准访问某个网站，并不等于把 GitHub Token 也交给它。
但这套保护有边界。凭据替换需要代理按 HTTP 处理请求，跳过检查的原始 TLS 隧道和非 HTTP 隧道不支持替换。开发者如果自行把密钥放在项目文件、提示词或其他位置，Provider 不会自动接管。此外，请求获准发送给云端模型后，内容仍会到达模型服务商；沙箱限制的是访问权限，并不会把云端推理变成本地推理。
被拒绝后如何补规则：人工审批与 Agent 提案
当 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 等内核能力，仅有内核版本号不足以保证运行；若不满足必要条件，启动检查会拒绝放行。
官方给出的安装与最小启动命令如下：
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell status
openshell sandbox create –name demo
其中，openshell status 中的 Status: Connected 表示网关健康检查可达，还需看到 Authentication: Authenticated，确认凭据通过认证，并确认 demo 沙箱创建成功。默认工作负载镜像是 nvcr.io/nvidia/base/ubuntu:24.04，不附带 Agent CLI；得到空沙箱属于正常结果。
要运行真正的 Agent，还需要准备包含 Agent 和所需工具的镜像，配置 Provider，再把 Agent 命令传给沙箱。官方首个 Agent 教程使用 OpenCode 加 OpenRouter 演示了这一流程，包括凭据配置、镜像选择，以及遇到网络拒绝后如何审批。
对于首次尝试，更稳妥的方式是先沿用官方示例，再用一个没有敏感数据的小项目验证：所需工具能否运行、网络规则是否够用、被拒绝的请求是否容易判断。等这条流程走通后，再考虑接入日常仓库。
从功能设计看，OpenShell 更像一个为 AI Agent 准备的受控工作环境。它并不解决 Agent 是否能写出正确代码的问题，而是把“Agent 能碰到什么”变成可声明、可检查、可审批的策略问题。对于希望让 Coding Agent 承担更多任务、又不愿一次性交出全部权限的团队，这是一个值得关注的基础设施方向。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/rang-coding-agent-shao-na-quan-xian-nvidia-kai-yuan
