NVIDIA 发布开源运行时 OpenShell，为 AI Agent 提供权限管控与安全沙箱

AI 智能体可以被赋予一个目标，编写代码、使用工具，并在新信息出现时持续工作。这为那些调查软件故障、运行实验，以及跨越数天或数周执行关键业务操作和研究的应用打开了大门。

有用的智能体需要访问工作区、计算资源、数据、凭据和外部服务。但更广泛的访问权限也会带来更严重的故障模式，从更改生产数据或泄露机密信息，到超出所分配任务范围行事。

NVIDIA OpenShell 0.1.0 是一个开源运行时，用于定义并强制执行智能体可以访问哪些系统和数据。它结合了沙箱化执行、受控服务访问、凭据管理和形式化策略分析。团队可以授予智能体任务所需的能力，同时由 OpenShell 在工作负载之外强制执行这些权限。

它支持 Codex、Claude Code、Pi、Hermes 以及未来的框架，覆盖企业应用、前沿研究和物理 AI——从内部智能体集群和长周期研究，到机器人和边缘系统。

本文展示 NVIDIA OpenShell 0.1.0 如何在不重写现有 AI 智能体的情况下，围绕它放置可强制执行的运行时控制，使团队能够限制 API 操作、保护凭据，并在智能体工作负载之外审查权限变更。

OpenShell 提供更广泛的 NVIDIA Open Agent Safety Platform 的运行时层，该平台将保护扩展到应用层、运行时层和基础设施层。

组织如何采用 OpenShell

OpenShell 是开源的，可供企业在广泛的合作伙伴生态系统中采用，这也塑造了产品本身。各组织正在一系列应用中采用 OpenShell，包括芯片设计、企业自动化、加速计算和物理 AI。

• Cadence 将 OpenShell 用于芯片设计，与其 ChipStack Autonomous RTL Design Engineer 配合使用。 
• Slack 正在 OpenShell 上构建一个按需智能体平台，以实现任务自动化。
• Gecko Robotics 使用 OpenShell 来治理在物理机器人上做出决策的智能体。 

OpenShell 能力

OpenShell 0.1.0 支持沙箱操作、策略验证、治理集成、凭据保护和灵活计算。

在 agent 外部强制执行权限

Agent 可以解读指令、选择工具，并随时间推移演进其方法。OpenShell 在保持这种灵活性的同时，在 agent 工作负载之外强制执行权限。

OpenShell 可以管理 agent 集群及其沙箱，每个沙箱都有自己的权限，并支持一次对多个组进行治理。三个组件提供了这种控制能力：

• OpenShell Gateway：管理众多沙箱的生命周期和策略。
• OpenShell Supervisor：与每个沙箱配对，运行在 agent 工作负载之外，并根据策略检查出站请求。
• OpenShell Sandbox：运行工作负载，对其文件系统和进程施加内核级控制，并且除通过 supervisor 之外没有任何网络路径。

OpenShell 沙箱运行时使用操作系统内核控制来限制工作负载可以读取或更改哪些文件，并防止其获取额外的系统权限。对于网络访问，你可以比仅允许连接到某个服务更加精细。Supervisor 可以检查已配置的 HTTP、GraphQL 和 Model Context Protocol (MCP) 流量，允许数据查询的同时阻止通过同一 API 进行的写入。当 agent 启动 shell、运行生成的代码、启动子进程或提议将任务委派给子 agent 时，这些控制依然有效。OpenShell 将策略决策记录在 Open Cybersecurity Schema Framework (OCSF) 审计跟踪中。当它阻止某个被检查的请求时，可以返回描述性错误，帮助 agent 决定下一步该怎么做。

观察一次策略决策的发生

本示例使用 curl 和 GitHub REST API 中一个无需身份验证的端点，使每次策略决策都可见，而无需 API 密钥或语言模型。当 agent 发出请求时，同样的控制也会生效。

按照安装指南安装并启动 OpenShell 0.1.0。然后将随附的 no-network.yaml 和 github-readonly.yaml 策略文件下载到 examples 目录中。

首先，创建一个没有出站网络访问权限的沙箱：

openshell sandbox create --name policy-demo \
  --no-auto-providers \
  --policy examples/no-network.yaml

create 命令会在沙箱内打开一个 shell。尝试读取一个公共端点：

curl -sS --max-time 10 https://api.github.com/zen

该请求失败，因为沙箱没有出站网络权限。在你的主机上打开第二个终端并检查日志，以查看是哪个程序发出了请求以及为什么被阻止：

openshell logs policy-demo --since 5m

