NVIDIA OpenShell 参考架构将智能体约束置于基础设施层

NVIDIA 于 10 月 21 日推出 NVIDIA OpenShell Reference Architecture，将智能体权限置于执行任务的软件控制范围之外。该设计在 GTC Berlin 上发布，连接模型计算、智能体执行与独立的安全强制执行。其核心主张很务实：智能体应能持续自主工作，但不应获得改写自身限制的权限。

这带来的采购决策不同于选择能力更强的模型。企业必须决定权限应存放在哪里、由哪些基础设施执行，以及一旦出现问题，谁有权停止智能体。关键张力在于：既要实现有用的自主性，又要让限制足够精确，以防止未授权操作，同时不妨碍正当工作。

Anthropic 的 Claude Code 提供了一个有益的对照，因为它同样通过运行环境来限制智能体。NVIDIA 则将这一讨论延伸至企业基础设施和可选的硬件强制执行。开发者、安全团队和企业软件供应商如今面临一个共同问题：组织如何将业务规则转化为在执行期间依然有效的边界？

NVIDIA OpenShell Reference Architecture 将执行与强制执行相连接

此次发布将智能体隔离包装为一项基础设施责任，并通过独立组件分别承担执行工作和实施治理。

参考架构是一份有文档记录的系统设计，组织和合作伙伴可在构建部署时加以采用。它并不意味着每项点名的集成都以具备相同能力的完整产品形式交付。在评估一项横跨处理器、操作系统、安全供应商和企业应用的发布时，这一区别尤为重要。

根据 NVIDIA 的 OpenShell 参考架构，Vera Rubin 基础设施运行模型，Vera CPU 则运行智能体 harness，即协调模型调用和工具的软件。作为专用基础设施处理器的 BlueField-4 数据处理单元运行 Sentry 安全软件，用于独立监控和强制执行。

这种划分对应不同的运行问题。生成计划需要计算能力。执行计划需要访问文件、服务和工具。对这些操作进行授权则需要一套规则，而执行中的智能体不能仅仅因为限制妨碍其任务，就自行修改这些规则。

此次发布还将该设计延伸至本地和边缘部署，即在更接近用户或设备的位置运行的系统。NVIDIA 点名了 RTX Spark、DGX Spark 和 DGX Station。采购方应逐一评估这些环境，而不应假定本地工作站具备为更大规模基础设施部署所描述的全部保护能力。

重要变化在于这些组成部分之间所提出的关系。该架构不再将安全视为开发后附加的应用功能，而是将强制执行置于应用之下。智能体的请求会成为基础设施评估的对象，而不是因为智能体给出了看似合理的解释便被接受。

以一项示例性的工程任务为例：智能体调查一项故障服务并提出修复方案。读取诊断文件、安装依赖项、修改配置和部署修复措施，分别代表不同的权限。一条修复服务的指令，并不意味着所有可能步骤都已获授权。

这一示例说明，该架构的相关性并不局限于安全专家。承诺实现自主执行的产品团队，也必须说明这种执行的边界。否则，客户获得的只是能力描述，而非相应的控制说明。

可用性同样需要谨慎解读。NVIDIA 表示该参考架构已可用，但这并不能证明每一种合作伙伴组合都已具备生产就绪条件。有文档的设计、受支持的部署以及经过验证的客户安装，回答的是不同问题。

因此，对评估此次发布的读者而言，第一个问题应当非常具体：在所提供的配置中，拟议的执行与强制执行链条哪些部分实际存在？答案将决定采购方评估的是软件控制、额外硬件保护，还是二者结合的路线图。

企业团队将承接权限难题

将强制执行移入基础设施可让企业获得更多控制权，同时也使其更难继续对自身的策略决策含糊其辞。

眼前的压力落在负责将业务权限转化为技术权限的团队身上。安全团队可以定义受限资源，但业务负责人必须说明哪些操作属于任务范围。基础设施团队随后必须让这些决定能够在智能体接触的各个系统中得到执行。

诸如“准备客户续约”的指令存在相当大的模糊性。它可能足以支持读取账户历史并起草提案，但并不自动意味着可以修改合同条款、导出客户记录，或未经审核直接发送提案。

这些是说明性的区分，并非关于 OpenShell 部署结果的报道。它们表明，智能体安全不仅仅是识别模型，或确认某位员工是否发起了请求。权限取决于操作、目标及其所处情境。

