OpenShell：用内核隔离和策略验证管控自主智能体
给自主智能体用的安全运行时，靠内核隔离和策略验证限制文件、网络与凭据访问。
GitHub NVIDIA/OpenShell 更新 2026-09-30 分支 main 星标 10.6K 分叉 1.4K
Rust Go 自主AI智能体安全 Kernel-level enforcement Kubernetes Linux/macOS Apple Silicon

🧭 决策指南

为什么现在热： 无法从材料判断 2026-09-30 当日新增 990 颗星的具体原因；可确认 README 在 OpenShell 0.1.x 发布信息中强调了稳定发布节奏、新隔离原语、扩展接口和新 API，仓库当日总星数为 10,615。

适合，如果你

  • 你要让 OpenCode 访问文件、安装包和 API，但不想开放整个主机网络。
    README 的 How It Works 和 Run Your First Agent：OpenShell 为智能体声明并执行文件、系统调用和网络策略。
  • 你的团队需要在批准策略前审查新增主机凭据访问或 API 方法。
    README 的 Formally verified policy changes：形式化验证会标记这类新增访问并等待人工审查。
  • 你运行 Kubernetes，并能让 CNI 强制执行 NetworkPolicy。
    README 的 Kubernetes：通过 Helm 部署 gateway，且 CNI must enforce NetworkPolicy。

不适合，如果你

  • 你的环境不是 Linux、Apple Silicon macOS 或 Windows WSL 2，也没有 README 所列的 Docker、Podman 或主机虚拟化。
    README 的 Quickstart 只列出这些操作系统和运行后端。
  • 你需要开箱即用的智能体，而不能接受默认 sandbox 只有最小 Ubuntu 且没有 agent。
    README 的 Quickstart 明确说明默认 sandbox image is minimal Ubuntu with no agent installed。
  • 你的 Kubernetes CNI 无法强制执行 NetworkPolicy。
    README 的 Kubernetes 明确要求 Your CNI must enforce NetworkPolicy。

前置条件

  • 需要 Linux、Apple Silicon 上的 macOS，或实验性的 Windows WSL 2。
  • 需要 Docker、Podman 或 host virtualization。
  • Kubernetes 部署使用 Helm，且 CNI 必须强制执行 NetworkPolicy。
  • SDK 与 gateway 尽可能使用同一个 OpenShell release。
  • 项目提供 Rust、Go、Python 和 TypeScript SDK；TypeScript SDK 使用 GitHub Packages。

第一步命令（README 原文）

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

要注意

  • 安装脚本会设置 CLI 和本地 gateway，但不会在默认 sandbox 安装 agent。
    README 的 Quickstart：The installer sets up the CLI and a local gateway；默认镜像没有 agent。
  • Windows 路径仍标注为 experimental，不能按稳定平台支持理解。
    README 的 Quickstart：Windows with WSL 2 (experimental)。
  • 若不关闭遥测，gateway 会收集匿名 operational categories and counts。
    README 的 Telemetry；可设置 OPENSHELL_TELEMETRY_ENABLED=false 或 Helm 的 server.telemetryEnabled=false。
  • SDK 不会安装 CLI，且 Rust 安装命令中的 --tag 参数在 README 代码行中为空。
    README 的 SDKs：SDKs do not install the CLI；Rust 行为 cargo add openshell-sdk --git https://github.com/NVIDIA/OpenShell --tag 。

材料未说明

  • README 未给出 sandbox 的具体资源开销、并发上限或智能体数量上限。
  • README 未说明 kernel-level enforcement 覆盖的具体 Linux kernel 版本范围。
  • README 未量化形式化验证的耗时、支持的策略语言或误报情况。
  • README 未说明 Docker、Podman 与 host virtualization 各自的功能差异。
  • README 未提供 OpenCode、OpenRouter free model 的具体模型名称或稳定性数据。
  • README 未给出 Kubernetes gateway 的高可用、升级和故障恢复方案。
  • README 未说明 10 位贡献者和 5 个版本对应的发布节奏是否足以支持生产部署。
  • README 未说明 Apache License 2.0 与外部 retrieved materials 条款在具体业务中的合规边界。