接下来，将沙箱策略替换为允许对 GitHub REST API 进行只读访问的策略。策略使用 YAML 编写并编译为 OPA/Rego，OpenShell 会对每个出站请求对其进行求值。

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

此规则允许 /usr/bin/curl 在端口 443 上访问 GitHub API。借助 protocol: rest，OpenShell 会检查 HTTP 请求，允许读取而阻止写入。

在你的主机终端中，应用完整的替换策略，而无需重启沙箱：

openshell policy set policy-demo \
  --policy examples/github-readonly.yaml --wait

返回沙箱 shell 并尝试这两个请求：

# Read: allowed
curl -sS --max-time 10 https://api.github.com/zen

# Write: blocked
curl -sS --max-time 10 -X POST https://api.github.com/zen

再次检查主机日志，以确认 OpenShell 阻止了 POST。运行这些命令的 agent 会遇到相同的限制。

在不暴露凭据的情况下访问服务

许多 agent 需要模型 API 或私有服务才能完成任务。OpenShell 在授权此类访问的同时，将真实凭据保留在 agent 工作负载之外。

对一个服务的授权并不会使该凭证可用于另一个服务。如果 agent 将占位符发送到该凭证已批准端点之外的目的地，OpenShell 会拒绝该请求。

接收服务仍会强制执行附加在真实凭证上的权限。OpenShell 额外增加了一层对 agent 如何使用该凭证的控制。例如，一项经过检查的只读 API 策略可以阻止写入请求，即使该凭证本身具有写入权限。

提供方配置文件定义了一个服务的凭证、端点和允许的程序。假设一个名为 github 的 GitHub 提供方已配置好，将其附加到一个新的沙箱并启动 Codex。

openshell sandbox create \
  --provider github \
  -- codex

在 agent 运行时调整网络访问

agent 可能会发现它需要某个在任务开始时未知的服务或数据源。当策略阻止该请求时，OpenShell 会记录该拒绝，以便操作员或 AI agent 审批者进行审查。启用 policy advisor 后，agent 可以提出范围狭窄的网络或文件策略变更。该提议默认保持待人工审查状态，且 agent 无法批准自己的请求。批准后，OpenShell 会将新规则加载到正在运行的沙箱中，使 agent 无需重启其工作即可重试。

文件系统和进程限制在沙箱启动时即已确立。更改这些控制需要新建一个沙箱。

使用以下命令为沙箱启用 policy advisor。

openshell settings set <sandbox-name> \
  --key agent_policy_proposals_enabled \
  --value true

验证策略授予的权限

一项策略可能看起来具有限制性，却仍留有另一条路径。如果另一个被允许的工具或生成的代码可以使用凭证进行同样的写入，那么通过一个工具阻止 GitHub 写入就无济于事。

OpenShell 策略证明器使用形式逻辑来检查策略授予的权限，包括提供方贡献的访问权限。它可以证明建模的权限仍处于操作员定义的边界之内，或识别出跨越该边界的具体操作。由于结果来自策略模型，agent 的解释无法改变该结果。链接的形式化方法入门详细介绍了其工作原理。

在长时程对抗性实验中，防护措施被削弱的前沿 agent 花费长达两小时试图说服 AI 审查者授予权限，以便修改受保护的 GitHub 仓库。OpenShell 的形式化策略分析为审查者提供了这些权限允许哪些操作的证据，即使 agent 试图操纵审查者。审查与运行时控制的结合允许了有用的访问，且在这些测试中未发生对受保护仓库的写入。

正在进行的工作将策略分析扩展到多个 agent，其中一个 agent 的访问权限可能与另一个的相结合。目标是检查它们共同构成的系统的权限。有关支持的检查，请参阅证明器文档。

在构建应用程序并定义其权限时，先从本地沙箱开始。要为多个用户提供服务，请遵循工作区与访问指南，并使用 SDK 创建和管理沙箱。每个工作负载都有自己的策略和附加的提供程序。

沙箱外部的可信中间件可以连接身份服务，并在请求路径中添加特定于应用程序的检查。计算驱动程序将 OpenShell 连接到 Docker、Podman、MicroVM 和 Kubernetes；支持矩阵涵盖了当前的要求。

加入 CNCF Slack 上的 #openshell-dev，提出问题、分享反馈，并与其他基于 OpenShell 构建的团队和开发者交流。在 GitHub 上探索代码并做出贡献，并在 OpenShell 开发笔记中关注正在进行的研究和工程工作。如果你要升级现有部署，请参阅 0.1.0 迁移说明。

准备好开始构建了吗？从快速入门开始，使用 OpenShell 运行你自己的代理，并配置它可以访问的服务。