NVIDIA 的智能体运行时控制将责任划分给网关、监督器、沙箱和策略证明器。网关负责管理策略和沙箱生命周期。监督器会检查请求，并在作为隔离执行环境的沙箱外协调凭据。策略证明器则根据组织定义的权限上限检查权限。

这种分离提供了强制执行位置，但组织仍需决定这些位置应允许什么。经过形式化检查的上限可以确认策略之间的关系，却无法独立判断某个业务部门最初是否授予了过多访问权限。

这改变了应用开发者与安全审查者之间的讨论方式。审查者不再需要询问智能体是否整体可信，而可以审查它能够读取、修改、调用或传输什么。这些问题能带来更具可操作性的答案，但也需要更细致的准备。

开发者面临一项相关的设计约束。只有在获得广泛权限时才能成功的工作流，比权限要求明确且有限的工作流更难获得批准。工具接口和任务描述会成为安全设计的一部分，因为它们决定了权限能够被表达得多精确。

对知识工作者而言，这一区别始于信息访问。一个可搜索的知识库有助于确定有用材料的存放位置。能够采取行动的智能体则引入另一项决策：找到信息是否也意味着有权分享它，或修改包含它的系统。

组织负担是持续存在的。员工会变更角色，项目会结束，凭据会过期，应用程序会获得新功能。智能体的权限需要反映这些变化，而不是保留令其首次演示成功的那部分访问权。

这正是治理不能止于审批文件的原因。企业需要在授权工作的人员、代表该权限的策略以及执行该策略的基础设施之间建立连接。没有这种连接，即使规则得到独立强制执行，也可能仍在保留过时或过于宽泛的决定。

因此，此次发布给软件供应商带来的压力不亚于基础设施采购方。供应商必须充分披露智能体操作的细节，才能让客户对其实施治理。将每项操作都呈现为难以区分的请求的系统，只会让客户在广泛访问与工作中断之间作出粗糙的选择。

硬件隔离改变边界的维持位置

NVIDIA 的硬件方案增加了一个独立的强制执行位置；其价值取决于相关操作是否实际经过该位置。

软件限制具有明确的作用范围。其保护效果取决于实施限制的组件，以及这些组件所作出的假设。通过将控制置于智能体执行环境之外，增加独立硬件安全层改变了其中一些假设。

NVIDIA 将 Sentry 描述为 OpenShell 软件边界之外的可选附加保护。这一区别避免了一种常见误解：使用 OpenShell 并不自动意味着部署包含 BlueField-4 强制执行。采购方在比较安全主张前，需要先识别实际配置。

在 NVIDIA 的 Sentry 运行时安全设计中，BlueField-4 位于节点通往模型和外部系统的通信路径上。Sentry 将流量检查与选定的主机内存分析相结合。NVIDIA 表示，它可在数毫秒内隔离智能体，无需智能体或主机软件配合。

其架构逻辑很直接：当被控制的工作负载无法将控制关闭时，控制对受损工作负载更有用。但独立性本身并不能证明覆盖完整。强制执行点还必须能够看到正在评估的操作，并保有阻止该操作的权限。

这为部署审查带来了具体问题。配置是否将每个相关的外部连接都路由至受控路径？哪些本地操作会受到单独限制？当某个工具在接收已获授权的请求后，转而在另一项服务上执行工作时，会发生什么？

这些问题源自设计本身，而非对已发现故障的记录。它们之所以重要，是因为智能体工作流可能跨越多个管理边界。阻止其下一次连接，并不一定能撤销另一应用已接受的操作。

加密流量引入了另一项配置决策。NVIDIA 描述了对被配置为解密和检查的连接进行检查。企业因此需要了解检查适用于何处、哪些信息将变得可见，以及这种可见性如何符合其保密要求。

与 Anthropic 的比较有助于厘清这种设计选择。Anthropic 的 Claude Code 沙箱化利用操作系统机制限制文件系统和网络访问。其公开表述的方法是在预定义边界内给予智能体自由，同时控制其边界之外的访问。

这两种方法都将限制置于模型生成的指令之外。区别并不只是“不受限制的软件”与“安全硬件”之间的简单较量。买家比较的是执行安排、部署要求和故障假设。

Anthropic 的示例针对开发者执行环境。NVIDIA 的公告则将智能体执行与更广泛的基础设施设计相连接，并提供可选的独立硬件层。仅凭任一描述，都无法判断哪种安排最适合特定企业工作负载。