💡 深度解析

6
适合 我维护 Python 和 TypeScript 应用，希望通过 SDK 连接 OpenShell 网关、把代理运行能力嵌入现有服务，而不是在应用进程里安装 CLI；这个集成路径是否可行？
适合读者： 维护 Python 和 TypeScript 应用的 AI 平台工程师，需要通过 SDK 接入 OpenShell 网关而不依赖 CLI

适合，README 明确把 SDK 定义为连接 OpenShell 网关的应用接口，并提供 Python 与 TypeScript 安装方式；但 SDK 不会替你安装 CLI。

  • SDKs 章节列出 Python 的 uv add openshell 和 TypeScript 的 npm install @nvidia/openshell-sdk，说明两种语言都有直接集成入口。
  • README 明确写着 “SDKs connect applications to an OpenShell gateway. They do not install the CLI.”，所以应用可以承担控制调用，但网关仍需独立部署。
  • 项目还提供 Go 和 Rust SDK，且建议 SDK 与网关尽量使用同一 OpenShell release，版本配对是集成条件。
  • TypeScript 包来自 GitHub Packages；这意味着构建环境需要处理该包源的访问与认证。

因此它适合已有 Python 或 TypeScript 服务的嵌入式集成，不适合把 SDK 当成完全自包含的本地代理运行器。

  • SDKs: “SDKs connect applications to an OpenShell gateway. They do not install the CLI.”
  • SDKs: Python `uv add openshell`
  • SDKs: TypeScript `npm install @nvidia/openshell-sdk` (GitHub Packages)
  • SDKs: “Use the same OpenShell release for the SDK and the gateway when possible.”
材料未说明：README 未说明 Python 与 TypeScript SDK 的 API 覆盖范围、认证方式、异步模型和连接故障处理行为。；README 未说明 GitHub Packages 所需的具体令牌权限或企业代理配置。
适合 我需要让自主代理调用获批的外部 API 和 inference provider，但不能把通用云密钥放进沙箱；OpenShell 的凭据和策略模型是否满足这个约束？
适合读者： 企业安全工程师，需要让代理访问获批 API 和推理服务，但禁止暴露通用云密钥

适合，因为 OpenShell 将凭据绑定到获批端点，并在策略变更时识别新增主机、凭据和 API 方法；这正对应“可调用服务但不暴露通用密钥”的约束。

  • How It Works 写明代理不会看到真实凭据，OpenShell 只把凭据加入绑定到 approved endpoints 的请求。
  • Providers 章节说明凭据只能在获批端点工作，且 inference 也纳入 provider 配置，适合统一治理模型访问。
  • 策略变更会经过形式化验证，若新增带凭据访问的新主机或 API 方法，会等待人工复核。
  • 这种机制限制的是 OpenShell 管理的请求路径，不等于外部服务、恶意依赖或业务授权本身已经安全。

所以它适合作为凭据代理和出口控制层，但不能替代企业身份治理、数据分类、供应链扫描或外部 API 的业务级权限。

  • How It Works: “Agents never see real credentials; OpenShell adds them only to requests bound for approved endpoints.”
  • Explore Further / Providers: “credentials that work only at approved endpoints, including inference”
  • How It Works: “flag risky new access ... reaching a new host with credentials or calling a new API method”
材料未说明：README 未说明支持哪些具体云厂商、认证协议、凭据轮换机制和短期令牌生命周期。；README 未说明请求重定向、DNS、代理服务或 API 网关场景下端点绑定的具体边界。
适合 我在 Apple Silicon macOS 上用 OpenCode，并需要代理安装软件包、读取项目文件和访问代码仓库；OpenShell 是否适合在不把宿主机和凭据全部暴露给代理的情况下运行它？
适合读者： 在 Apple Silicon macOS 上运行 OpenCode、需要让编码代理安装依赖并访问代码仓库的个人开发者

