用 NVIDIA OpenShell 为 AI Agent 加上运行时控制
各组织如何采用 OpenShell
OpenShell 是开源的，可在广泛的合作伙伴生态中供企业采用，而合作伙伴也影响着产品本身的发展。各组织正在芯片设计、企业自动化、加速计算和物理 AI 等一系列领域采用 OpenShell。- Cadence 在芯片设计中使用 OpenShell，应用于其 ChipStack Autonomous RTL Design Engineer。
- Slack 正在基于 OpenShell 构建按需 agent 平台，用于自动化任务。
- Gecko Robotics 使用 OpenShell 来治理在实体机器人上做决策的 agent。
OpenShell 的能力
OpenShell 0.1.0 支持沙箱操作、策略验证、治理集成、凭据保护以及灵活的计算配置。
| 能力 | 作用 |
|---|---|
| 多租户平台支持 | 在共享基础设施上为多个团队或客户运行 agent 服务，各自拥有独立的工作区、权限和服务访问。 |
| 形式化策略验证 | 向人类和 AI 审查者展示所请求的权限是否仍在定义的安全边界内，并标明越界之处。 |
| 可扩展的安全与治理 | 接入第三方安全服务、治理系统和自定义检查，在 agent 工作负载之外执行管控。 |
| 凭据保护的服务访问 | 使用经过身份验证的服务，同时真实凭据保留在 agent 工作负载之外，并与已授权的请求绑定。 |
| CPU 和 GPU 执行 | 在容器、虚拟机和 Kubernetes 环境中的 CPU 或 GPU 上运行实验和数据处理。 |
在 agent 之外执行权限管控
Agent 可以理解指令、选择工具，并随时间调整策略。OpenShell 在保留这种灵活性的同时，在 agent 工作负载之外执行权限管控。
OpenShell 可以管理 agent 集群及其沙箱，每个沙箱都有各自的权限，并支持跨组治理。这一控制体系由三个组件实现：
- OpenShell Gateway：管理大量沙箱的生命周期和策略。
- OpenShell Supervisor：与每个沙箱配对，运行在 agent 工作负载之外，根据策略检查出站请求。
- OpenShell Sandbox：运行工作负载，在内核层面控制其文件系统和进程，除通过 supervisor 外没有任何网络通路。
OpenShell 沙箱运行时利用操作系统内核级别的控制，限制工作负载可以读取或修改哪些文件，并防止其获取额外的系统权限。在网络访问方面，你甚至可以做到比"允许连接到某个服务"更细粒度的控制。监督器可以检查已配置的 HTTP、GraphQL 和 Model Context Protocol (MCP) 流量，比如允许通过同一个 API 执行数据查询，同时拦截写入操作。当 agent 启动 shell、运行生成的代码、创建子进程，或将任务委派给 sub-agent 时，这些控制始终生效。OpenShell 会把策略决策记录到 Open Cybersecurity Schema Framework (OCSF) 审计日志中。当它拦截某个请求时，还能返回描述性的错误信息，帮助 agent 判断下一步该怎么做。
亲眼看看策略决策的过程
下面的示例使用 curl 和 GitHub REST API 中一个无需认证的端点，无需 API key 或语言模型就能清晰看到每一次策略决策。当 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，再试一次这两个请求：
# 读：允许 curl -sS --max-time 10 https://api.github.com/zen # 写：拦截 curl -sS --max-time 10 -X POST https://api.github.com/zen
再次查看主机日志，确认 OpenShell 拦截了 POST 请求。运行这些命令的 agent 同样会受到这些限制的约束。
访问服务但不暴露凭证
许多 agent 需要调用模型 API 或私有服务才能完成任务。OpenShell 在授权这类访问的同时，把真实凭证留在 agent 工作负载之外。
一项服务的授权不会让凭据对其他服务可用。如果 agent 把占位密钥发送到该凭据未批准的端点，OpenShell 会拒绝该请求。
接收方服务仍然会强制执行真实凭据所附带的权限，而 OpenShell 额外增加了一层对 agent 使用凭据方式的控制。例如，一条经审查的只读 API 策略可以阻止写请求，即使凭据本身拥有写权限。
provider profile 定义了某项服务的凭据、端点和允许运行的程序。假设已配置好一个名为 github 的 GitHub provider，将它挂载到新的 sandbox 并启动 Codex：
openshell sandbox create \ --provider github \ -- codex
在 agent 运行期间调整网络访问
Agent 在执行任务过程中，可能会发现需要一个任务开始时未知的ừ务或数据源。当策略拦截了该请求时，OpenShell 会记录这次拒绝，供运维人员或 AI Agent 审批者审查。启用 policy advisor 后，Agent 可以提出一个作用范围极小的网络或文件策略变更提案。该提案默认保持待审状态，等待人工审查，且 Agent 无法批准自己发起的请求。审批通过后，OpenShell 会把新规则加载到正在运行的 sandbox 中，Agent 无需重启即可直接重试。
文件系统和进程限制是在 sandbox 启动时确定的，要修改这些限制需要新建一个 sandbox。
使用以下命令为 sandbox 启用 policy advisor。
openshell settings set <sandbox-name> \ --key agent_policy_proposals_enabled \ --value true
验证策略实际授予的权限
一项策略可能看起来限制很严，实际上却留有其他通道。通过某个工具阻止 GitHub 写操作毫无意义——只要另一个被允许的工具或生成的代码能够利用凭证完成同样的写入，防线就形同虚设。
OpenShell policy prover 使用形式化逻辑来检查策略授予的权限，包括 provider 贡献的访问权限。它能证明建模后的权限始终处于运维人员定义的边界内，或者找出越界的具体操作。由于结论来自策略模型本身，Agent 的任何辩解都无法改变结果。可以阅读配套的形式化方法入门，了解其工作原理。
在长时间运行的对抗性实验中，被削弱安全防护的前沿 Agent 花了长达两小时试图说服一个 AI 审核员授予其权限，以便修改受保护的 GitHub 仓库。即便 Agent 百般操纵，OpenShell 的形式化策略分析仍为审核员提供了证据，说明这些权限究竟意味着什么。审查与运行时控制相结合，既保证了有用的访问，也让这些测试中未发生任何对受保护仓库的写入。
目前正在进行的工作是将策略分析扩展到多个 agent 的场景：一个 agent 的访问权限可能与另一个的权限组合在一起，目标是校验它们共同构成的系统的权限。支持的检查类型详见 prover 文档。
本地构建，部署到共享基础设施
开发和定义应用权限时，可以先在本地 sandbox 中进行。要服务多个用户，可参考workspaces 与访问指南，并使用 SDK 创建和管理 sandbox。每个 workload 都有各自的策略和挂载的 provider。
sandbox 外部的可信中间件可以对接身份服务，并在请求路径上加入应用特定的检查。计算驱动负责将 OpenShell 接入 Docker、Podman、MicroVM 和 Kubernetes，当前的依赖要求见支持矩阵。
欢迎加入 CNCF Slack 的 #openshell-dev 频道提问、分享反馈，并与使用 OpenShell 构建产品的其他团队和开发者交流。你也可以在 GitHub 上查看代码并参与贡献，或在 OpenShell dev notes 中关注最新的研究与工程进展。如果要升级已有部署，请参阅 0.1.0 迁移说明。
准备好动手了吗？从快速入门开始，用 OpenShell 运行你自己的 agent，并配置它可访问的服务。