对于运行范围明确的开发任务的组织而言，现有环境控制措施本身就值得评估。对于需要进一步独立于主机软件的敏感部署，NVIDIA 的硬件方法提供了另一种选择。决策应取决于所要应对的威胁。

核心权衡在于：以更高的部署复杂度换取更强的隔离。额外的执行层增加了一个阻止不安全活动的环节。但它也增加了一个组件，其策略、可观测性、更新和运维归属必须与系统其余部分保持一致。

合作伙伴公告揭示了不同的成熟阶段

最有价值的合作伙伴信息，能够区分现已可用的能力与仍处于规划阶段的集成。

ServiceNow 提供了一个具体示例，说明该架构正进入企业产品讨论。其关于企业智能体治理的公告称，面向长时任务设计的个人智能体 Arc 已全面上市。ServiceNow 将 OpenShell 执行机制描述为 Arc 受治理执行的一部分。

同一公告将 AI Passport 与 OpenShell 和 BlueField 执行机制的集成安排在未来版本中。AI Passport 是一项旨在传达智能体权限的授权记录。其仍处于规划阶段这一点很重要，因为当前应用的发布并不意味着整条拟议治理链已经可用。

这种区分为买家解读其他发布材料提供了有用方法。当前时态的可用性应与预期集成、合作伙伴协作及未来能力分开评估。将它们合并为对成熟度的单一印象，会掩盖仍需完成的工作。

ServiceNow 的示例也使业务问题变得具体。一个持续运行的工作场所智能体必须跨越不断变化的任务分配和权限开展工作。治理必须在初始请求之后仍然有效，尤其当任务延续到用户无法即时关注的时段时。

一个说明性案例是，员工指派智能体协调项目交接。阅读项目文档、识别未完成工作、起草消息和变更访问权限需要不同的授权。一个有用的系统需要在任务推进过程中保持这种区分。

安全合作伙伴带来了另一层差异化。F5 描述了AI 流量检查，它通过检查所支持的提示、响应和工具调用，补充运行时权限控制。其公告还区分了一个仍需进行产品验证的拟议部署拓扑。

这是一项重要限定，而非无关紧要的脚注。合作伙伴可以支持该架构的方向，同时特定配置仍有待验证。客户应询问：哪个部署已经过测试、启用了哪些检查功能、面向何种工作负载。

F5 的说明还将授权与内容评估区分开来。一个请求可以指向获批准的服务，但携带敏感信息或恶意指令。连接权限和对传输内容的判断，处理的是不同风险。

这有助于解释为何此次发布包含安全合作伙伴，而不是将基础设施执行机制呈现为对所有现有防御措施的替代。拟议的边界需要获得有关身份、授权和可疑活动的输入。在某项活动被阻止后，它还需要相应的运营响应。

商业层面的问题是，这些层是否会变得更易于协同运作。买家应关注策略是否一致，以及事件记录是否易于理解。如果新增的是彼此独立的控制台，却没有清晰说明各项决策之间的关系，调查人员仍将不得不在割裂的系统中重建事件经过。

广泛的合作伙伴阵容表明市场兴趣，但部署细节更具分量。客户可以评估受支持的配置、已记录的限制或已交付的集成。发布名单上的公司名称，对于证明客户当下能够安全运行什么，提供的证据较少。

安全边界仍然依赖正确的规则

NVIDIA OpenShell Reference Architecture 并未消除“获授权的行动”与“良好决策”之间的区别。

智能体可以始终处于其权限范围内，却仍然产生错误结果。它可能误读文档、选择错误记录，或提出不当建议。基础设施隔离解决的是行动范围问题；它并不能确保每一个结论都正确。

这种区别应当塑造组织对“安全”一词的理解。安全是一种广泛结果，而运行时执行机制提供的是特定控制。有效的评估应明确所防止的故障，以及防护成立所依赖的假设。

设想一个获授权更新排班系统的智能体。一项限制可能成功阻止它访问薪资数据。但同一个智能体仍可能在获准应用中安排错误的预约。两种结果都很重要，但需要不同的防护措施。

过于宽泛的权限带来另一项限制。一条允许智能体导出整个数据集的规则，即便得到完美执行，也无法保护该数据集免受获授权导出。即使执行机制完全按设计工作，业务决策的质量依然至关重要。

过于狭窄的权限则会带来相反问题。如果日常工作反复受阻，用户就会有动力申请更广泛的访问权限。安全团队随后需要掌握证据，区分哪些拦截是在防止损害，哪些则反映出策略与合法任务不匹配。

