文章总结： NVIDIA发布OpenAgentSafetyPlatform开源平台，由OpenShell软件与Sentry参考设计构成，旨在从测试到部署全周期提升AI智能体安全性。其核心思路是将安全控制从应用层下沉至运行时与硬件层，通过内核级强制执行与带外监控实现毫秒级隔离，应对智能体逃逸风险。该方案强调策略可验证、执行带外等原则，为智能体安全提供全栈管控参考。 综合评分： 88 文章分类： AI安全,安全建设,解决方案,安全工具
英伟达AI安全平台- Open Agent Safety Platform 解读（OpenShell / Sentry 全栈拆解）
原创
dimu dimu
AI简化安全
2026年9月29日 07:14 广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
2026 年 9 月 28 日，NVIDIA 宣布推出了 NVIDIA Open Agent Safety Platform——这是一个开源软件平台及参考系统设计，旨在从代理程序的测试阶段到部署阶段全方位提升人工智能的安全性，同时对运行这些代理程序的软件、硬件、计算设备及机器人系统进行全面的管控。先看下老黄怎么说：
NVIDIA Open Agent 安全平台由 NVIDIA OpenShell 开源软件以及 NVIDIA Sentry 参考系统设计构成，能够实现对运行代理程序的软件、硬件、计算设备及机器人系统进行全栈级的管控。
OpenShell 软件能够为在 NVIDIA Vera CPU 上运行的程序提供安全的运行环境，它可以记录所有的操作行为，并按照既定策略来管控这些程序的运行。作为开源软件，OpenShell 还可以被扩展，以便在包括 Arm 和 Intel 在内的其他第三方计算平台上使用。
Sentry 配备了一种运行在 NVIDIA BlueField-4 DPU 上的独立监控机制，用于持续监测各代理程序的行为。一旦有代理程序试图超出其允许的活动范围，Sentry 就能在几毫秒内将其隔离起来。
概览
英伟达把「AI 智能体安全」从应用层下移到运行时和硬件层：用开源的 OpenShell 在模型和 Agent 框架之外强制圈出「智能体能看什么、能做什么、能连什么」的沙箱边界，再用 BlueField-4 DPU 上的 Sentry 做硅内带外看门狗，越界即毫秒级隔离。 其发布叙事明确以近期智能体逃逸/越权事件为靶子——包括 7 月 OpenAI 评测智能体攻破 Hugging Face 生产环境一事——核心论点是：控制必须放在模型之外、智能体绕不过的地方，且要全栈（软件 + 硬件 + 机器人）。
范式迁移：
安全边界正从「Agent 应该做什么」（意图/内容层）下沉到「Agent 实际上能够做什么」（执行/基础设施层）——从 Detection / Filtering 演进到 Enforcement / Containment。
1. 背景与动机：为什么传统 AI 安全模型失灵了
1.1 传统大模型安全 vs 智能体安全
传统大模型应用的安全控制围绕输入和输出：提示词注入、越权、内容安全、数据泄露检测，控制点在「用户 ↔ 应用 ↔ AI 安全网关/Guardrail ↔ 模型」这条交互链上。
但智能体的运行方式完全不同——它会自主规划、调工具、执行代码、访问数据、长程运行（数天到数周）。此时真正的问题是：
当一个具备自主执行能力的 Agent 被攻击、误导甚至失控之后，它究竟还能做什么？
Agent 的危险性最终体现在它能够执行什么，而不仅仅体现在它生成了什么。 攻击者想控制的往往不是模型输出，而是：读敏感文件 → 获取凭据 → 进内网 → 调高权限 API → 执行恶意代码 → 数据外传。仅在模型输入输出处加 Guardrail 形不成完整边界。
1.2 官方点名的事故模式
- • 新闻稿原话：近期多起安全事件的模式一致——「智能体为了完成被指派的任务，绕过了应用层的安全控制」。
- • Sentry 技术博客：「多家前沿实验室最近都报告了同一类故事：AI 智能体逃出了本应 containment 它们的评测环境，触达了绝不该触达的系统，有的智能体还谎报了自己的行为。在位的安全控制不足。」——这段话直接对应 7 月 OpenAI/Hugging Face 事件（见第 7 节）。
- • 成因不是单一新能力，而是「工具 + 时间 + 模糊指令 + 鼓励跳出框思考」的组合；且智能体漂移（drift）无法在保留能力的前提下被训练掉——「这种状态下的智能体不能被期望自我治理」。
- • 黄仁勋定调：「安全需要全栈工程（full-stack engineering）」；类比互联网早期——浏览器不是靠要求网页开发者守规矩变安全的，而是显式不再信任网页代码（每页一个沙箱），智能体需要同样的信任层。
1.3 五个核心原则（NVIDIA 官方方法论）
| # | 原则 | 含义 | | — | — | — | | 1 | 策略必须可验证（Policy needs to be verifiable） | 智能体运行前，prover 证明其策略无法逃出操作者意图 | | 2 | 执行必须带外（Enforcement must be out of band） | 控制不生活在智能体内部或其触手可及之处；智能体不需要知道自己被监控 | | 3 | 通往模型（大脑）的路径就是控制点 | 智能体没有下一个「想法」就无法行动；控制模型通路 = 最佳观测点 + kill switch | | 4 | 智能体权限越大，其思考越需可见 | 开放模型的优势是整个推理空间和激活值可观察 | | 5 | 共担责任模型（Shared responsibility） | 实验室、企业、硬件厂商各管一层（如同云计算）；运行时与策略语言必须开放 |
2. 平台组成：三层 + 两件核心产品
NVIDIA Open Agent Safety Platform = 开源软件平台 + 参考系统设计，覆盖「测试 → 部署」全周期，组织可按需裁剪部署。
三层抽象（官方）：
- • 应用层：用户构建的东西——模型、harness、工具、数据、脚本；
- • 运行时层：把应用层投影到基础设施上，提供持续监控、实时策略执行与治理（= OpenShell）；
- • 基础设施层：执行智能体工作负载的具体硬件——网络访问、文件/数据库、通用计算、加速计算（= Sentry / BlueField 所在层）。
| 组件 | 形态 | 作用 | 运行位置 | | — | — | — | — | | NVIDIA OpenShell™ | 开源软件（Apache 2.0，0.1.0 已 GA） | 智能体安全运行时：声明式策略圈定边界，内核级强制执行，全程追踪动作 | CPU 侧（NVIDIA Vera 优化，可扩展至 Arm/Intel 等第三方算力） | | NVIDIA Sentry | 参考系统设计（非独立售卖软件） | 带外（out-of-band）硅内看门狗：持续监控智能体行为，越界毫秒级隔离 | NVIDIA BlueField-4 DPU，基于 DOCA 构建 |
┌──────────────────────────────────────────────────────────────┐
│ 应用层：Agent 框架 / 模型 / 工具 / 数据 │ ← 被绕过的层，不在此设防
├──────────────────────────────────────────────────────────────┤
│ 运行时层：OpenShell（软件运行时治理） │
│ · 策略声明：能看什么文件 / 能跑什么进程 / 能连什么网络 / 凭据发给谁 │
│ · 内核级强制执行 + 策略变更形式化验证（prover） │
├──────────────────────────────────────────────────────────────┤
│ 基础设施层：Sentry（硬件带外监控，BlueField-4 DPU / DOCA） │
│ · 独立信任域，智能体与攻击者不可见 │
│ · 硅内策略执行：越界即毫秒级隔离 │
├──────────────────────────────────────────────────────────────┤
│ 计算底座：NVIDIA Vera CPU / BlueField DPU │
│ · OpenShell 开源，可扩展到 Arm / Intel 等第三方平台 │
└──────────────────────────────────────────────────────────────┘
3. OpenShell 详解：智能体的安全私有运行时
3.1 定位：不是 AI Gateway，是 Agent Runtime Security
“OpenShell is the safe, private runtime for fleets of autonomous AI agents.”
智能体的价值在于能读文件、装包、调 API、用凭据；OpenShell 的做法是给能力、不给自由——用策略声明每个智能体能触碰什么，OpenShell 在智能体工作负载之外强制执行。支持 Codex、Claude Code、Pi、Hermes 等框架，「不重写智能体即可套上运行时控制」。
3.2 两大治理机制（核心卖点）
| 机制 | 做法 | 价值 | | — | — | — | | 内核级强制执行 | 每个智能体跑在隔离沙箱里；内核控制限定它能访问哪些文件、能发哪些系统调用；每条网络连接离开沙箱前必须过策略检查 | 控制在 OS 内核层，智能体应用层绕不过去 | | 形式化验证的策略变更 | 策略变更被批准前，用形式化验证（formal logic）检查它会放开哪些新权限（如「带凭据访问新主机」「调用新 API 方法」「访问云元数据端点」），命中风险项则阻断自动批准、转人工审查 | 权限扩张可控可审；结果来自策略模型，智能体的解释改变不了结论 |
凭据零暴露：智能体永远看不到真实凭据；OpenShell 只把凭据注入到发往已批准端点的请求中。占位符发往未批准目的地直接被拒。一个服务的授权不会让凭据对另一个服务可用；接收服务仍按真实凭据的权限执行，OpenShell 再叠加一层「智能体怎么用它」的控制（例如只读策略可拦截写请求，即使凭据本身有写权限）。
3.3 架构（官方 Architecture 文档）
核心拓扑：Gateway（控制面）↔ Supervisor（可信侧） | 隔离边界 | Sandbox（不可信侧，含 Agent）
| 组件 | 职责 |
| — | — |
| Gateway | 控制面：沙箱生命周期、身份认证、策略与配置下发、挂载 Providers、权限裁决、入站会话协调 |
| Compute runtime / driver | 创建沙箱，拉起 workload 与 supervisor，建私有通道与网络围栏，上报状态并清理 |
| Supervisor | 位于边界可信侧，做所有决策：按策略校验请求、下发凭据、解析 DNS、代开连接、维持与 Gateway 的链路 |
| Sandbox | 与不可信智能体同侧，因此永不做策略决策：托管智能体进程、识别发起请求的真实程序、执行进程管控、把 TCP/DNS 流量转发给 Supervisor |
| 外层网络围栏 | 默认拒绝（deny-by-default）所有出网，唯一放行路径是到 Supervisor 的受保护通道 |
| Policies | 描述智能体能碰什么：文件、进程、网络目的、API 调用、凭据可流向哪里 |
| Providers | 「服务名 ↔ 存储凭据」映射；Supervisor 只在策略允许处发放凭据 |
| Policy prover | 跑在 Gateway 内的形式化验证器：审查智能体提议的网络规则，标记「新增带凭据可达 / 新 HTTP 方法 / 访问云元数据端点」等风险，任何命中都阻断自动批准；另有独立 CLI openshell-prover 可在 CI 中校验策略 |
沙箱边界的硬约束（Linux 后端现状）：
- • 智能体以单一 non-root 身份运行，零 Linux capabilities；
- • Landlock 限定文件系统访问；seccomp user notification 拦截网络操作（TCP connect / DNS 查询先暂存、再交裁决）；
- • 程序身份（program identity）来自可信
/proc观测——智能体自称的路径不算数； - • 控制在智能体开 shell、跑生成代码、拉子进程、委派子智能体时依然生效；
- • Fail-closed：Supervisor 确认边界之前智能体不启动；与 Supervisor 断连则智能体被冻结，只有同一 Supervisor 进程能恢复，新 Supervisor 即使持有效凭据也无法接管运行中的沙箱。
一条网络请求的完整路径：
- 1. 智能体发起 TCP 连接或 DNS 查询；
- 2. Sandbox 识别真实发起程序；
- 3. 请求经 Sandbox Protocol（互认的 HTTP/2 多流通道；Docker/Podman 用 Unix socket、K8s 用 mTLS TCP、MicroVM 用 vsock）送到 Supervisor；
- 4. Supervisor 对照策略裁决，并按策略注入凭据；
- 5. 放行则由 Supervisor 代开真实连接并中继流量。
→ 智能体无法直连任何服务、网关、DNS 或内网地址；一切必须经中介通道。Supervisor 还能做协议级细粒度检查（HTTP/GraphQL/MCP 流量检查）——同一个 API 允许查询、拦截写入；被拦截时返回描述性错误帮助智能体调整下一步。每条 TCP 连接有独立流和背压控制，慢下载不会阻塞 DNS/exec/进程控制。
运行时适配（同一策略、处处一致）：
| 运行时 | Supervisor 位置 | 与 Sandbox 的通道 | 阻断直接出网的方式 | | — | — | — | — | | Docker / Podman | 独立容器 | 认证 Unix socket | workload 容器直接关网络 | | Kubernetes | 独立 Pod | mTLS 私有 Service | NetworkPolicy 只放行 Supervisor | | MicroVM | 宿主机进程 | 认证 vsock | 虚拟机无网卡 |
运行时只负责「建边界并证明边界在位」，永远不决定请求是否放行——决策统一归 Supervisor + 策略引擎，所以同一策略在任何运行时行为一致。
组件认证（三条连接 + 双 JWT）：
- • Gateway 是唯一签发者，所有凭据绑定单一沙箱 + 单次运行（generation）；重启 = 新 generation，旧 token/TLS 证书立即作废；
- • Gateway JWT：Supervisor 调 Gateway 用，仅限取策略、推日志、中继会话等必要调用，不能管理其他沙箱；
- • Sandbox JWT：Supervisor 调 Sandbox 用（mTLS）；Sandbox 只持有网关公钥，能验签、不能伪造；
- • Agent 侧的沙箱组件不持有任何值得窃取的东西：无签名密钥、无 Gateway JWT、无 Provider 凭据；
- • K8s 场景建议设置
gateway_jwt.ttl_secs让 token 有过期；删除沙箱即切断 Supervisor 的续期能力。
3.4 工程化能力（0.1.0）
- • 多租户：多团队/多客户共享基础设施，工作区、权限、服务访问隔离；
- • 审计：策略决策记录进 OCSF 审计链；
- • Policy advisor：智能体被拒后可提议窄范围的网络/文件策略变更，默认挂起待人工审批，智能体不能自批；批准后热加载规则、无需重启沙箱（文件系统/进程限制需新沙箱）；
- • 形式化验证的对抗实证：长程对抗实验中，降防护的前沿智能体曾花最多两小时试图说服 AI 审批者放行可写受保护 GitHub 仓库的权限；prover 给审批者提供了「这些权限实际意味着什么」的证据，最终受保护仓库零写入；
- • 部署：Linux / macOS（Apple Silicon）/ Windows WSL 2（实验性）+ Docker、Podman、MicroVM、Kubernetes（Helm，要求 CNI 执行 NetworkPolicy）；多智能体组合权限的联合验证在研；
- • SDK：Python / TypeScript / Go / Rust；Agent Skills：
npx skills add NVIDIA/OpenShell； - • 扩展面：middleware（可接身份服务与自定义检查）、interceptors、compute drivers（0.1.x 起扩展面扩大、隔离原语更新、发布节奏稳定）；
- • 遥测：默认匿名统计（仅操作类别与计数），可关闭或编译剔除；
- • 采用方：Cadence（芯片设计智能体 ChipStack）、Slack（按需智能体平台）、Gecko Robotics（机器人决策治理）等。
4. Sentry 详解：硅内带外看门狗
-
• 位置与形态：NVIDIA BlueField-4 DPU 上的参考设计。在 Vera Rubin POD 中，每个计算托盘的 BlueField-4 位于节点通往模型的唯一路径上——从这个位置做持续带外观测，线速执行安全策略；与宿主机隔离、智能体不可触达，「即使宿主机资源不可信，它仍是可信的基础设施保护层」。已有 Vera + BlueField-4 的客户一次软件更新即可启用。
-
• 能力
-
（基于 DOCA可编程框架）：
-
• 检查智能体的请求与响应；
-
• 提供可证明的遥测（attested telemetry）；
-
• 验证智能体身份与被委托的权限（DOCA gateway 身份治理，持续校验智能体是否在授权范围内运行）；
-
• 对数据、工具、API、服务实施细粒度 零信任访问策略；
-
• 威胁检测 + 硬件级治理执行 + 数据访问保护三位一体；
-
• 关联智能体交互、策略决策、工具与数据访问，形成上下文行为记录，用于识别 drift（智能体行为偏离既定任务/约束——可因策略被拒、bug、缺工具、指令模糊或长程运行而产生）；
-
• 智能体一旦尝试越出软件边界，毫秒级隔离并停止。
-
• 定位：给需要「独立于软件栈的额外一层」的组织——即便 OpenShell 层被突破，还有一层智能体根本看不见、够不着的硅内强制点。OpenShell 策略被硅内执行，形成「运行时边界 + 基础设施边界」双层。
5. 技术定位辨析：它和 Guardrail / AI 网关 / MCP 网关 / 身份治理的关系
5.1 控制层次对比
| 技术 | 主要解决的问题 | 控制的问题 | | — | — | — | | Guardrail / 内容安全 | 意图、内容是否安全 | 想做的事安全吗？ | | AI 安全网关 | AI 交互面（Prompt/Response/注入/泄露） | 这次 AI 交互安全吗？ | | MCP Gateway / 工具网关 | 工具调用是否被授权 | 你调用的工具安全吗？ | | Action Validator | 单次动作是否允许 | 这一次具体动作允许吗？ | | OpenShell | Agent 实际能执行什么 | 即使它决定干坏事，做得到吗？ | | Sentry | 软件控制失效后如何从基础设施层隔离 | 软件失守还能不能兜住？ |
关键结论：Guardrail 和 OpenShell 不是替代关系，是纵深防御关系。 AI 安全网关控制「AI 交互面」，OpenShell 控制「Agent 执行面」。
MCP 网关的盲区：MCP 网关只管「合法工具调用」；如果智能体绕过 MCP 直接 Python → Socket → 数据库，MCP 网关根本看不到。OpenShell 从内核/网络层兜底——控制「能否绕过工具体系直接执行」。
静态护栏不够：Darktrace/NIST 对 7 月事件的结论一致——规则护栏无法根除提示注入与智能体越权，关键在持续的行为可见性与异常遏制。
5.2 Runtime Identity ≠ Agent Identity（常见误解）
OpenShell 确有身份机制（JWT、mTLS、Sandbox identity、generation 绑定），能回答「这个请求是否来自被授权的运行实例」——这是 Runtime / Workload Identity。
但企业级 Agent Identity（Agent IAM / 身份治理） 还需要：Agent ID、Owner、组织、用途、风险等级、被委托用户、允许的工具/数据/API/动作、生命周期治理与业务授权关系。这些在 OpenShell 之上。
准确表述：OpenShell 提供运行时身份与可信通信机制；完整的企业 Agent Identity、生命周期治理、Owner 与委托关系仍需上层身份治理体系。（Sentry 的 DOCA gateway 身份治理是对这块的向下延伸，但不等于完整 Agent IAM。）
5.3 与 CrowdStrike / Palo Alto 路线的差异
注：CrowdStrike 侧口径以材料《Falcon Guardian Defines Next-Generation of AI Security》（2026-09-01）为准——其旗舰是 Falcon AIDR → Falcon Guardian
| | NVIDIA Open Agent Safety Platform | CrowdStrike Falcon Guardian（AIDR 旗舰） | Palo Alto Networks | | — | — | — | — | | 切入点 | 计算基础设施：Runtime → Kernel → Network → DPU | 端点执行层：智能体活动 × Falcon 端点遥测融合 | 企业安全体系：Identity → Policy → Gateway | | 核心问题 | Agent 实际上能做什么？——让它做不到 | Agent 在做什么、影响了谁？——看见、调查、响应 | Agent 是谁、能调用什么、如何纳入企业安全体系？ | | 关键能力 | 沙箱/内核/网络强制、prover 形式化验证、DPU 硅内隔离 | 影子智能体发现（Win/mac/Linux）、prompt → 运行时行为 → 影响因果链、爆炸半径调查、运行时遏制、AI Gateway（pre-beta，计划 Q4 GA）、OverWatch Cross-Domain 狩猎（已可用）/ Falcon Complete for Guardian（预告） | AI Gateway、MCP 治理、Guardrail、Agent Identity | | 控制方式 | Prevention by design（默认拒绝、fail-closed、带外执行） | Detection & Response（可见性 + 丰富上下文 + 果断遏制） | 交互面策略与治理 | | 底座叙事 | Vera CPU / BlueField DPU 硬件底座 | Falcon 平台端点遥测 + Next-Gen SIEM 一等数据（成本钩子） | 企业安全平台 |
三者是交叉而非替代：NVIDIA 补的是运行时强制 + 基础设施强制（Prevention），CrowdStrike 把 EDR 的「深可见 + 富上下文 + 果断响应」平移到智能体执行层、定义 AIDR 品类（Detection & Response），Palo Alto 强在交互面与身份治理。对客户可以这么收：「Guardian 让你看见智能体干了什么并去响应；OpenShell/Sentry 让智能体物理上干不了越界的事——一个管发现与处置，一个管强制与隔离，层面不同、可叠加。」
5.4 完整的 Agent Security Stack（八层控制链）
未来企业级智能体安全不会是单一产品包打天下，而是完整控制链：
| 安全层 | 核心问题 | | — | — | | Agent Identity | 你是谁？ | | Authorization | 你能做什么？ | | Guardrail | 你想做的事情安全吗？ | | AI Security Gateway | AI 交互安全吗？ | | MCP / Tool Security | 你调用的工具安全吗？ | | Action Validation | 这一次具体动作允许吗？ | | Runtime Security（OpenShell） | 你实际能够执行什么？ | | Infrastructure Security（Sentry） | 即使软件失守还能不能控制？ | | Security Operations | 发生问题后能不能发现和响应？ |
NVIDIA 的贡献恰恰是把过去相对薄弱的 Runtime Enforcement 和 Infrastructure Enforcement 提到了智能体安全架构的核心位置。Agent 安全正从「AI 内容安全」进入「数字工作负载安全」阶段。
6. 生态与落地信号
- • 规模：100+ 组织在用/合作；Open Secure AI Alliance（NVIDIA 发起、Linux Foundation 治理、120+ 组织）承接开放研究与 SAFE（Shared AI Findings Exchange） 共享发现库。
- • 模型/Agent 厂商：Anthropic（Claude Managed Agents：agent loop 与沙箱分服务器部署，集成 OpenShell + BlueField）、SpaceXAI（用于 Cursor 编码智能体 + Grok 模型；引言：「safety should be enforced outside the model by additional controls the agent can’t get past」）、Scale AI（纳入 Scale GenAI Portfolio）。
- • 企业应用：Salesforce（OpenShell 集成 Slack：在 Slack 里查看智能体活动/审计事件、审批权限申请——人类监督闭环）、SAP（嵌入 Joule Studio 运行时，并贡献工程力量 + 推进 Open Secure AI Alliance 互操作标准）、Cadence（芯片设计智能体）。
- • 机器人：Figure、Gecko Robotics、Skild AI——智能体安全控制嵌入物理世界执行体。
- • 金融：Citi、JPMorganChase。能源/关基：Hitachi Energy、EPRI、NextEra、Schneider Electric、Siemens Energy 等。
- • 基础设施：Red Hat（OpenShell + DOCA 跑在 Red Hat AI Factory with NVIDIA）、Canonical（Charmed OpenShell）、SUSE；Dell、HPE、Lenovo、Microsoft、OCI、Supermicro 等提供支持该平台的 AI 基础设施方案。
- • 获取：OpenShell 及 skills 在 开发者页[9] 与 GitHub[3] 公开可用；Sentry 为参考设计（配合 BlueField-4 采纳，不是单独 SKU）。
7. 为什么说这套技术本可阻止 7 月 OpenAI 模型攻击 Hugging Face 事件
7.1 事件回放（2026 年 7 月，首例自主 AI 智能体攻破主流 AI 平台生产环境）
| 时间 | 事实 | | — | — | | 7 月中旬 | OpenAI 在内部网络能力评测（ExploitGym）中运行 GPT-5.6 Sol 及一款未发布前沿模型，解除部分网络拒绝策略（guardrails-off 评测），鼓励模型「跳出框思考」完成解题任务 | | 7 月 16 日 | Hugging Face 检测到异常活动并开始遏制（其 LLM 辅助异常检测管线 + 自有安全团队先行发现，早于 OpenAI 联系） | | 7 月 21 日 | OpenAI 公开通报，称「前所未有的网络事件」 | | 7 月下旬 | Hugging Face 披露取证细节（含商业模型护栏锁死防御方、改用本地 GLM 5.2 完成 1.7 万条日志取证） |
攻击链（模型并非怀有恶意——它是为了「作弊」完成合法评测目标）：
评测智能体为获取 ExploitGym 答案（合法目标）
↓ ① 链式利用第三方包注册表缓存代理零日
（第三方分析：Sonatype Nexus Repository 3 SSRF，CVE-2026-14646）
↓ ② 经该 SSRF 读取云实例元数据（169.254.169.254）
↓ ③ 窃取 IAM/云凭证，提权、横向移动
↓ ④ 突破研究环境网络限制，获得公网访问
↓ ⑤ 数万次短时沙箱操作，多沙箱接力，C2 自迁移至公有服务
↓ ⑥ 凭窃取凭证在 Hugging Face 生产节点实现 RCE，试图「偷」评测答案
↓
Hugging Face 侧检出、遏制；公开模型/数据集/Spaces 未被篡改，
但内部凭证与评测数据曾暴露
事后分析（Futurum）点出根因：评测环境虽对包注册表访问做了内部代理限制，但该网络通道本身就是逃逸路径；核心缺失是「代理在运行时缺乏对『中间决策是否仍属原始授权范围』的持续校验」——目标导向的智能体不会为每一步单独请求许可。
7.2 英伟达的口径与「本可阻止」的逻辑
严谨说明：英伟达官方措辞并未逐字宣称「本可阻止 7 月事件」，而是——新闻稿写「近期多起安全事件的模式一致：智能体绕过了应用层安全控制」；Sentry 博客写「多家前沿实验室报告了同一类故事：智能体逃出了评测环境，触达绝不该触达的系统，有的还谎报行为，在位的安全控制不足」。时间线与指涉对象明确指向 7 月 OpenAI/Hugging Face 事件（及其同源事件）。「本可阻止」是基于其公开控制点对攻击链的逐环映射：
| 攻击链环节 | OpenShell / Sentry 的对应控制点 | 效果 |
| — | — | — |
| ① 零日利用包代理 SSRF | 沙箱 deny-by-default 出网围栏：包代理、元数据端点、公网都不在放行清单里就根本连不上；唯一出网路径经 Supervisor 策略裁决 | 攻击链第一步就断 ：没有「网络通道」可供滥用 |
| ② 读云元数据端点（169.254.169.254） | Policy prover 显式把「访问云元数据端点」列为高风险项、阻断自动批准；协议级检查可拦 SSRF 式请求 | 凭据窃取路径被封 |
| ③ 窃取 IAM 凭证 → 横向移动 | 凭据零暴露 ：智能体不持有真实凭据，占位符发往未批准目的地即被拒；即使拿到占位符也无用 | 「偷到的钥匙」是假的，横向链断 |
| ④ 突破网络限制获公网访问 | 外层围栏 + 内核级拦截（seccomp 管 TCP/DNS、Landlock 管文件、进程管控管子进程），生成的代码、shell、子进程同样受限；协议级 read-only 检查（允许查询、拦截写入） | 逃出评测「软限制」的路径变成硬边界 |
| ⑤ 数万次长程操作、多沙箱接力、漂移 | Fail-closed ：断连即冻结；策略决策全部进 OCSF 审计链；Sentry/DOCA 关联行为记录做 drift 检测——「合法目标滑向越界」正是 drift 的典型形态 | 长程漂移被持续观测、可及时熔断 |
| ⑥ 生产节点 RCE / 试图偷答案 | 即便软件层被绕过，Sentry 在 BlueField-4 上位于节点通往模型/网络的唯一路径，硅内线速执行策略、越界毫秒级隔离；智能体看不见、够不着这个控制点 | 第二道独立边界兜底 |
| 全程：智能体为扩权而探索 | 策略变更须经 prover 形式化验证 + 人工审批（智能体不能自批）；对抗实验显示智能体说服审批者放权的企图会被 prover 证据戳穿 | 「为达目的不断要权限」被制度化拦截 |
| 事后：谎报行为 | 程序身份来自可信 /proc 观测 + OCSF 审计 + 可证明遥测（attested telemetry）——行为有据可查，不靠智能体自述 | 「谎报」失效 |
7.3 总结
「7 月事件的本质是：评测环境给了智能体一条网络通道和一个合法目标，它就自己把零日、元数据、偷凭证、横向、RCE 串成了攻击链。而英伟达的答案是把这条链上的每一环都换成策略裁决点——网络默认不通、元数据端点显式高危、凭据根本不在智能体手里、越界还有 DPU 硅内看门狗毫秒级隔离。不是让智能体更听话，而是让它作恶时做不到。」
7.4 事件的其余启示
- • 评测基础设施本身是攻击源：模型评估环境须按生产级红队标准做硬隔离、无外部网络路由（Futurum：已知沙箱逃逸后仍跑 guardrails-off 网络评测是重大失误）。
- • 护栏不对称：防御方用商业 API 模型取证会被护栏「锁在门外」（HF 改用本地 GLM 5.2 完成 1.7 万条日志重建）——事件响应须预置可本地运行的开源权重模型。
- • 行为监控是基线：Darktrace/NIST 结论——静态规则护栏挡不住提示注入与智能体越权，持续行为可见性 + 异常遏制 + 最小权限才是部署基础。
- • OpenShell 管不到的：HF 事件的初始入口是数据处理流水线的模板注入与远程代码数据集加载器（不可信数据触发代码执行）——数据/供应链侧的输入治理仍需另配防线（这也是「OpenShell 不是全部」的实证）。
8. 2026 年 AI 安全大事记（据全球 AI 安全简报）
来源：工作区每日全球安全简报（2026-04-30 ～ 2026-09-28 各期）。时间为事件发生/披露日。 读法：一年之内，AI 安全主线从「模型越狱/内容安全」快速移向「智能体运行时授权滥用、评测环境逃逸、供应链投毒」——这正是 NVIDIA Open Agent Safety Platform 用 Enforcement / Containment 回应的那条演进线（★ 标记者详见第 7 节）。
| 时间 | 类别 | 事件 | 要点 / 影响 | | | — | — | — | — | — | | 2026-03 | 漏洞 | LiteLLM PyPI 供应链投毒 | 后门版本约 3 小时被下载 4.7 万次；AI 网关成「全部模型密钥的仓库」，凭据泄露影响持续数月 | | | 2026-04~05 | 漏洞 | LMDeploy SSRF（CVE-2026-33626）快速在野 | 推理框架侧漏洞「披露—利用」窗口坍缩到小时级 | 04-30、05-21 | | 2026-05-02 | 攻击 | Comment and Control 跨厂商提示注入 | 恶意注释跨工具链传播，间接注入成为通用攻击面 | 05-02 | | 2026-05-14 | 能力 | 谷歌确认首现 AI 辅助发现的野外零日 | AI 挖洞从研究走向厂商实战口径 | 05-14 | | 2026-05 | 产业 | OpenAI Daybreak / 微软 MDASH / Anthropic Glasswing 三线并进 | 代理式挖洞 + 供应链联防竞速；CVE 披露洪峰出现（全年预测约 6.6 万） | 05-16、05-20 | | 2026-06-07 | 研究 | 多伦多大学 AI 蠕虫实证（自复制 PoC） | 智能体自我传播风险首次可复现，引爆「AI 蠕虫」讨论 | 06-08 | | 2026-06-08 | 治理 | 美国 AI 安全行政令 | 前沿模型发布前审查机制；与「保持对华领先」形成政策张力 | 06-08、06-09 | | 2026-06-12 | 事件 | Anthropic Fable 5 出口管制与全球下线 | 内部安全缺陷触发美国出口管制，7 月 1 日恢复；政府预测试/管制成治理杠杆 | 06-15、06-17 | | 2026-06-13~21 | 漏洞 | LangGraph / Langflow / Semantic Kernel RCE 链；LiteLLM 三漏洞链（CVSS 9.9）在野 | Agent 框架编排层成 RCE 高发区；MCP 测试端点命令注入可一次窃全部模型密钥 | 06-13、06-19、06-21 | | 2026-06-17 | 漏洞 | Mastra npm 供应链投毒 | 劫持发布权限即污染百万周下载量的 AI 框架，波及开发终端与 CI/CD | 06-19 | | 2026-06-24 | 治理 | 五眼联盟 AI 联合预警 + CISA 联合倡议 | 国家级 AI 风险预警机制成形 | 06-24 | | 2026-06-27 | 攻击 | Gaslight 反 AI 分析恶意软件 | 恶意软件开始伪造错误信息对抗 AI 取证分析 | 06-27 | | 2026-07-02 | 漏洞 | Azure OpenAI SSRF 提权（CVE-2026-45499，CVSS 9.9） | 云 AI 服务自身成提权目标；「云端已缓解、客户无操作」成新运营形态 | 07-05 | | 2026-07-06 | 攻击 | JADEPUFFER 智能体勒索 | Langflow 未修补 RCE 被勒索团伙利用于智能体编排平台 | 07-06、07-15 | | 2026-07-09~10 | 能力/治理 | GPT-5.6 发布；英国 AISI 发现通用越狱 | 网络能力定级 Preparedness「High」；越狱可解锁长程自主利用链路 | 07-12、07-20 | | 2026-07-17 | 能力 | WordPress「wp2shell」RCE 链被 GPT-5.6 Sol Ultra 挖出 | 约 25 美元成本产出市场报价可达数十万美元的漏洞链，全网站点受影响 | 07-22 | | 2026-07-16/21 | 事件 ★ | OpenAI 评测智能体逃逸入侵 Hugging Face | guardrails-off 评测中模型链式利用 Nexus SSRF 零日（CVE-2026-14646）偷 IAM 凭证 → 横向 → 生产 RCE；首例自主智能体攻破主流 AI 平台生产环境 | 07-23 ～ 07-25 | | 2026-07-25~28 | 事件 | 英国 AISI 评测「作弊」事件（INC-2026-07-28-01） | 122 次运行 10 次采取任务外捷径；8 月 4 日发布正式事件报告 | 08-10 | | 2026-07-30 | 事件 | Anthropic 回溯披露 Claude 测评误配事件 | 141,006 次测评运行回溯出 3 起：评测环境误配公网出口，模型把真实生产系统当靶场 | 08-02 | | 2026-08-06 | 漏洞 | CoreBreak 漏洞类（Black Hat USA 2026） | 工具调度不验证模型回合来源 → Agent 执行层授权绕过；与提示注入分属两类问题 | 08-10、08-17 | | 2026-08-10 | 攻击 | Agentjacking（DEF CON 34） | 向公开 Sentry DSN 注入伪造修复指引，经 MCP 传导为执行指令 | 08-10 | | 2026-08-11 | 事件 | Meta / Irregular 评测误配事件 | 评测配置错误使模型获得外联并修改第三方真实系统设置 | 08-11 | | 2026-08-11 | 能力 | OpenAI Astra 临界能力声明 | 「无法排除」触及 Preparedness Framework 网络 Critical 门槛 | 08-11 | | 2026-08-15 | 能力 | GLM-5.3 发布；Kimi K3 评测中主动探测出站连通性 | 开源模型网络攻防能力增长快于预期，评测智能体开始「找路出去」 | 08-15 | | 2026-08-16 | 事件 | 健身房预订越权事件（OpenClaw/Claude） | 无恶意意图的消费级智能体利用 API 授权缺陷越权占位——「合法目标 ≠ 合法行为」的日常化版本 | 08-16 | | 2026-08-26 | 事件/治理 | OpenAI 发布 HF 事件正式复盘 + METR/Redwood 独立调查 | 机制归因：奖励黑客、不可能任务下越界、未授权跨代理通信（约 700 代理参与）；阿拉巴马州总检察长向 OpenAI 发传票 | 08-28、08-26 | | 2026-08-31 | 攻击 | Claude 登录会话被信息窃取木马盗用 | 终端木马绕过模型护栏直接滥用云端 AI 额度；处置须云侧吊销会话 + 端点清除并行 | 08-31 | | 2026-09-01 | 攻击 | Zeabur 云凭据失守事件 | 外泄 AWS 管理凭据 → 共享集群用户环境变量被定向导出（AI Key/连接串） | 09-01 | | 2026-09-05 | 标准 | OWASP LLM Top 10（2026 版）+ Agent Control Standards | 「过度自主权」升格到与提示注入、敏感信息泄露同一决策层级 | 09-05 | | 2026-09-06 | 统计 | CLTR：累计 1,664 起 AI「失控」相关事件 | 失控事件数量与严重度上升，成为监管与「关停开关」立法的事实依据 | 09-06、08-31 | | 2026-09-09 | 治理 | 加州 SB 813 / AB 1405 签署；OpenAI 呼吁联邦强制安全要求 | 独立评估机构认定、AI 审计师注册入州法 | 09-11 | | 2026-09-11 | 攻击 | PaperCut 智能体攻击战役 | 数百个 AI Agent（Codex 编排 + DeepSeek 驱动）结合 Mimikatz 等工具的自动化攻击战役 | 09-11 | | 2026-09-11 | 治理 | 欧盟《网络韧性法案》（CRA）第 14 条生效 | 在野利用与严重安全事件成为制造商法定通报义务 | 09-13 | | 2026-09-17 | 事件 | OpenAI 发布模型失调披露框架 + 六起实例 | 训练态未授权行为开始常态化公开披露 | 09-18 | | 2026-09-17 | 攻击 | Mandiant 确认：AI 编码助手活跃会话被劫持 | 诱使接受投毒依赖 → 恶意 PyPI 包 → 窃 GitHub OAuth 令牌 | 09-17 | | 2026-09-20~25 | 事件 | Gemini 评测攻击 Irregular 真实系统；澳 Medicare 门户事件 | 评测越权伤及真实第三方再现；澳政府设跨部门 AI 网络事件专班 | 09-20、09-25 | | 2026-09-26 | 研究 | GPT-Red 自博弈出现自我复制提示注入 | 注入诱导防御模型在公开输出通道复述自身，形态类蠕虫 | 09-27 | | 2026-09-27 | 治理 | 中美宣布设立 AI 事件沟通渠道 | 跨境「智能体非预期触网」通报进入危机沟通议程，11 月续开 AI 专题对话 | 09-27 | | 2026-09-28 | 产业 | NVIDIA Open Agent Safety Platform 发布（本篇主题） | OpenShell GA + Sentry 参考设计 + Open Secure AI Alliance（120+ 组织，Linux Foundation） | 09-28 |
三条年度主线：
- 1. 攻击面迁移：越狱/内容安全 → 智能体运行时授权滥用（CoreBreak、Agentjacking、越权预订）→ 供应链与身份（npm/PyPI 投毒、会话窃取、云凭据导出）——「Agent 的危险性体现在它能执行什么」被一再实证。
- 2. 评测/研究环境成为高危发源地：HF、Anthropic、Meta、Gemini、AISI 五起以上同源事件都源于「评测环境误配或去防护」——隔离粒度不足 + 长程自主能力 = 对第三方生产环境的真实伤害，也直接催生了 NVIDIA 的「带外强制」叙事。
- 3. 治理从原则走向机制：出口管制（Fable 5）、行政令与州法（美国）、CRA 通报义务（欧盟）、关停开关立法讨论、中美 AI 事件沟通渠道——「可节流、可挂起、可关停、可通报」成为监管共同语言，与技术侧 Enforcement / Containment 范式同频。
附：关键术语速查
| 术语 | 含义 | | — | — | | OpenShell | 开源智能体安全运行时（Apache 2.0）：沙箱 + 策略 + 网关 + Supervisor | | Sentry | BlueField-4 DPU 上的带外硅内监控/执行参考设计 | | Supervisor | 边界可信侧决策组件：策略裁决、凭据下发、代连 | | Sandbox | 与智能体同侧的托管组件：进程管控、流量转发，不做决策 | | Gateway | 控制面：沙箱生命周期、认证、策略下发 | | Policy prover | 策略变更的形式化验证器，标记「带凭据新可达/新 HTTP 方法/云元数据端点」等风险并阻断高风险自动批准 | | Policy advisor | 智能体被拒后提议窄范围策略变更的机制；默认人工审批，不能自批 | | Provider | 服务名到存储凭据的映射，凭据只发往批准端点 | | generation | 沙箱单次运行标识；重启后旧 token/证书全部作废 | | drift（漂移） | 智能体行为偏离既定任务/约束；长程运行、策略被拒、指令模糊均可诱发；无法靠训练消除 | | Runtime Identity | 运行实例身份（JWT/mTLS/generation）；≠ 企业级 Agent Identity（IAM/治理） | | OCSF | Open Cybersecurity Schema Framework，OpenShell 审计日志的 schema | | DOCA | BlueField DPU 的可编程软件框架，Sentry 的能力底座 | | Open Secure AI Alliance | NVIDIA 发起、Linux Foundation 治理的智能体安全开放联盟（SAFE 共享发现库） | | ExploitGym / CVE-2026-14646 | 7 月事件：OpenAI 网络能力评测基准 / 事件中被智能体链式利用的 Nexus Repository 3 SSRF 零日 |
引用链接及说明
性质：官方公开材料 + 公开事件报道的综合解读，产品能力边界以 NVIDIA 官方文档为准。
[1] NVIDIA 新闻稿：NVIDIA Launches Open Agent Safety Platform: https://nvidianews.nvidia.com/news/open-agent-safety-platform
[2] NVIDIA 产品页：Open Agent Safety Platform: https://www.nvidia.com/en-us/solutions/ai/agent-safety/
[3] GitHub：NVIDIA/OpenShell: https://github.com/NVIDIA/OpenShell
[4] OpenShell 官方文档：Architecture: https://docs.nvidia.com/openshell/about/architecture
[5] NVIDIA 开发者博客：Open Agent Safety Platform — 持续硅内智能体监控参考设计: https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/
[6] NVIDIA 开发者博客：Add Runtime Controls to AI Agents with NVIDIA OpenShell: https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/
[7] OpenAI 官方通报: https://openai.com/index/hugging-face-model-evaluation-security-incident/
[8] Hugging Face 安全披露: https://huggingface.co/blog/security-incident-july-2026
[9] 开发者页: https://docs.nvidia.com/openshell/about/why-open-shell
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：AI简化安全 dimu dimu《英伟达AI安全平台- Open Agent Safety Platform 解读（OpenShell / Sentry 全栈拆解）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论