用OpenShell约束Agent的系统权限

AI agent 能读文件、装依赖、调用 API，才能真正替程序员干活；但这些能力也可能让它读走 .env，或把敏感数据发到外部。NVIDIA OpenShell 给出的方案，是在 agent 和机器之间加一层执行权限的运行时。

原文的核心判断是：别把安全寄托在 agent 听话上，要让文件、进程、网络和凭据访问受到实际约束。不过，这是一篇基于项目文档的介绍，没有性能实测，也没有攻击对照实验。它值得读的地方，是把「放手让 AI 写代码」需要补齐的权限边界讲具体了。

agent 能做什么，应该由运行环境决定

OpenShell 不是模型，也不是编程助手，而是承载 agent 的运行时。你继续使用编程助手，它负责在助手访问文件、执行命令和连接网络时执行规则。

按原文引用的文档，每个 agent 在独立沙箱中运行，文件访问和系统调用受到内核机制约束，网络连接离开沙箱前也要经过策略检查。提示词里的「不要读取密钥」只是一条指令；运行环境拒绝读取，才是一道权限边界。

凭据处理是另一个重点。文档称 agent 不接触真实 credential，由 OpenShell 只向获准目的地的请求注入凭据。这样可以减少 agent 把密钥写进代码、日志或外发内容的机会。

但隐藏密钥不等于消除泄漏。项目自己的安全说明也提醒：每个获准访问的目的地，都可能成为数据外流通道。如果 agent 被提示词注入（prompt injection）诱导，仍可能滥用已有权限。

沙箱限制的是出错后的影响范围，不能保证 agent 不会出错。

这对同一台机器上同时放着项目代码、客户资料和 API 密钥的开发者尤其相关。不过，是否覆盖某个助手的完整执行流程，还要看具体接入方式，原文没有给出 Claude Code 或 Codex 的完整配置示例。

一份 YAML，实际要回答哪些权限问题

OpenShell 的策略文件使用 YAML，原文将它分为五部分。

filesystem_policy 定义哪些路径可读、哪些可读写，通过 Linux 内核安全机制 Landlock 执行。单独的 landlock 部分则决定：文件系统规则无法实施时，沙箱是否还允许启动。后者直接关系到隔离条件不足时如何处理，不能当作普通兼容性选项。

process 指定进程使用的用户和组，在通过 Docker 或 Podman 创建沙箱时锁定。network_policies 规定各个二进制程序能访问什么目的地、发送什么请求，默认拒绝全部出站连接，再按规则放行。

第五部分处理已经获准的流量，可以检查、转换或阻断请求。原文没有写出这一部分的配置字段名，但给出了用途：允许读取 API，同时禁止写入，或者在数据外发前进行过滤。

这里最有价值的思路，是把「能联网」拆成更细的问题：哪个程序、连接哪里、能做什么操作。给 agent 一个宽泛的网络开关，通常不足以表达团队真正想授予的权限。

策略更新也有一道检查。按文档描述，新策略生效前会经过形式化证明（formal verification），识别新增带凭据的主机访问、开放新的 API 方法等风险，并将风险项挂起，等待人工审核。

所谓形式化证明，是按明确的规则和模型检查性质，不是让另一个模型读一遍 YAML。它也只覆盖证明器检查的内容，不能证明策略已经足够收敛，更不能证明所有获准操作都符合业务意图。

能装起来，离团队可用还有多远

系统由 gateway、supervisor 和沙箱组成：gateway 管理沙箱、策略与访问权限，supervisor 负责监督，实际任务在沙箱中执行。已有 Kubernetes 的团队可以通过 Helm chart 安装 gateway，但需要支持执行 NetworkPolicy 的 CNI。

原文给出的入门命令用于安装工具并创建一个演示沙箱：

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

要注意第二行只创建沙箱；默认镜像是精简 Ubuntu，没有预装 agent。文档另有 OpenCode 配合 OpenRouter 免费模型的教程，并展示新增访问权限的审批过程。

项目提供 Python、TypeScript、Go、Rust SDK，Python 包已发布到 PyPI，可通过 pip 或 uv 安装。还提供公共 skill，让 coding agent 操作 CLI、编写策略和调试 gateway。这能减少手写 YAML 的工作，但生成策略与批准权限仍是两件事。

环境要求也不算轻：需要 Docker、Podman 或可在宿主机运行的虚拟化环境。原文列出的平台包括 Linux、Apple Silicon 上的 macOS，以及处于实验状态的 Windows WSL 2。Windows 原生路线使用 Microsoft MXC，覆盖 x64 和 ARM64，但仍在开发，尚未达到生产安全要求。

还有两个会直接影响落地的细节。第一，镜像中的策略文件无效时，工作负载不会启动，必须先修复。第二，匿名 telemetry 默认开启；文档称不采集沙箱名、主机名、文件路径、prompt 和 credential，可在 gateway 设置 OPENSHELL_TELEMETRY_ENABLED=false，或通过 Helm 配置关闭。

这些行为需要进入团队的配置和排障流程，安装命令跑通只是起点。

我的判断

我认同它把权限约束放在执行环境里的方向。尤其是凭据注入、默认拒绝出站连接和按路径授权，比仅靠提示词要求助手自律更有约束力。相较于只把 agent 放进一个普通容器，这套方案进一步表达了文件、网络请求和凭据的使用边界；实际隔离效果仍取决于策略与运行环境。

但原文没有充分证明它已经适合普遍推广。作者主要查阅文档，没有给出沙箱开销、安装成功率、策略维护成本，或提示词注入防护的对照数据。「更敢放手让 agent 工作」是合理期待，目前仍是判断。

项目状态也应按时间快照理解。截至作者核查的 2026 年 10 月 27 日，仓库有 20,191 个 star、1,988 次 fork；创建于 2026 年 2 月 24 日，核查当天仍有更新。文档版本为 v0.1.5，采用 Apache 2.0 许可证，并提供旧版本升级指南。

约 390 个开放 issue 加上约 210 个开放 PR，构成页面显示的约 600 项。这个数字不能单独证明质量好坏，star 数也不能替代安全审查。

此外，原文披露文章由 Hermes Agent 调用 ollama-cloud 提供的 deepseek-v4.1-flash 生成，再由 Nokka 人工监督和质检。因此，文中的安全能力应理解为对项目文档的转述，不能当作独立验证结论。

能拿来做什么

• 先盘点日常 AI 编程任务的必要权限：允许读写哪些目录、安装依赖需要访问哪里、哪些 API 只需读取。用这些具体需求检查策略，避免直接开放整个项目目录和全部网络。
• 试用时从不含真实密钥的前端或 Node 项目开始，完整跑一次读取代码、修改文件、安装依赖和执行构建，记录哪些操作被拒绝，以及放行是否符合预期。
• 将策略变更纳入代码审查，重点检查新增路径、目的地、凭据和 API 方法；让 agent 帮忙写 YAML，也仍需有人判断授权是否必要。
• 用自己的任务测量耗时、失败率和权限审批次数，再决定是否扩大使用。原文没有性能数字，这部分只能由团队补齐。