这是一项分析层面的关切，而非认定 OpenShell 会造成不必要的中断。它指出了评估自主性权衡所需的衡量标准。成功的隔离应与有效任务完成、干预频率以及被拒绝操作的后果一并考量。

检测时机同样需要结合背景理解。快速隔离的说法描述的是在检测到相关条件后作出的响应。买家仍需了解哪些事件会触发检测，以及在隔离开始前，外部系统是否已经采取行动。

现有供应商描述并未确立一项经独立验证、适用于所有企业工作流的普遍保证。它们解释了预期机制和集成点。生产环境中的安全结论需要与已部署配置相关的证据，包括其权限和已启用的防护措施。

扩展可观测性还涉及隐私维度。检查通信和执行上下文可以改善调查，但也可能使敏感材料暴露给更多安全组件。组织需要就检查范围、记录访问和保留期限作出明确决定。

运营责任同样值得关注。必须有人维护策略、调查拒绝事件、批准例外，并在隔离后恢复智能体。如果这些责任仍不明确，即使技术边界有效，也可能造成长时间中断或不安全的规避方案。

NVIDIA 的方法使这些问题更加具体，因为它明确了可独立执行规则的位置。这是系统设计上的有益进展。它并未消除评估规则本身或围绕安全决策的工作流的必要性。

因此，恰当的标准应是一项有边界的主张：在特定条件下，特定控制能够阻止特定的未授权行动。买家应避免将这一表述扩大为智能体不会造成损害的普遍承诺。

关注已交付的集成、安全证据与运营适配性

下一批有意义的信号将是已交付的能力、可复现的验证，以及组织能够维护由此产生的控制措施的证据。

未来几个月，第一个信号将是对被描述为未来工作的集成的交付。ServiceNow 规划中的 AI Passport 执行机制就是一个具体例子。若发布版本提供已记录的支持与限制，企业授权与基础设施执行机制之间的拟议连接将更易于评估。

这将强化这样一种判断：企业能够让治理决策跨越执行层传递。若相关内容持续停留在路线图语言中，这部分主张的确立程度就会较低。买家应区分产品可用性与演示或合作公告。

第二个信号是与完整部署相关联的安全验证。有价值的证据应描述工作负载、策略配置、已启用的检查、尝试的未授权行动以及观察到的结果。它还应说明哪些合法工作仍可继续进行。

展示智能体被拦截，所能证明的内容少于一份可复现的说明，后者能够解释它为何被拦截。后者帮助客户判断同一控制是否适用于其应用，也揭示了演示中可能未明确说明的假设。

验证应同时覆盖获允许的工作流和攻击场景。一个既能阻止未授权活动、又允许预期工作的边界，支持该架构的核心权衡。若反复依赖宽泛例外，将削弱企业能够将自主性与精确控制结合起来的主张。

第三个信号是其在实际企业环境中的运营适配性。组织需要了解当应用、身份和工具发生变化时，策略能否保持一致。它们还需要事件记录，以解释请求的行动与执行决策之间的关系。

可管理的策略更新和易于理解的调查证据将强化部署理由。规则不一致或归属不清的证据，则会揭示另一项瓶颈。在这种情况下，额外的执行能力本身无法解决治理问题。

本地和边缘部署在这项运营评估中尤其值得关注。读者应寻找针对所部署具体系统的已记录能力。共享的产品家族或架构标签，并不能回答有关执行覆盖范围的每一个问题。

对于开发者而言，实际影响是对更清晰权限要求的需求。对于企业买家而言，是对配置特定证据的需求。对于知识工作者而言，则是授予智能体信息访问权与委托其采取行动的权限之间的区别。

在批准部署之前，明确代理需要完成的具体工作流，以及必须始终排除在其权限范围之外的操作。要求供应商在拟议配置中展示两种结果：合法工作持续进行，以及未经授权的操作被阻止。随后审查由谁维护相关政策、访问权限变更如何生效，以及调查人员事后能够重建哪些记录。务必将当前已具备的能力与承诺中的集成方案区分开来，尤其是在软件和硬件发布节奏不同的情况下。NVIDIA OpenShell Reference Architecture 为这类评估提供了可供审查的具体基础设施设计。利用它要求对一个实际问题作出明确回答：当代理独立工作时，哪些决策仍由你的组织掌控？