NVIDIA OpenShell解析：沙箱、凭据代理与L7策略执行
内容提要
NVIDIA OpenShell 通过 Gateway、Supervisor 和 Sandbox 三层，在 Agent 外部强制实施网络、凭据和方法级权限控制。默认无网络，外发请求由 Supervisor 按 L7 策略检查，真实密钥保留在工作负载之外。文章强调需进行策略审查、日志审计和故障演练，并指出多 Agent 组合权限与供应链风险仍待解决。
延伸解读
版本差异与安装注意
文章基于 NVIDIA 9 月 28 日详解的 OpenShell 0.1.0，但官方 GitHub 同日已发布 v0.1.2。安装时若照抄文章中的旧版本号，可能错过修复或变更。建议以 v0.1.2 当前文档为准，并注意示例命令需结合最新文档执行，避免将文章摘要当作完整安全配置。
策略审查与能力清单
策略写错时，强执行只会精确执行错误权限。应对策略变更做 diff，先用形式分析查看新增能力，再人工批准。上线前为每个 Agent 做能力清单：可读目录、可启程序、可访主机、可用 HTTP 方法、凭据替换点及拒绝告警。清单应从任务推导，而非从现有密钥推导，确保只允许任务必需的主机、路径和方法。
日志审计与故障演练
OpenShell 记录 OCSF 格式的策略决策，便于拒绝事件进入统一安全分析流水线。建议分开统计误拒、真越权、未匹配路由和凭据绑定失败，避免所有拒绝只被当作“网络错误”。故障演练需回答：Supervisor 不可用时网络是否默认拒绝；凭据代理失败时 Agent 是否结束；日志后端不可用时策略执行是否保持。只有控制面故障下仍安全失败，运行时边界才可信。
多 Agent 组合权限风险
多 Agent 场景存在组合权限问题：单个 Agent 只能读数据，另一个只能发消息，单独看低风险，但若通过共享文件或远程 MCP 传递内容，整体可能具备将数据发往外部的能力。NVIDIA 表示后续工作正扩展到多 Agent 权限分析，说明当前版本不应被视为已完整解决组合风险。上线前应以整条任务图为单位审计，而非只看每个沙箱自己的策略。
Q&A
NVIDIA OpenShell 是什么？它的核心安全机制是什么？
NVIDIA OpenShell 是一个在 Agent 外部强制实施网络、凭据和方法级权限控制的运行时安全框架。其核心机制是通过 Gateway、Supervisor 和 Sandbox 三层架构，默认无网络路径，所有外发请求由 Supervisor 按 L7 策略检查，真实密钥保留在工作负载之外。
OpenShell 的 Gateway、Supervisor 和 Sandbox 分别负责什么？
Gateway 管理多个沙箱和策略；Supervisor 在工作负载外检查外发请求，执行 L7 策略；Sandbox 利用操作系统内核控制文件、进程和特权。
如何验证 OpenShell 的策略执行是否生效？
官方提供了一个无需 API 密钥的 GitHub 公开端点练习：先使用 no-network.yaml 策略创建沙箱，执行 curl 请求应被拒绝，日志会指出请求程序和命中规则；然后更新为 github-readonly.yaml 策略，重试 GET 应放行，写方法应拒绝，且两者都有审计记录。
使用 OpenShell 时需要注意哪些安全风险或限制？
主要风险包括：策略写错会导致精确执行错误权限；允许访问域名不等于允许所有操作，需下沉到方法、路径和身份；凭据不进工作负载只降低泄漏面，接收服务仍需实施自己的 IAM 和业务授权。此外，供应链风险和多 Agent 组合权限问题仍待解决。
OpenShell 适合哪些场景？哪些场景可能过重？
适合长时间运行、会写代码、会调外部服务、需要多租户管理的 Agent。如果任务只是在无网络的一次性容器中读公开文本，完整网关可能过重。
上线 OpenShell 前应该做哪些准备工作？
应为每个 Agent 制定能力清单，包括可读目录、可启程序、可访主机、可用 HTTP 方法、凭据替换位置及拒绝事件告警方式。能力清单应从任务推导，而非从现有密钥推导。策略变更应像代码一样审查，日志应记录 OCSF 格式的策略决策，并分开统计误拒、真越权、未匹配路由和凭据绑定失败。还需进行故障演练，确保控制面故障时安全失败。
