AI智能体可以被赋予一个目标，随后自行编写代码、调用工具，并根据新出现的信息持续推进任务。这为一系列应用打开了空间，比如排查软件故障、执行实验、以及在数天或数周内完成对业务至关重要的操作与研究。
要发挥实际作用，智能体需要访问工作空间、计算资源、数据、凭证以及外部服务。但更广泛的访问权限也意味着更严重的潜在故障，从更改生产数据、泄露机密信息，到执行超出既定任务范围的操作。
英伟达OpenShell 0.1.0是一款开源运行时系统，用于定义并强制执行智能体可以访问哪些系统和数据。它结合了沙箱化执行、受控服务访问、凭证管理以及形式化策略分析。团队可以根据任务需求授予智能体相应能力，而OpenShell则在工作负载之外强制执行这些权限。
该系统支持Codex、Claude Code、Pi、Hermes以及未来的其他框架，覆盖企业应用、前沿研究和物理AI领域——从内部智能体集群、长周期研究，到机器人和边缘系统。
本文将展示英伟达OpenShell 0.1.0如何在不改写现有AI智能体代码的前提下，为其加装可强制执行的运行时控制机制，使团队能够限制API操作、保护凭证安全，并在智能体工作负载之外审核权限变更。
OpenShell构成了英伟达开放智能体安全平台（Open Agent Safety Platform）的运行时层，该平台的保护范围还延伸至应用层与基础设施层。
企业如何采用OpenShell
OpenShell是开源项目，并已在广泛的合作伙伴生态中面向企业开放采用，这也反过来塑造着产品本身的发展方向。目前，企业已在芯片设计、企业自动化、加速计算和物理AI等多个应用场景中采用OpenShell。
Cadence在其ChipStack自主RTL设计工程师中使用OpenShell进行芯片设计。
Slack正基于OpenShell构建一个按需智能体平台，用于任务自动化。
Gecko Robotics使用OpenShell来管理在物理机器人上做决策的智能体。
OpenShell的核心能力
OpenShell 0.1.0支持沙箱操作、策略验证、治理集成、凭证保护以及灵活的计算部署。
在智能体之外强制执行权限
智能体能够理解指令、选择工具，并随着时间推移调整其做法。OpenShell在保留这种灵活性的同时，将权限强制执行放在了智能体工作负载之外。
OpenShell可以管理多个智能体及其对应的沙箱集群，每个沙箱拥有独立的权限设置，并可同时对多个群组进行治理。这一控制能力由三个组件共同实现：
OpenShell Gateway：管理众多沙箱的生命周期与策略。
OpenShell Supervisor：与每个沙箱配对运行，独立于智能体工作负载之外，对出站请求进行策略核查。
OpenShell Sandbox：运行工作负载本身，具备内核级的文件系统与进程控制，且除通过Supervisor外没有任何网络通路。
OpenShell的沙箱运行时利用操作系统内核控制机制，限制工作负载可读取或修改的文件范围，并阻止其获取额外的系统权限。在网络访问方面，管理者可以比"允许连接某服务"做得更精细：Supervisor能够检查配置好的HTTP、GraphQL和模型上下文协议（MCP）流量，允许通过某个API进行数据查询，同时阻止通过同一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，尝试两种请求：
读取：允许 curl -sS --max-time 10 https://api.github.com/zen # 写入：被拦截 curl -sS --max-time 10 -X POST https://api.github.com/zen
再次查看主机日志，确认OpenShell拦截了POST请求。若由智能体执行这些命令，也会遭遇同样的限制。
在不暴露凭证的前提下访问服务
许多智能体需要调用模型API或私有服务来完成任务。OpenShell会授权这类访问，同时将真实凭证保留在智能体工作负载之外。
针对某一服务的授权并不意味着该凭证可用于另一服务。如果智能体将占位凭证发送到该凭证授权范围之外的目的地，OpenShell会拒绝该请求。
接收服务仍会强制执行与真实凭证相关联的权限。OpenShell在此基础上增加了一层独立控制，用于管理智能体如何使用该凭证。举例来说，即便凭证本身具有写入权限，一项经检查的只读API策略也可以阻止写入请求。
一个提供方配置文件（provider profile）定义了某项服务所对应的凭证、接口以及允许调用的程序。假设名为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的策略证明器（policy prover）运用形式化逻辑来核查策略所授予的全部权限，包括由提供方引入的访问权限。它既能证明经建模的权限始终处于操作员设定的边界之内，也能找出具体越界的操作。由于结果来自策略模型本身，智能体的任何解释都无法改变这一结果。相关的形式化方法入门资料详细介绍了其工作原理。
在长周期的对抗性实验中，安全防护被削弱的前沿智能体曾花费长达两小时的时间，试图说服一个AI审核者授予其修改受保护GitHub代码库的权限。OpenShell的形式化策略分析为审核者提供了这些权限实际含义的证据，即便智能体试图操纵审核者也是如此。审核机制与运行时控制的结合，在保障必要访问的同时，确保了这些测试中没有发生任何对受保护代码库的写入操作。
目前正在进行的研究工作，致力于将策略分析扩展到多智能体场景中——在这种场景下，一个智能体的权限可能与另一个智能体的权限相结合，形成组合效应。研究目标是核查这些智能体共同构成的整体系统的权限边界。相关支持的检查类型详见证明器文档。
本地构建，部署至共享基础设施
在构建应用并定义其权限时，可先从本地沙箱入手。若要面向多个用户提供服务，可参照工作空间与访问指南，并使用SDK来创建和管理沙箱。每个工作负载都拥有各自独立的策略与绑定的提供方。
沙箱外部的可信中间件可以对接身份服务，并在请求路径中加入特定于应用的检查逻辑。计算驱动程序将OpenShell与Docker、Podman、MicroVM及Kubernetes相连接，具体的当前需求可参见支持矩阵。
欢迎加入CNCF Slack上的#openshell-dev频道，提出问题、分享反馈，并与其他基于OpenShell构建产品的团队和开发者交流。可在GitHub上查看代码并参与贡献，并通过OpenShell开发笔记了解持续进行中的研究与工程工作。若您正在升级现有部署，请参阅0.1.0迁移说明。
准备好开始构建了吗？请从快速入门指南开始，运行属于你自己的智能体，并配置其可访问的服务。
Q&A
Q1：英伟达OpenShell是什么？
A：OpenShell是英伟达推出的开源运行时系统，用于定义并强制执行AI智能体可以访问哪些系统和数据，它结合了沙箱化执行、受控服务访问、凭证管理及形式化策略分析等能力。
Q2：OpenShell支持哪些AI智能体框架？
A：OpenShell支持Codex、Claude Code、Pi、Hermes以及未来出现的其他框架，应用场景覆盖企业应用、前沿研究和物理AI，包括内部智能体集群、长周期研究、机器人和边缘系统等。
Q3：目前有哪些企业在使用OpenShell？
A：Cadence在芯片设计中使用OpenShell；Slack正基于OpenShell构建按需智能体平台以实现任务自动化；Gecko Robotics则用它来管理在物理机器人上做决策的智能体。
