AI 智能体能够在获得既定目标后编写代码、调用工具，并随着新信息不断出现而持续开展工作。这为应用程序带来了广阔空间，使其能够调查软件故障、运行实验，并在数天乃至数周内持续执行关键业务操作和研究任务。
实用的智能体需要访问工作区、计算资源、数据、凭证和外部服务。然而，权限扩大也会带来后果更为严重的故障风险，例如更改生产数据、泄露机密信息，或执行超出分配任务范围的操作。
NVIDIA OpenShell 0.1.0 是一个开源运行时，用于定义并强制执行智能体可访问的系统和数据范围。它集沙盒执行、受控服务访问、凭证管理和形式化策略分析于一体。团队可授予智能体完成任务所需的能力，同时由 OpenShell 在工作负载之外强制执行相应权限。
它支持 Codex、Claude Code、Pi、Hermes 及未来横跨企业应用程序、前沿研究和物理 AI 的各种框架 —— 适用于从内部智能体集群、长周期研究到机器人和边缘系统场景。
本文介绍 NVIDIA OpenShell 0.1.0 如何在无需重写现有 AI 智能体的情况下，为其设置可强制执行的运行时管控，帮助团队在智能体工作负载之外限制 API 操作、保护凭证，并审查权限变更。
OpenShell 为更广泛的 NVIDIA 开放智能体安全平台提供运行时层，并将安全防护扩展至应用程序、运行时和基础设施层。
组织如何采用 OpenShell
OpenShell 是开源的并可供广泛的合作伙伴生态系统供企业采用，这也塑造了产品本身。目前，各类组织正将 OpenShell 应用于涵盖芯片设计、企业自动化、加速计算和物理 AI 的多种场景。
- Cadence 在其 ChipStackAutonomous RTL Design Engineer 中采用 OpenShell 进行芯片设计。
- Slack 正基于 OpenShell 构建按需智能体平台，以实现任务自动化。
- Gecko Robotics 使用 OpenShell治理在实体机器人上执行决策的智能体。
OpenShell 功能
OpenShell 0.1.0 支持沙盒操作、策略验证、治理集成、凭证保护及灵活计算。
| 功能 | 如何提供帮助 |
| 多租户平台支持 | 在共享基础设施上，借助独立的工作区、权限和服务访问，为多个团队或客户运行智能体服务。 |
| 形式化策略验证 | 帮助人工和 AI 审查者判断所请求的权限是否处于既定安全边界内，并识别越界之处。 |
| 可扩展的安全与治理 | 将第三方安全服务、治理系统和自定义检查集成至位于智能体工作负载之外的强制执行机制中。 |
| 受凭证保护的服务访问 | 使用经过身份验证的服务，同时确保真实凭证始终处于智能体工作负载之外，并仅绑定至获授权的请求。 |
| CPU 和 GPU 执行 | 跨容器、虚拟机和 Kubernetes 环境的 CPU 或 GPU 运行实验并处理数据。 |
表 1：OpenShell 0.1.0 引入的新功能
在智能体之外强制实施权限
智能体能够理解指令、选择工具，并随时间推移不断优化其工作方法。OpenShell 在保留这种灵活性的同时，可在智能体工作负载之外实施权限管控。
OpenShell 能够管理智能体集群及其各自拥有独立权限的沙盒，并支持跨群组的同步治理。这一管控能力由以下三个组件提供：
- OpenShell 网关：管理众多沙盒的生命周期和策略。
- OpenShell 监督器：每个沙盒均配有一个监督器；该监督器独立于智能体工作负载运行，并依据策略检查出站请求。
- OpenShell 沙盒：运行工作负载，对其文件系统和进程进行内核级机制管控，并且不提供除经由监督器外的任何网络路径。
OpenShell 沙盒运行时借助操作系统内核管控机制，限制工作负载可读取或更改的文件，并防止其获取额外的系统特权。对于网络访问，您可以进行比简单地允许连接某项服务实现更具体的管控。监督器可检查已配置的 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 请求。运行这些命令的智能体会受到同样的限制。
在不暴露凭证的情况下访问服务
许多智能体需要访问模型 API 或私有服务才能完成任务。OpenShell 可对此类访问进行授权，同时确保真实凭证始终处于智能体工作负载之外。
对某项服务的授权不会使其凭证可供其他服务使用。如果智能体将占位符发送至该凭证获批端点之外的目标，OpenShell 将拒绝该请求。
接收服务仍会强制执行真实凭证所附带的权限。OpenShell 则添加了独立的管控机制，用于管理智能体对凭证的使用方式。例如，即使凭证本身拥有写入权限，经过检查的只读 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 策略证明器采用形式化逻辑检查策略授予的权限，包括提供商授予的访问权限。它能够证明建模后的权限始终处于运行人员定义的边界内，或识别出越界的具体操作。由于结果来自策略模型，智能体给出的解释无法改变这一结果。相关形式化方法入门指南详细介绍了其工作原理。
在长周期对抗性实验中，安全防护措施被削弱的前沿智能体在长达 2 小时内试图说服 AI 审查者授予权限，以便修改受保护的 GitHub 代码仓库。即使智能体试图操纵审查者，OpenShell 的形式化策略分析仍能为审查者提供相关证据，明确说明这些权限允许执行的操作。通过结合审查机制与运行时管控，智能体仍可获得具有实际用途的访问权限，这些测试均未对受保护的代码仓库执行写入操作。
目前，相关工作正在将策略分析扩展至多智能体场景。在该场景下，一个智能体的访问权限可与另一个智能体的访问权限相结合，目标是检查它们共同组成的系统权限。如需了解支持的检查类型，请参阅证明器文档。
在本地构建并部署至共享基础设施
在构建应用程序并定义其权限时，可先从本地沙盒入手。如需为多个用户提供服务，请遵循工作区和访问指南，并使用 SDK 创建和管理沙盒。每个工作负载均拥有独立的策略和关联的提供商。
沙盒外的可信中间件可连接身份服务，并在请求路径中添加应用程序专属检查。计算驱动程序可将 OpenShell 连接到 Docker、Podman、MicroVM 和 Kubernetes；支持矩阵涵盖了当前的要求。
欢迎加入 CNCF Slack 上的 #openshell-dev 频道，提出问题、分享反馈，并与基于 OpenShell 开展构建工作的其他团队和开发者建立联系。您也可前往 GitHub 浏览代码并参与贡献，同时通过 OpenShell 开发说明了解持续推进的研究与工程工作。如需升级现有部署，请参阅 0.1.0 迁移说明。
准备开始构建？请先参阅快速入门指南，使用 OpenShell 运行您自己的智能体，并为其配置可访问的服务。
