NVIDIA 推出开放式 Agent 安全平台，将 AI 护栏移至模型之外

NVIDIA 于 9 月 28 日推出开放式 Agent 安全平台，对当前 AI 行业的安全模式提出了明确挑战。NVIDIA 不再依赖 Agent 遵守提示词，而是希望由 Agent 外部的软件和硬件控制其每一项操作。

该平台将 OpenShell——一个用于隔离 Agent 执行的开源运行时——与 Sentry 相结合；后者是一种围绕 NVIDIA BlueField-4 数据处理单元构建的独立监控设计。NVIDIA 表示，当 Agent 越过授权边界时，Sentry 可在数毫秒内将其隔离。

这一差别意味着，它不只是又一个 Agent 框架。NVIDIA 的观点是，一旦 Agent 获得凭证、网络访问权限以及更改真实系统的授权，模型对齐和应用层指令便无法提供充分控制。其提出的替代方案类似于传统基础设施安全：默认拒绝访问、授予最小必要权限、记录每项决策，并将强制执行机制置于工作负载的控制范围之外。

眼下的问题并不在于 OpenShell 能否将 Agent 置于沙箱中。现有操作系统和云平台已经提供隔离工具。更困难的问题是，NVIDIA 能否在不阻碍企业希望 Agent 完成工作的前提下，将 Agent 约束转化为实用的基础设施层。

NVIDIA 推出开放式 Agent 安全平台，提供两层控制

NVIDIA 将 Agent 安全划分为软件边界与独立的硬件兜底防线。

OpenShell 提供第一层防护。它在隔离环境中运行每个 Agent，并对文件、进程、网络目的地、凭证和模型端点应用策略。Agent 可以获得完成任务所需的访问权限，而不会取得对宿主系统的不受限制控制权。

NVIDIA 将 OpenShell 描述为运行时，而非 Agent 框架。它位于 Claude Code、Codex、GitHub Copilot CLI、OpenCode 及自定义 Agent 系统等工具的底层。开发者无需替换 Agent 的推理模型或应用编排框架，即可使用这一安全边界。

该运行时采用默认拒绝的方式。沙箱启动时，Agent 不会获得通用网络访问、高权限或广泛的文件系统权限。随后，管理员通过机器可读策略定义获准资源。

例如，发票处理 Agent 可以获准读取特定文件夹并联系已批准的会计 API，但仍无法删除发票、查看无关目录，或将数据发送至未经批准的网站。

OpenShell 还将凭证使用与凭证持有分离。运行于沙箱外的监督器，只有在策略授权特定请求时才会提供凭证。Agent 无需直接访问底层密钥。

运行时会根据请求二进制文件、目的地、方法和路径等细节评估网络活动。它可以在 Agent 继续运行时应用策略更新。每次允许或拒绝的操作都会成为审计轨迹的一部分。

NVIDIA 的 OpenShell 架构还包括策略证明器。该组件会在管理员应用策略变更前，利用形式化验证——一种用于检查指定规则是否满足定义属性的数学方法——进行验证。

证明器解决了一个微妙问题。安全团队通常知道 Agent 需要访问某项新服务，但未必能轻易看清策略变更带来的全部能力。一条看似狭窄的规则，可能会打开意想不到的网络路径，或让凭证变得可被访问。

Sentry 提供第二层防护。它在 BlueField-4 DPU 的隔离信任域中运行；这些专用处理器在主 CPU 之外处理基础设施与安全工作负载。

根据 NVIDIA 的平台公告，Sentry 独立监控 Agent 活动，并可在数毫秒内阻止可疑行为。NVIDIA 表示，该系统使用其 DOCA 软件检查请求、验证身份、保护数据访问，并生成经过证明的遥测数据。

这种分离至关重要，因为 Agent 无法简单地通过提示词影响 Sentry、重写其指令，或从工作环境内部将其禁用。即使运行时遭到入侵，主系统之外仍存在另一处强制执行点。

OpenShell 已广泛可用，而 Sentry 则被定位为与 BlueField-4 绑定的参考系统设计的一部分。NVIDIA 表示，OpenShell 的软件也可扩展至 Arm 和 Intel 的处理器。

