NVIDIA OpenShell v0.1.5：策略推送，审计日志

1. 不再定期询问，而是直接接收变更

OpenShell v0.1.5 于 2026年10月20日发布。核心变化是向智能体运行环境沙箱传递策略和配置的新方式。沙箱不再定期询问是否有变更，而是由作为管理入口的网关将变更推送给已连接的监督进程。

据公司介绍，新方式将变更传递到沙箱约需 100毫秒。原有定期检查方式最多可能需要 10秒，且在本版本中仍为默认方式。前者是大致传递时间，后者是最长等待时间，因此运维人员应关注等待变更的方式有何不同，而非比较速度倍数。

要使用新方式，需在配置中将分发模式设为 push。网关内部也按工作空间和沙箱拆分了等待变更操作的队列。这一调整可缓解多个监督进程同时重连时，所有操作都堵在同一把锁这一防止并发访问的控制机制后面的问题。

2. 将审计记录接入外部日志采集通道

网关和沙箱监督进程可将按通用安全事件格式 OCSF 记录的内容发送到外部。传输时使用可观测性数据传输协议 OTLP 的日志记录格式。此外还新增了将执行流程追踪信息与安全事件分别发送到不同采集地址的功能。

这项传输功能需在配置中启用。如果配置仍像以往一样仅指定一个采集地址，则保持原有行为。运维团队可将追踪信息与审计记录集中到同一处，也可按用途拆分采集通道。

被拒绝的请求也会记录为身份验证事件。记录包含身份验证方式、拒绝原因分类、请求来源地址和请求标识符。这不仅记录了请求被拒绝的事实，也提供了更多信息，用于确认拒绝涉及的方式与原因。

事件格式也得到完善。根据发行说明，新增的操作系统类型标识符使其能够通过 OCSF 1.8 模式验证，即检验数据字段和结构规则的验证。此次同时扩展了外部采集通道并完善了记录格式。

3. 先检查日志采集模式与历史记录保留

监督进程的审计日志采用含日期的文件名和逐行 JSON 格式。如果现有采集器查找的是 openshell-ocsf.*.log，就需要将匹配模式改为 openshell-ocsf.*.jsonl。

现有日志文件不会迁移到新格式，且可能被清理，因此应在升级前收集所需历史记录。文件名变更并非单纯的命名调整，而是确保采集器持续找到新记录所必需的迁移工作。

4. 沙箱创建代码和部署规则发生变化

Go SDK 这一提供开发功能的工具集，其沙箱创建函数从在固定位置传入标签参数，改为按功能传入选项。原有的选项结构体，即将配置值打包传递的数据类型，也已移除，因此使用这些调用的代码需按新方式修改。不仅标签，注解这一描述对象的附加信息以及服务暴露配置，也都通过新的选项方式传递。

在 Kubernetes 中，运维人员必须将通过沙箱模板附加到 Pod（运行容器的部署单元）上的标签和注解键，登记到允许使用的条目清单即允许列表中。指定未获允许的键的模板会被拒绝。需要检查的是直接通过 API 或 SDK 指定模板的集成，而命令行工具的元数据标签仍可照常使用。

5. 更快生效与更广的记录用途伴随着迁移工作

此次变更的益处是缩短等待策略生效的时间，并拓宽审计记录的使用渠道。相应地，运维团队需要决定是否启用新的分发方式与日志传输功能，并检查采集匹配模式、模板允许列表及现有创建代码。关键是将新功能的选择和现有集成的迁移一并纳入部署计划。

发行说明提供的指定版本安装示例如下。

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | OPENSHELL_VERSION=v0.1.5 sh

OpenShell v0.1.5 的实际价值在于更快地将策略变更和审计记录接入运维流程，而要利用这些能力，也必须同步准备现有采集与集成配置的迁移。