适合，因为它在支持的本地环境中提供了沙箱、文件策略、网络策略和端点绑定凭据，而不是把权限全部交给代理。

  • README 的 Quickstart 明确支持 Apple Silicon macOS，并要求 Docker、Podman 或主机虚拟化。
  • 每个代理运行在独立沙箱中；内核控制文件访问和系统调用，网络连接离开沙箱前也要经过策略检查。
  • 代理不会看到真实凭据，OpenShell 只会把凭据加入发往获批端点的请求。
  • 默认沙箱镜像是没有代理的最小 Ubuntu，运行 OpenCode 需要按“Run Your First Agent”配置代理和访问权限。

因此它能覆盖这个本地编码场景，但 README 没有说明 OpenCode 所需的具体目录、包管理器和代码托管端点策略，也没有证明所有 Apple Silicon 虚拟化组合都具备相同性能。

  • Quickstart: “You need Linux, macOS on Apple Silicon, or Windows with WSL 2 (experimental)”
  • How It Works: “Each agent runs in an isolated sandbox”
  • How It Works: “Agents never see real credentials”
  • Quickstart: “The default sandbox image is minimal Ubuntu with no agent installed”
openshell sandbox create --name demo
材料未说明：README 未列出 OpenCode 需要开放的具体文件路径、包管理器和代码仓库域名。；README 未给出 Apple Silicon 上不同 Docker、Podman 或主机虚拟化后端的性能与兼容性差异。
视情况 我需要在 Kubernetes 中通过 Helm 部署 OpenShell 网关，管理多个代理沙箱，并依赖现有 CNI 强制执行 NetworkPolicy；在什么条件下它适合作为平台运行时？
适合读者： 负责 Kubernetes 平台的 DevSecOps 工程师，需要通过 Helm 管理多个代理网关，并依赖 CNI 执行 NetworkPolicy

视情况，只有当集群的 CNI 确实执行 NetworkPolicy、团队能承担网关与策略运维，并接受 0.1.x 仍在演进时才适合。

  • README 的 Kubernetes 章节支持用 Helm 部署网关，但明确要求 CNI 必须强制执行 NetworkPolicy；仅提交策略对象并不等于网络隔离生效。
  • 网关是沙箱、策略和访问的控制平面，适合集中管理多个代理，而不是只启动一个容器。
  • README 同时提供沙箱镜像、运行时、GPU 和生命周期管理入口，说明平台需要处理计算资源与代理运行状态。
  • 项目数据将最新发布标记为 dev，README 还强调 0.1.x 带来新 API 和隔离原语，因此接口与策略语义的稳定性仍需核验。

如果 CNI 行为、节点权限或版本兼容性无法确认，不能把 OpenShell 的网络治理承诺直接等同于集群整体安全边界。

  • Explore Further / Kubernetes: “deploy the gateway with Helm. Your CNI must enforce `NetworkPolicy`”
  • Explore Further / Gateways: “the control plane for sandboxes, policy, and access”
  • Explore Further / Sandboxes: “images, runtimes, GPUs, and lifecycle”
  • 项目数据：latest_release 为 `dev`；README： “New in OpenShell 0.1.x ... new APIs”
材料未说明：README 未说明支持哪些具体 CNI、Kubernetes 版本、节点运行时和 GPU 插件组合。；README 未给出多网关、高可用、升级回滚或大规模沙箱数量的容量数据。
视情况 我需要同时维护 OpenShell 网关、Python SDK 和多个仍在开发中的组件；考虑到项目最新发布标记为 dev，我是否适合现在把它作为生产代理平台的基础依赖？
适合读者： 负责代理平台版本治理的基础设施工程师，需要同时维护 OpenShell 网关、Python SDK 和多个开发版组件