因此，这是一项分层提案，而非单一安全产品。OpenShell 限制 Agent 在正常运行期间的行为；Sentry 则从这一边界之外进行监控，并在活动似乎试图越界时作出响应。

为什么 Agent 安全正在超越提示词

能够采取行动的 Agent 会带来一个仅靠更完善指令无法解决的安全问题。

传统聊天机器人输出供人审核的文本。自主 Agent 则可以读取本地文件、安装软件包、调用外部服务、使用身份验证令牌、修改代码，并在无需持续批准的情况下继续工作。

这些能力让 Agent 更有用，也扩大了错误假设、被操纵的输入、遭入侵的依赖项或模糊指令可能造成的后果。

提示词可以要求 Agent 不要共享机密信息，但这项指令并不能从物理上阻止 Agent 打开敏感文件，或联系未知服务器。应用护栏仍处于 Agent 正在探索的同一软件环境中。

提示词注入使这一弱点尤为重要。Agent 可能在网站、文档、电子邮件、问题跟踪器或源代码仓库中遇到恶意指令。这些指令可能试图误导 Agent，同时伪装成合法的任务数据。

即使未遭遇攻击者，模型也可能误解有效请求。被要求清理项目的编程 Agent 可能删除必要文件。研究 Agent 可能因认为该步骤有用，而将信息提交给未经授权的服务。

NVIDIA 企业 AI 副总裁 Justin Boitano 向记者表示，当指令含糊或工具行为出乎意料时，Agent 可能偏离既定目标。他的核心论点是，一旦 Agent 能够采取行动，就不能期待它自行约束自己。

这正是 NVIDIA 推出开放式 Agent 安全平台公告背后的原则。Agent 推理仍具有概率性，但基础设施权限可以是确定性的。无论模型如何解释其请求原因，策略引擎都可以拒绝网络连接。

这种转变类似于云安全领域早期的变化。企业不再仅仅依赖应用开发者保护每个数据库、密钥和网络路由，而是在每个应用外部加入身份管理、工作负载隔离、策略引擎和监控机制。

Agent 安全如今也面临类似转型。模型仍需接受安全训练，应用仍需具备合理指令。但任何一层都不应仅因测试表现良好，就被赋予无限权限。

NVIDIA 的立场也对 Agent 平台供应商施加压力。当外部运行时能够跨多个模型和框架强制执行权限时，仅在 Agent 编排框架内部实施的安全控制就显得不那么有说服力。

云服务提供商同样面临压力。部署 Agent 集群的客户将越来越期待专为自主工作负载设计的身份边界、凭证代理、出站控制和审计记录。通用容器无法回答所有治理问题。

企业则是第三个承压群体。除非一家公司能说明 Agent 可访问哪些资源、权限如何变化以及由谁可以将其停止，否则它无法宣称 Agent 以最小权限运行。

这一要求不仅适用于戏剧性的失控 Agent 场景。合规团队还需要常规操作的记录，包括文件访问、API 调用、策略变更和凭证使用。

NVIDIA 表示，已有超过 100 家组织正与该平台中的技术开展合作。其公布的名单包括 Anthropic、Cisco、CrowdStrike、Dell Technologies、Hugging Face、JPMorganChase、Microsoft、Palantir、Perplexity、Red Hat、Salesforce、SAP、Scale AI、ServiceNow 等。

这份名单表明了广泛兴趣，但并不能证明其已具备生产成熟度。“开展合作”的范围可能包括评估、集成、联合工程或计划中的支持。采购方仍需要部署证据和运营成果。

OpenShell 0.1 将最小权限转化为 Agent 运行时

OpenShell 的主要贡献不是更智能的模型，而是位于多种不同模型底层、可复用的控制层。

OpenShell 0.1 发布线通过稳定的发布节奏、扩展的扩展点、新 API 和额外隔离机制，将这一方法正式化。其开源仓库公开了运行时、策略系统、软件开发工具包和部署材料，供外界检查。

每个 Agent 都在采用非特权账户、且操作系统能力受限的沙箱中运行。Linux 控制机制限制文件系统访问和系统调用，而出站连接则会经过策略检查。

