英伟达宣布将智能体开源安全运行时OpenShell贡献给CNCF，以Sandbox项目身份推进厂商中立治理。项目通过文件、网络、进程和凭据控制约束智能体执行权限，Cedar策略语言与跨平台集成仍在推进，基金会托管并不意味着安全验证或产品成熟度已经达标。
2026年11月10日，英伟达在 KubeCon + CloudNativeCon 北美大会期间宣布，将面向自主人工智能智能体的开源安全运行时 OpenShell 贡献给云原生计算基金会（CNCF）。CNCF同日发布的公告确认，OpenShell以 Sandbox 项目身份进入基金会社区，并将推进厂商中立的治理安排。
这次公告的重点不是推出一个全新的智能体产品，而是改变已有安全基础设施的共同维护方式：谁来讨论规则、审查设计，以及决定项目如何演进。英伟达仍将继续核心工程投入，其他厂商、集成商和使用者则获得参与共同建设的渠道。
需要区分公告日期与项目接收日期。11月10日是双方这轮公开公告的日期，但CNCF项目页面将接收日期列为2026年9月26日，而项目元数据中的 Sandbox 阶段日期为10月2日。几份材料的日期口径并不一致，公告没有解释其中差异，因此不能把11月10日直接认定为项目首次获接收的时间。
安全边界为什么要设在智能体之外
智能体要完成实际工作，往往需要读取文件、调用接口、使用凭据或访问网络。这些能力也是风险来源：执行任务所需的权限，可能被用于访问不相关的数据，或者把内部信息发送到未经批准的地址。
OpenShell试图把“模型决定做什么”与“系统允许做什么”分开。英伟达此次公告称，它通过确定性的运行时控制，在智能体使用工具、访问推理服务和执行工作负载时落实策略，而不是只依赖模型遵守提示词中的要求。
OpenShell官方文档给出了更具体的机制：文件系统限制约束可读写的路径；网络策略限制对外连接；进程隔离和系统调用限制用于阻止权限提升；凭据访问则与获准的服务端点绑定。文档同时说明，不同控制的更新方式并不相同，例如文件系统和进程策略在创建沙箱时锁定，网络策略可以在运行时热更新。
这意味着，安全运行时并不是替模型判断每一项业务决策是否正确，而是在执行层约束它可以接触哪些资源。其效果仍取决于策略是否完整、允许的服务是否可信，以及企业如何管理身份和权限。开源代码和基金会托管本身，不能替代对具体部署的安全验证。
从厂商项目转向共同治理
CNCF表示，OpenShell正从英伟达的 GitHub 仓库迁往中立的 ai-openshell 组织。该组织页面已经可以访问，并列有 SDK、管理界面及项目元数据等仓库；这不意味着所有代码和治理迁移工作都已完成。
按照CNCF公告，项目已经采用基金会行为准则，运行公开的 RFC（征求意见稿）流程，并在治理模式中明确厂商中立承诺。英伟达、Red Hat、Docker 和 Canonical 的核心贡献者此前已参与开发；接下来还将围绕集成组件、可观测性等议题成立工作组和特别兴趣小组。
对企业用户而言，这一变化的实际意义，在于安全控制层不必完全依附于单一厂商的产品路线。公开讨论和共同维护，为不同云平台、凭据系统和审计工具的接入提供了组织基础。不过，中立治理是一套决策和协作安排，不等于不同厂商已经实现完全互操作，也不构成独立的安全效果认证。
这一进展与此前的产品发布也有区别。AIFlux此前报道的OpenShell参考架构，着眼于运行时、计算和硬件管控如何组成企业基础设施；此次公告则着眼于开源运行时本身由谁共同治理和维护。
Cedar与跨平台集成仍在推进
CNCF称，OpenShell正在采用同属基金会项目的 Cedar 作为策略语言。公告使用的是正在推进的表述，而不是宣布所有部署均已完成切换。当前官方概览仍以声明式 YAML 策略说明运行时控制；两份材料不足以证明 Cedar 已在所有现有配置中全面替代原有策略方式。
可扩展性是项目强调的另一项设计目标。CNCF列出的扩展点涉及计算、推理服务、审批流程、策略执行、隔离和凭据管理，企业可以逐步接入已有系统，而不必同时替换所有基础设施。但这种设计目标仍需由具体实现、文档和一致性测试支撑。
英伟达还表示，正与Google合作，将OpenShell与Google发起的 Agent Substrate 整合。后者用于在 Kubernetes 上运行长期智能体工作负载，并通过保留执行环境、在空闲时释放计算资源来管理任务。两者分别面向执行环境的治理与规模化运行，整合具有互补性；目前公告确认的是合作工作，而非一套已经在所有云和本地环境全面交付的联合产品。
Sandbox不是成熟度终点
CNCF将多项工作列为后续贡献方向：扩大 Linux、macOS 和 Kubernetes 的平台覆盖，开展安全审查和对抗测试，建立与 OpenTelemetry 对齐的指标、追踪和审计事件，以及完善多租户、身份接入和策略管理流程。
发布工程也是待推进领域，包括可复现构建、软件物料清单（SBOM）、签名和持续集成。公告明确，这些工作将支持未来的 Incubation（孵化）要求。这说明，Sandbox身份与后续孵化阶段并不是同一成熟度状态，接收项目也不意味着上述能力已经全部具备。
OpenShell此次治理转向，为企业、平台厂商和安全研究人员提供了共同审查与改进运行时控制的场所。它能否形成可信赖的通用基础设施，仍要看公开治理如何运作、策略执行能否经受真实攻击，以及不同部署环境中的集成与审计能否保持一致。对企业来说，基金会托管可以成为评估项目持续性的一项依据，但不能替代对权限边界、故障处理和实际安全效果的逐项验证。