NVIDIA OpenShell 0.1.0：为 AI 智能体添加可强制执行的运行时控制

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 的运行时层，该平台将保护扩展到应用层、运行时层和基础设施层。

视频 1. 如何设置你的自主长时运行智能体的操作演示

组织如何采用 OpenShell

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

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

OpenShell 能力

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

表 1. OpenShell 0.1.0 中引入的新能力

在智能体之外强制执行权限

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

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

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

图 1. OpenShell 管理智能体沙箱。外部 supervisor 将出站通信限制为已配置的服务

OpenShell 沙箱运行时使用操作系统内核控制来限制工作负载可以读取或更改哪些文件，并防止其获取额外的系统权限。对于网络访问，你可以比仅允许连接到某个服务更加具体。supervisor 可以检查配置的 HTTP、GraphQL 和模型上下文协议（MCP）流量，允许数据查询，同时阻止通过同一 API 进行的写入。当智能体启动 shell、运行生成的代码、启动子进程或提议将任务委托给子智能体时，这些控制仍然有效。OpenShell 将策略决策记录在开放网络安全模式框架（OCSF）审计跟踪中。当它阻止被检查的请求时，可以返回描述性错误，帮助智能体决定下一步该做什么。

观察策略决策的发生

此示例使用 curl 和 GitHub REST API 中的未认证端点，使每个策略决策都可见，而无需 API 密钥或语言模型。当智能体发出请求时，同样的控制也适用。

使用安装指南安装并启动 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 工作负载之外。

图 2. 真实凭据在 agent 工作负载之外被替换，且仅针对已授权的端点。网络访问和凭据绑定必须同时允许该请求

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

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

提供商配置文件定义了某个服务的凭据、端点和允许的程序。假设一个名为 github 的 GitHub 提供商

已完成配置，将其附加到新的沙箱并启动 Codex。

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

在智能体运行期间调整网络访问

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

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

使用以下命令为沙箱启用策略顾问。

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

验证策略授予的权限

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

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

在长视野对抗性实验中，具有减少保障措施的前沿代理花费长达两小时试图说服 AI 审查员授予权限，以允许它们修改受保护的 GitHub 仓库。OpenShell 的形式化策略分析为审查员提供了这些权限允许内容的证据，即使代理试图操纵审查员。结合审查和运行时控制允许了有用的访问，并且在这些测试中没有发生受保护仓库的写入。

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

本地构建并部署到共享基础设施

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

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

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

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