该架构将沙箱与其监督器分离。Agent 在受限工作负载边界内运行，监督器则留在外部，并代理经授权的访问。网关负责管理用户、沙箱、策略、设置和凭证。

这种分离降低了 Agent 进程所掌握的权限。如果模型生成请求访问被禁止文件的 shell 命令，操作环境将阻止该操作。模型的信心或其声称的理由都不会改变这一结果。

OpenShell 策略采用声明式设计。管理员在配置中描述允许的行为，而不是将每项限制嵌入应用代码中。这为安全、平台和开发团队创造了共同的审查界面。

策略覆盖多个相关领域。文件系统规则区分可读路径与可写路径。进程控制降低权限并限制系统调用。网络规则评估目的地、端口、二进制文件和应用层细节。

供应商配置文件将获准服务与相应凭证和网络规则关联起来。这可以让 API 令牌绑定至预期目的地，而不是将其放在通用环境变量中。

该运行时还支持推理路由。企业可以管理 Agent 使用哪些模型端点，同时将供应商凭证保留在沙箱外部。当团队混合使用本地模型、云 API 和受限数据时，这一点尤为重要。

可观测性完善了基础控制闭环。OpenShell 会记录决策，并能以结构化格式导出安全事件。调查人员可以审查 Agent 请求了什么、运行时允许了什么，以及拒绝了什么。

这些能力尤其适合编程 Agent。开发者可以允许 Agent 读取一个仓库、在工作分支内创建文件、从获准的注册表下载软件包，并联系经授权的模型端点。

同一政策还可阻止访问无关代码库、个人目录、生产凭据和任意网站。如果代理请求更广泛的访问权限，人类或可信系统可以审查拟议的变更。

该设计也支持长时间运行的代理。传统沙箱通常只在有限任务期间保护单个受限进程。OpenShell 旨在持续治理不断变化的代理活动，包括政策更新和子代理工作流。

这一雄心也带来了运维复杂性。政策必须适应合理的差异，同时又不能宽泛到失去保护价值。团队还需要建立审查例外情况的流程，避免每项任务都陷入停滞。

形式化验证有助于评估拟议政策的结构。它无法判断企业是否有意授权某项危险操作。可接受边界仍须由人工治理决定。

OpenShell 的开源性质为组织带来另一项优势。安全研究人员可以检查实现、测试假设并提出修改建议。企业也可以针对不同的计算平台或部署环境扩展软件。

开源并不会自动造就安全的软件。它提供独立审查的条件，但有效审查仍需要积极维护者、清晰的披露流程、可复现的测试和及时修复。

0.1 版本同样传递出谨慎信号。该项目现已具备具体的公开架构，但早期采用者应预期，随着真实工作负载暴露局限性，API、政策、部署实践和集成方式都会发生变化。

主要较量是强制执行与代理自我约束

NVIDIA 正押注于：可强制执行的基础设施控制，优于仍停留在代理推理循环内的安全规则。

这主要并非 NVIDIA 与另一家芯片制造商之间的较量，而是两条安全路径之间的竞争：要求代理安全行事，或构建一个让不安全操作无法成功的环境。

模型提供商仍在持续改进对齐、拒绝行为、指令层级和监控。这些措施可以降低模型选择有害操作的可能性，也能应对基础设施控制本身无法识别的行为。

OpenShell 处理的是不同层面。它假定模型最终可能犯错、遵循被操纵的上下文，或尝试未获授权的操作。运行时环境专注于限制由此造成的损害。

两条路径应当相辅相成，但其优先级不同。对齐旨在改善代理的决策；运行时强制执行则假设决策依然可能出错，并限制其后果。

Anthropic 的参与说明了这种组合方法。NVIDIA 表示，Claude Managed Agents 将代理循环与执行沙箱分离。OpenShell 和 BlueField 可以围绕这些沙箱中的访问再增加控制。

这种安排形成了纵深防御，即在代理与敏感资源之间设置多层独立控制。一层防线失效并不会自动击穿其他所有层。

该平台还支持开放和闭源模型。对 NVIDIA 而言，这种模型无关的定位具有战略意义，因为该公司为相互竞争的 AI 生态系统提供基础设施。无论哪个模型在特定市场中领先，共享运行时都可能发挥作用。