视情况，项目具备生产治理所需的架构能力，但当前发布状态和版本配对要求使它不适合未经验证就承担高关键生产负载。

  • 项目数据表明最新发布为 dev，发布数量为 5；README 又强调 0.1.x 引入新隔离原语、扩展面和新 API，说明接口仍可能快速演进。
  • SDKs 章节建议 SDK 与网关尽量使用同一 OpenShell release，网关、SDK 和 CLI 混用版本会带来兼容性风险。
  • 项目提供正式的网关、沙箱、策略、provider 和 Kubernetes 入口，能力范围足以支撑平台化集成，而不只是实验性容器启动器。
  • README 还提供 prerelease 和 development builds，表明开发版是明确支持的试用路径，但不是稳定性承诺。

因此，若团队能维护版本矩阵、验证升级和处理策略兼容性，可以作为受控平台依赖；若要求稳定 API、长期支持和低运维投入，则当前证据不足。

  • 项目数据：latest_release 为 `dev`；release_count 为 5
  • README 重要提示： “New in OpenShell 0.1.x: ... new APIs”
  • SDKs： “Use the same OpenShell release for the SDK and the gateway when possible.”
  • Explore Further： “Prerelease and development builds”
材料未说明：README 未提供各版本的支持周期、向后兼容承诺、升级回滚方案或生产 SLA。；README 未给出网关、SDK、CLI 和策略格式之间的完整兼容矩阵。
视情况 我在 Linux 上运行自动化运维代理，需要开放部分文件、安装软件包并使用 GPU；OpenShell 是否能在保留这些能力的同时提供足够的隔离？
适合读者： 需要在 Linux 上运行自动化运维代理、允许其读取部分主机文件并使用 GPU 的平台工程师

视情况，OpenShell 能控制文件、系统调用、网络和沙箱资源，但一旦代理需要主机文件、GPU 或高权限系统资源，隔离边界和运维复杂度都会明显上升。

  • Quickstart 支持 Linux，并要求 Docker、Podman 或主机虚拟化，具备本地运行基础。
  • How It Works 说明内核级控制会限制文件访问和系统调用，网络连接也要经过策略检查。
  • Sandboxes 章节明确覆盖 images、runtimes、GPUs 和 lifecycle，说明 GPU 是设计中的资源类型，而不是 README 未涉及的场景。
  • 项目洞察指出，真实文件、内网服务、GPU 或高权限资源会使隔离边界更复杂；沙箱也不能替代宿主机、内核、镜像和运行时加固。

因此，若任务可以限定文件范围和资源权限，它有匹配度；若代理必须广泛访问主机或高权限接口，README 没有足够证据证明隔离风险可接受。

  • Quickstart: “You need Linux ... plus Docker, Podman, or host virtualization.”
  • How It Works: “Kernel controls confine which files it can access and which system calls it can make”
  • Explore Further / Sandboxes: “images, runtimes, GPUs, and lifecycle”
  • 项目洞察 / usage_limitations：访问真实文件、GPU 或高权限系统资源时，隔离边界会变复杂
openshell sandbox create --name demo
材料未说明：README 未说明 GPU 直通所需的具体驱动、容器运行时、设备策略和隔离强度。；README 未说明运维代理所需的主机文件挂载方式、系统调用清单和性能开销。

✨ 核心亮点

  • 内核级隔离控制文件、系统调用与网络连接
  • 形式化验证策略变更并标记新增主机访问
  • 凭据仅注入批准端点的请求
  • Kubernetes 部署要求 CNI 强制 NetworkPolicy

🔧 工程化

  • 用 sandbox、policy 和 gateway 组成智能体运行时
  • 支持 OpenCode、OpenRouter 模型与多语言 SDK
  • 通过 advisor 与 prover 审查文件、网络和进程规则

⚠️ 风险

  • Windows 支持依赖实验性的 WSL 2
  • 默认 sandbox 是无智能体的最小 Ubuntu 镜像
  • 网关会收集匿名运行类别和计数遥测
  • 外部材料须由用户自行审查许可与安全性

👥 适合谁？

  • 需要约束自主智能体文件、API 和凭据访问的团队
  • 运行 Linux、Apple Silicon macOS 或 WSL 2 的开发者
  • 使用 Kubernetes、Helm 和 NetworkPolicy 的平台团队