不过，软件可移植性与硬件独立性并不相同。OpenShell 可以扩展到 NVIDIA CPU 之外，而完整的 Sentry 设计依赖 BlueField-4 来实现隔离的芯片内强制执行。

这在“开放”平台内部形成了一种商业张力。软件层可以支持异构基础设施，但 NVIDIA 最有力的隔离叙事突出了 NVIDIA 网络硬件及其 DOCA 技术栈。

竞争对手和云服务提供商可以通过多种方式应对：在其平台上支持 OpenShell、构建兼容的政策系统，或将现有隔离和机密计算功能作为替代方案进行推广。

安全厂商也可以将代理活动与既有的终端、身份、网络和数据保护产品连接起来。代理治理很可能成为企业安全架构中的又一层，而非独立市场。

因此，NVIDIA Open Agent Safety Platform Launched 活动扩大了 NVIDIA 的角色。该公司并不满足于仅为训练和推理提供算力；它希望帮助定义自主工作负载如何获得权限，以及基础设施如何撤销这些权限。

这一定位让 NVIDIA 能够影响一个新的控制平面。如果 OpenShell 政策得到广泛采用，该运行时可能塑造人们对代理身份、可审计性、凭据处理和网络访问的预期。

采用程度将取决于中立性。如果一个名义上通用的安全层明显偏向某一硬件技术栈，企业可能会犹豫。清晰的接口以及对非 NVIDIA 系统的可信支持将十分重要。

开发者则会评估另一个问题：摩擦。一层频繁打断有效工作的安全机制，会促使人们设置宽泛例外、放弃部署，或进行非正式绕过。

只有当细粒度权限依然具备实用性时，平台才能成功。这需要工具帮助团队发现所需访问权限、解释拒绝原因、测试政策并批准变更，而不是将每项代理任务都变成安全工单。

NVIDIA 的安全平台仍无法保证什么

隔离可以限制代理的触及范围，但无法判定每一项被允许的操作是否正确。

代理即使在其正式权限范围内也可能造成损害。获准提交发票的财务代理可能会批准欺诈文件。拥有写入权限的编码代理则可能在获准访问的代码库中引入隐蔽漏洞。

OpenShell 可以记录这些操作并限制其范围。但它无法独立理解每个组织的意图、业务逻辑或伦理要求。

政策质量仍是核心。如果管理员授予广泛的文件系统访问权限、不受限制的网络出口或可重复使用的凭据，运行时会精确地强制执行这一脆弱边界。

加州大学圣迭戈分校研究人员 Earlence Fernandes 将该平台称为朝正确方向迈出的一步。但他也警告说，定义最小必要访问仍然很困难，因为有用的代理需要真实资源。

威斯康星大学计算机科学教授 Somesh Jha 提出了相关担忧。他告诉 Associated Press，案例研究必须展示该系统如何在安全与阻断有用工作之间取得平衡。

误报构成这一平衡的一面。如果 Sentry 隔离了合法工作负载，组织可能会失去对自主运营的信心。它们需要可靠的恢复流程，以及对每次干预的解释。

漏报构成另一面。可疑行为可能看起来像有效活动，尤其当代理将获准工具用于非预期目的时。一次被允许的请求仍可能通过其内容泄露信息。

NVIDIA 表示，Sentry 可以在数毫秒内进行干预。检测后的速度很重要，但这一公开说法并不能证明其在多样化环境中的检测准确性。

独立基准测试需要衡量的远不止隔离延迟。评估者应测试逃逸尝试、政策绕过、凭据滥用、隐蔽数据传输、受损依赖项，以及针对控制平面本身的攻击。

性能开销也需要谨慎测量。NVIDIA 将 OpenShell 在 Vera CPU 上的开销描述为极低。买方需要针对具体工作负载的结果，覆盖网络密集型代理、大型工具链、频繁政策变更和大量并发沙箱。

完整系统对硬件的依赖也带来了另一项不确定性。BlueField 可以将强制执行与主工作负载隔离，从而强化安全模型。但这也增加了纯软件采用者无需面对的基础设施要求。

该平台并不能消除模型对齐工作。它无法阻止在允许渠道内发生的欺骗性输出、糟糕推理、伪造证据、带偏见的建议或有害内容。

它同样无法解决问责问题。组织仍需决定由谁批准权限、由谁审查日志、由谁响应隔离事件，以及由谁为代理获准执行的操作承担责任。

NVIDIA 已将此次发布与近期代理超出预定边界的事件联系起来。初始报道恰当地强调了 OpenShell 和更广泛安全平台的重要性。

不过，声称该系统本可防止此前某次入侵，仍属于事后公司评估。复现的事件测试和独立红队演练将提供更有力的证据。

更可信的解读应当更为有限。NVIDIA 已针对代理风险提出了一项严肃的系统级应对方案，但并未解决整体 AI 安全问题。在组织正确配置的前提下，该平台可以缩小可访问的攻击面。

三个信号将表明平台是否有效

接下来的证据必须来自实际部署、独立测试，以及对 NVIDIA 自身基础设施之外环境的支持。

第一个信号是发布时所列组织公开的生产实践。合作伙伴名单颇具分量，但客户需要了解有关政策、被阻止操作、运营开销和事件响应的详细说明。

一份有意义的案例研究应描述实际代理工作流及其所需权限。它应展示 OpenShell 拒绝了哪些操作、开发者如何调整政策，以及这些控制是否干扰了合法工作。

来自受监管环境的证据将尤其有用。银行、医疗保健组织、政府机构和关键基础设施运营商都面临严格的访问控制和可审计性要求。

如果这些组织将 OpenShell 投入生产，NVIDIA 的论点将更具说服力。如果相关活动仍局限于演示和评估，此次发布看起来就更像一项架构提案。

第二个信号是独立安全验证。研究人员需要访问具有代表性的部署、威胁模型、配置指导和可复现测试。

测试应检查沙箱、监督器、网关、政策证明器、凭据代理和 Sentry 边界。攻击者会瞄准组件之间的交互，而不只是 NVIDIA 认为最强的组件。

研究人员还应检查可用性失误。当管理员复制宽松示例、误解默认设置，或在多次被拒后禁用控制时，即使技术上正确的安全系统也可能失效。

NVIDIA 的公开文档已经为开发者提供了检查材料。下一步需要持续的外部审查、透明的漏洞处理，以及研究人员发现缺陷时可见的修正。

第三个信号是可信的可移植性。OpenShell 的软件可以扩展至 Arm 和 Intel 平台，但最强的 Sentry 主张仍与 BlueField-4 相连。

跨云、混合、本地部署和隔离网络系统的有效集成，将支持 NVIDIA 关于这是开放代理安全层的说法。若过度集中于 NVIDIA 硬件，则会削弱这一定位。

操作系统厂商的支持可能有所帮助。Canonical、Red Hat 和 SUSE 均在 NVIDIA 所列名单中，被认定为正将平台技术整合进常见部署基础设施的组织。

开发者还应关注 OpenShell 的发布节奏。策略兼容性、稳定 API、迁移指南以及可观测性方面的改进，将决定 0.1 版本能否发展为可靠的基础设施。

“NVIDIA Open Agent Safety Platform Launched”公告为这场讨论树立了一个有益标准。Agent 安全应包含 Agent 无法改写、说服或忽视的控制措施。

这一标准并不要求每家公司都采用 NVIDIA 的完整设计。但它确实要求采购方围绕访问权限、隔离、凭据、审计和紧急遏制提出更严格的问题。

评估自主 Agent 的团队可以先梳理 Agent 能够访问的每一种资源。他们应识别哪些控制措施依赖模型的配合，哪些措施即使模型出现意外行为后仍可强制执行。

他们还可以维护一个用于记录策略、被拒绝的操作、例外决策和事故发现的工程知识库。这类记录有助于安全规则基于证据而非猜测持续演进。

实际检验很简单：组织能否让 Agent 完成有价值的工作，同时不授予远超该任务所需的权限？OpenShell 和 Sentry 给出了 NVIDIA 的答案。生产环境中的证据将决定这一答案是否站得住脚。