直接答案：NVIDIA Open Agent Safety Platform 是一个把 Agent 安全控制放到模型之外的全栈方案：OpenShell 负责软件运行时的隔离、策略与审计，Sentry 则以 BlueField-4 DPU 为基础提供带外监控和隔离参考设计。企业不应把它当成“一装就安全”的单品；应先按任务破坏半径建立最小权限、批准、证据和回滚，再决定是否需要硬件独立监督。
核验边界：本文于 2026 年 9 月 29 日核对官方发布与公开文档。官方产品声明、本站可观察文档事实和编辑建议已分别标注；地区、硬件、版本、支持与可获得性会变化，采购或上线前应重新核对。
先把产品名拆成三个可验证对象
NVIDIA 在 2026 年 9 月 28 日发布的 Open Agent Safety Platform 不是一个单独的模型，也不是把一句安全提示词包装成产品。官方材料把它描述为开放的软件平台与参考系统设计：OpenShell 位于软件运行时边界，Sentry 是运行在 BlueField-4 DPU 上的带外看门狗，平台还涉及计算与机器人执行层。采购、部署和审计时必须分别核对组件、版本、硬件依赖与可获得状态，不能用平台总名替代逐项验收。
直接答案：先用 OpenShell 收紧运行边界，再判断是否需要 Sentry
多数团队的第一步不是采购一套新硬件，而是把 Agent 的网络、文件、进程、凭据和工具调用收进可执行的最小权限边界。OpenShell 适合承担这层运行时隔离、策略执行和审计；Sentry 的价值在于把监控与阻断放到 Agent 进程之外，以降低被同一软件栈绕过的风险。只有高敏感、高自主、高破坏半径的任务，才值得进一步评估 BlueField-4、DOCA、集成路径与运维成本。
什么变化发生在 9 月 28 日
官方发布把此前可单独讨论的 OpenShell 与新的 Sentry 参考系统设计放进同一全栈安全框架，并说明 OpenShell 已广泛可用。发布稿声称 Sentry 能在 Agent 超出软件边界时于毫秒级隔离并停止它；这属于 NVIDIA 的官方产品声明，不是本站独立基准。本文因此把事件事实、公开文档可观察行为和编辑建议分开：发布日期与组成来自官方，策略检查来自静态资产，性能和绕过能力不作本站实测结论。
OpenShell 控制的是 Agent 所在的执行环境
OpenShell 的公开仓库和文档把核心对象定义为 sandbox、gateway、provider profile 与 policy。Agent 在受控环境中运行，外部服务、可执行文件、文件系统和网络访问由策略约束。与只在系统提示中写“不要访问敏感数据”相比，这类控制不要求模型自己忠实解释约束；即使输入中出现恶意指令，未被允许的路径仍应在执行层被拒绝。真正的验收对象因此是拒绝事件和副作用，而不是回答语气是否谨慎。
Sentry 为什么强调带外
带外意味着监控与执行 Agent 的主要软件路径分离。官方把 Sentry 描述为运行在 BlueField-4 DPU 上的独立看门狗，并使用 DOCA 做硬件隔离的监控、治理和策略执行。这个设计试图解决一个基本问题：如果 Agent、工具运行器和安全代理都在同一主机、同一权限域内，受到破坏的一方可能同时影响日志或控制面。带外并不等于绝对安全，但它把攻击者需要跨越的边界增加了一层。
不要把 OpenShell 与 Sentry 当成同义词
OpenShell 是可获取的开源运行时软件，公开文档列出了 Docker、Podman、MicroVM 与 Kubernetes 等路径，并提供 CLI、SDK 与策略示例。Sentry 则是参考系统设计中的硬件隔离监控组件，依赖 BlueField-4 DPU 与 DOCA。前者可用于开发与软件侧治理，后者面向需要独立监督面的基础设施。若方案书只写“采用 NVIDIA Agent 安全平台”，却没有列出实际部署了哪一层、谁维护、失败时怎样回退，就不能通过验收。
先定义 Agent 的真实破坏半径
风险评估应从 Agent 能产生的副作用开始：它能否提交代码、删除文件、发邮件、修改工单、转账、调用生产 API、读取客户数据或控制物理设备。再记录每个动作的资源范围、凭据强度、人工复核点与可逆性。只问模型能力或准确率会漏掉最关键的控制对象。同一个模型用于公开资料摘要与用于生产变更，风险级别完全不同；安全架构应按动作与数据边界分层，而不是按模型品牌统一放行。
建立身份边界，而不是把人的令牌交给 Agent
Agent 继承个人或管理员长效凭据时，会同时继承超出当前任务的访问范围。更可控的方式是为工作负载分配独立身份，使用短期凭据，并把任务、环境、资源和时间绑定进授权。OpenShell provider profile 能描述所需客户端、端点和凭据注入，但配置存在不等于最小权限已经成立。验收要证明凭据只到达需要的进程，只能访问批准端点，而且日志、提示与错误信息中不出现明文秘密。
网络策略要验证方法、路径与 DNS 变化
只允许一个域名仍可能范围过大，因为同一域名可承载读取与写入、公开与私有 API。公开示例显示策略可以细化到 HTTP 方法与路径：GET 可允许而 POST 被拒绝。生产环境还要处理重定向、CDN、代理、DNS 解析、IPv6、WebSocket 与非 HTTP 协议。测试应包含允许路径、相邻未允许路径、大小写和编码变体、重定向目标以及断网后的失败方式，不能只证明一次正常请求成功。
文件系统要区分读、写、执行和持久化
Agent 需要读取代码不代表它应读取整个用户目录；需要写构建产物也不代表它可以覆盖源码或凭据文件。将输入、工作区、缓存、输出和秘密挂载拆开，分别设置只读、可写、不可执行与生命周期。测试越权时使用无害标记文件，验证拒绝、审计和清理。任务结束后确认临时目录、历史记录、shell 配置和模型缓存不会把敏感数据带进下一次会话。
进程和命令边界不能只靠命令黑名单
命令黑名单容易被解释器、脚本、子进程或等效工具绕过。应优先建立允许的可执行文件、参数模板、工作目录、用户身份、资源限额和系统调用边界。对包管理器、shell、编译器和下载器尤其谨慎，因为它们能扩展能力。验收既要测试明显危险命令，也要测试间接路径，例如由允许的编辑器调用 shell、由构建脚本下载依赖、由测试钩子启动网络连接。
工具策略必须覆盖参数，而不只是工具名称
允许“读取工单”与允许任意搜索、导出全部客户字段并不相同；允许“创建草稿”与允许“直接发送”也不相同。策略应约束主体、动作、资源、字段、数量、目的地和时间窗口，并让高风险参数进入人工审批。若工具协议只暴露一个宽泛函数，应该先拆分接口或增加可信中间层，而不是把所有判断交给模型。工具清单变更后应触发重新审查。
批准流程需要绑定不可变请求
人工批准不能只展示一句自然语言摘要，否则 Agent 在批准后可能更换参数。审批记录应绑定完整请求摘要、调用主体、工具版本、策略版本、资源范围、有效期和批准人；任何关键字段变化都使旧批准失效。超时、拒绝和撤销必须是终态，不能通过重试生成一个新请求绕过。批准者看到的预览应突出写操作、外部接收方、数据量和不可逆影响。
默认拒绝是起点，不是完成态
默认拒绝能避免未知能力自动开放，但如果团队不断临时批准宽泛规则，边界仍会膨胀。每次拒绝后的规则建议都应由人检查具体主机、端口、路径、进程和用途，并设置到期时间。长期规则需要负责人和复核周期。将“任务终于跑通”作为放行标准会鼓励越权；正确标准是业务任务在最小授权下完成，且相邻不允许动作持续被拒绝。
策略建议器不能替代策略所有者
公开文档提到 Policy Advisor 可根据拒绝事件生成更窄的规则提案，并由 policy prover 检查后等待审阅。这能减少手工编写成本，但生成建议的系统并不知道组织的业务意图、数据分类与合规义务。策略所有者仍需决定目的是否正当、范围是否必要、是否存在更小授权。自动批准只适用于低风险、边界明确、可回滚且持续监控的动作。
审计日志要能回答五个问题
一条有用的 Agent 审计记录至少回答：谁发起、哪个 Agent 和版本执行、使用了什么凭据与策略、对哪个资源做了什么、结果与副作用是什么。再关联任务 ID、输入来源、批准记录、时间、失败码和输出哈希。只保存聊天文本或命令字符串无法重建真实影响；只保存全部内容又可能造成新的敏感数据仓库。日志应结构化、最小化、访问受控，并有保留和删除规则。
防止 Agent 改写自己的证据
如果执行进程能删除或覆盖审计记录，成功日志就不能证明违规没有发生。日志应流向 Agent 无法修改的外部存储，关键事件可使用追加写、签名、不可变保留或独立采集。带外监控的价值也应在这里验证：断开主机侧日志代理、终止 Agent、修改系统时间或让任务崩溃时，外部记录是否仍完整。没有这类故障演练，‘可审计’只是架构描述。
提示注入测试要关注副作用
测试网页、邮件、文档或工具返回值中的隐藏指令时，不应只看模型是否复述恶意内容，而要检查是否产生未经批准的网络访问、文件读取、凭据使用或写操作。准备无害诱饵资源，定义禁止效果，并固定输入与策略版本。即使模型回答含有危险建议，只要执行边界拦截了副作用，控制仍发挥作用；反之，语气安全但后台已泄露数据就是失败。
数据泄露有三条主要路径
第一是把秘密直接发给外部模型或服务；第二是通过工具返回、错误堆栈、日志和缓存间接暴露；第三是把数据编码进域名、URL、文件名或其他允许输出。策略要覆盖请求和响应，并限制目的地、字段、大小和频率。内容过滤可作为补充，但不能替代结构化字段删除和最小授权，因为字符串掩码无法证明推断信息或变形编码都被阻断。
模型调用本身也需要路由约束
企业可能允许不同数据进入不同模型端点。Provider 与网络策略应绑定批准的域名、模型、区域和数据处理条件，禁止 Agent 临时改用未知代理。记录实际请求端点、模型标识、账户与数据保留设置，但不要把密钥写入回执。模型别名或供应商路由变化会改变处理边界，应作为重新验收事件，而不是只要 API 仍返回 200 就继续使用。
容器不是自动的安全结论
容器提供进程与文件系统隔离，但特权模式、宿主套接字、宽泛挂载、共享网络和内核漏洞都可能削弱边界。验收要记录镜像摘要、用户、capabilities、seccomp/AppArmor 或同类配置、挂载、设备、网络和资源限制。若使用 Docker socket 管理其他容器，应视为接近宿主控制权限。只展示容器正在运行不能证明 Agent 的动作范围已被约束。
MicroVM 与 Kubernetes 路径各有运营条件
MicroVM 能提供更强的虚拟化边界，但会增加镜像、启动、调试和容量管理成本；Kubernetes 便于统一调度，却要求命名空间、ServiceAccount、RBAC、NetworkPolicy、镜像策略和密钥管理共同正确。OpenShell 文档明确提示 Kubernetes 的 CNI 必须执行 NetworkPolicy。团队应选择能持续维护和验证的路径，而不是只选理论隔离更强却无人负责的方案。
资源限制也是安全控制
无限 CPU、内存、磁盘、进程、网络和任务时长会让错误循环演变成拒绝服务或费用事故。为 sandbox 设置上限、超时、并发和预算，并将触发事件记录为失败而非自动扩大额度。模型调用还要限制 Token、工具轮次和重试。资源限额不证明内容安全，但能收缩破坏半径；容量规划则应基于代表性任务与失败分布，而不是单次最快运行。
机器人与物理系统需要更短的控制回路
软件 Agent 写错文件可能可以回滚，机器人、车辆或工业设备的动作可能立刻影响人和设施。物理任务需要独立的安全控制器、速度和空间限制、急停、传感器健康检查、人工接管与安全状态。语言模型不得成为唯一的安全决策点。NVIDIA 发布将机器人层纳入平台愿景，但具体设备认证、实时性与功能安全仍需按行业标准单独完成。
Sentry 的采购问题从硬件依赖开始
评估 Sentry 时先确认 BlueField-4 DPU、服务器平台、DOCA 版本、网络拓扑、管理面和供应支持是否匹配，再问哪些 Agent 事件能够被观察和阻断。不要把参考设计等同于现有环境开箱可用。方案应列出安装责任、固件和驱动生命周期、故障域、升级窗口、遥测出口、与 SIEM/SOC 的集成以及 DPU 失效时的安全状态。
毫秒级隔离声明需要自己的验收方法
官方发布声称 Sentry 可在毫秒级隔离越界 Agent。若这一时延对业务决策重要，采购验收必须定义起点、终点、时钟来源、负载、并发、样本数和分位数，并保存原始事件。本站没有 BlueField-4 环境，因此不复述为独立测试结果。即使阻断很快，也要评估在触发前已经完成的操作、在途请求、缓存写入和下游系统的撤销能力。
高可用不能让安全策略变成旁路
安全组件故障时要明确 fail-closed 还是 fail-open。对支付、生产写入或敏感数据，控制面不可用通常应停止高风险动作；对只读低风险任务，可能允许有限降级。双机、健康检查和恢复流程不能自动把所有流量绕过策略。演练网络分区、DPU 重启、gateway 崩溃、策略存储损坏和日志目标不可达，确认系统进入预先定义的状态。
版本锁定与供应链证据
部署应记录 OpenShell 发行版、容器或二进制哈希、仓库提交、SDK 与 gateway 兼容版本、策略包哈希以及依赖来源。公开仓库的 main 分支会变化，不能作为生产不可变版本。升级前阅读发行说明，在隔离环境重跑允许与拒绝夹具，再逐步放量。安装脚本方便启动试验，但生产环境应先下载、校验、审查并通过受控软件分发渠道执行。
策略即代码也需要评审和测试
将策略放入版本控制，要求负责人、变更说明、测试夹具和回滚版本。每条允许规则至少配一个正例、一个相邻拒绝例和一个越界变体；每条高风险写操作配批准、拒绝、超时和重复执行测试。静态检查可以发现缺字段和过宽模式，但不能判断业务意图是否正确。策略上线后仍需从真实拒绝与批准事件中复盘。
本文提供的独立资产证明什么
随文的 JSON 资产用于记录 Agent、环境、策略哈希、允许动作、禁止动作、审批与回滚字段；校验脚本只检查结构完整、哈希格式和决策枚举。它能帮助团队避免漏填关键证据，也能在版本变化时发现记录不一致。它不能运行 OpenShell、不能证明 Sentry 性能、不能证明没有未知绕过，更不能替代渗透测试、硬件验收或法律合规判断。
用四组夹具做最小可复现验收
第一组是允许路径：业务所需读取或写入按预期完成。第二组是相邻拒绝：相同工具但不同资源、方法或参数被拦截。第三组是注入与绕过：外部内容诱导访问诱饵秘密、改写策略或换端点。第四组是故障恢复：控制面中断、任务超时、进程崩溃和重启后不重复副作用。每组保留输入、策略、事件、输出、时间和结论。
测试重复执行与幂等性
Agent 遇到超时往往自动重试，写操作可能重复发送邮件、创建工单或扣费。工具应支持幂等键、状态查询和去重窗口，策略允许写入时也要限制重复频率。验收先模拟响应丢失再重试，确认系统返回原结果或阻止重复副作用。回滚不是删除日志，而是撤销业务变化并保留完整证据。
测试权限升级和横向移动
不要只在单个 sandbox 内测试。验证 Agent 能否读取其他任务目录、访问其他服务账号、利用共享缓存、调用管理 API 或连接邻近命名空间。凭据、网络与文件边界应同时阻止横向移动。管理员调试工具要与 Agent 身份分离，临时提升有到期和审计。若一个低风险任务能影响策略控制面或其他 Agent，隔离设计就没有达到目标。
测试终止后残留
停止 Agent 后检查子进程、后台作业、网络连接、临时凭据、挂载、队列消息和定时任务是否仍存在。攻击者可能把副作用延迟到主任务结束后。sandbox 销毁应有明确顺序，先阻断新外联和写操作，再撤销凭据、终止进程、保存证据并清理存储。清理失败必须进入告警与人工处置，而不是静默标记任务完成。
从开发到生产分四阶段推进
阶段一在本地或隔离环境建立默认拒绝与固定夹具；阶段二接入非敏感只读工具，观察拒绝和规则申请；阶段三开放可回滚写操作并强制逐次批准；阶段四才考虑高自主、高敏感或物理动作，并加入独立监督面。每阶段设进入和退出条件，任何越权、证据缺失或恢复失败都回退。不要一次把生产凭据和全部工具交给新 Agent。
角色分工要避免一个人同时写规则又批准
业务负责人定义任务与可接受影响，安全负责人设最大授权边界，平台团队实现运行时与日志，工具所有者维护接口和幂等，审计或合规人员抽查证据。高风险规则由不同角色复核。值班手册说明谁能隔离 Agent、撤销凭据、恢复服务和通知受影响方。没有明确负责人时，安全告警容易在模型、平台和业务团队之间相互推诿。
把告警分成可行动的等级
策略拒绝不一定都是攻击，也可能是缺失依赖或任务设计错误。按资源敏感度、动作类型、是否重复、是否来自外部内容和是否接近成功分级。低风险拒绝可用于改进规则，高风险越权应立即隔离、撤销凭据并保全证据。告警必须包含任务和策略上下文，但避免复制全部敏感提示。通过演练确认值班人员能从告警定位真实副作用。
采购评分不要只比较功能清单
可用同一组场景比较候选方案：最小权限表达力、执行边界独立性、身份和秘密处理、允许与拒绝证据、故障状态、部署依赖、升级与回滚、日志可移植性、成本和团队能力。对每项要求演示或可复现回执。营销中的“安全 Agent”“零信任”或“硬件级”不是验收结果；无法说明不覆盖什么的方案，应降低评分。
OpenShell 适合谁
适合需要运行编码、研究、自动化或自建 Agent，且希望把进程、网络、文件、凭据和策略集中治理的团队。开发者可先用公开文档与仓库建立小规模试验。若任务只调用一个窄 API、没有本地执行或敏感数据，也可用更简单的网关和工作负载身份满足需求。工具选择应由风险和运营能力决定，不必为了架构先进而增加无法维护的层。
Sentry 更可能适合谁
更适合已经采用或计划采用 BlueField-4 基础设施、运行高价值或高自主 Agent、需要把监督面与主机软件隔离，并能承担硬件、网络与安全运营工作的组织。普通个人开发者、仅做内容草稿的团队或没有 DPU 运维能力的环境，通常应先把软件侧最小权限、审批、日志和回滚做好。是否采用仍需等待可获得性、支持矩阵和实测结果逐项确认。
何时不应上线
出现以下任一项就停止：任务副作用未列全；Agent 使用个人或管理员长效凭据；允许规则包含未解释的通配范围；越权测试没有被稳定拒绝；批准未绑定完整请求；日志可被 Agent 修改；控制面故障默认放行高风险动作；无法撤销写入；关键版本和策略哈希未记录；团队把官方声明当作本站实测。停止并不等于项目失败，而是避免把未知风险带进生产。
如何处理已发生的越界
先隔离 Agent 和相关执行环境，撤销短期与长期凭据，阻断外联与新任务；随后保存策略、日志、任务输入、工具调用和受影响资源快照。不要为了恢复服务先清理现场。确认哪些动作真正完成、哪些只是尝试，并对下游系统做撤销或补偿。修复后用原夹具与新增攻击路径重新验证，再由独立人员批准恢复。涉及个人信息或受监管数据时按组织的事件响应与通知要求处理。
每周与事件触发复核
稳定运行不代表边界永久有效。每周查看新增规则、拒绝峰值、临时批准、超时和未完成清理；版本、工具、模型、端点、数据类别、业务用途或基础设施变化时立即重验。官方文档与仓库更新只能作为发现信号，必须读取具体发布说明和适用范围。没有实质变化时记录“无须更新”，不要只刷新日期制造维护痕迹。
官方伙伴声明的证明边界
NVIDIA 与 HPE 等伙伴材料说明计划集成和目标场景，可用于理解生态与部署方向；它们不证明你的环境已经兼容、功能已经在所有地区可购买、性能达到目标或安全风险已经消失。尤其是计划于未来季度提供的集成，应明确标为计划状态。采购决定需要合同、支持矩阵、交付版本和自己的验收回执，不能只依据发布稿中的合作名单。
与 124973 NemoClaw 指南的意图区分
本站已有 NemoClaw 与 OpenShell 部署指南，主任务是把企业 Agent 放进受控运行环境并完成策略验收。本文的主任务是理解 9 月 28 日新平台的组件边界，判断是否需要软件运行时、带外硬件监督或两者组合，并建立采购与上线证据。两页互相链接但不重复：需要具体 OpenShell 部署步骤时进入前者，需要平台架构和 Sentry 决策时留在本文。
本文没有做哪些测试
本站没有 BlueField-4 与 Sentry 测试环境，没有测量毫秒级隔离，也没有以真实客户数据运行 OpenShell。文章核对了 NVIDIA 官方发布、OpenShell 官方仓库和文档、HPE 官方集成说明以及一篇带外策略研究，并制作静态验收资产。原创图用于解释架构与流程，不代表产品截图；官方页面截图只证明公开发布内容在核验日可见，不代表本站已部署。
一页式上线检查表
任务：列出输入、输出、副作用和停止条件。身份：独立工作负载、短期凭据、不可进入提示与日志。边界：网络、文件、进程、工具参数和资源上限。批准：高风险请求绑定摘要、策略版本和期限。证据：允许、拒绝、注入、故障和恢复回执。运维：告警、隔离、撤销、回滚和负责人。版本：二进制、镜像、策略、SDK、硬件与固件可追踪。结论：任何关键项缺失都保持试验状态。
给决策者的最终建议
若你现在仍靠提示词提醒 Agent 不要越权，先建立软件侧强制边界和可回滚工具接口；OpenShell 可作为值得验证的候选。若组织已有高敏感 Agent、BlueField 路线和成熟安全运营，再把 Sentry 加入带外监督的采购验证。不要先购买平台再寻找问题，也不要把开源、硬件或合作伙伴数量当作安全证明。最终通过条件应是：授权最小、拒绝可复现、副作用可追踪、故障进入安全状态、恢复可演练。
先做一份能力与依赖清单
在安装任何平台之前，为每个 Agent 盘点模型端点、MCP Server、浏览器、shell、代码仓库、数据库、消息系统、对象存储和物理设备。每项记录所有者、身份、允许动作、敏感字段、外部接收方、速率、不可逆效果与回滚方式。再标出由谁提供 DNS、代理、证书、密钥、镜像和日志。清单的作用不是增加文档，而是让策略对象与真实依赖一一对应；未登记能力默认不可用。
把业务流程画成可拦截的控制点
例如一个修复缺陷的编码 Agent，流程可拆成读取问题、克隆仓库、创建分支、编辑文件、运行测试、生成差异、提交和创建拉取请求。读取公开问题与创建 PR 的风险不同，合并、发布和修改密钥又是更高一级。把每个转换点标成自动、需批准或禁止，并绑定实际工具动作。只有这样，平台策略、人工批准和审计事件才能映射到业务责任，而不是停留在抽象权限名。
秘密管理要验证注入、使用和撤销三段
秘密应由可信控制面在任务需要时注入到指定进程或请求，不以明文出现在镜像、工作区、提示、命令历史和通用日志中。测试 Agent 是否能打印环境、读取进程信息、访问凭据文件或把令牌发送到其他端点。任务结束、审批撤销或异常隔离时，短期令牌要失效，长期上游授权也能追踪。只把秘密放进环境变量并不自动安全，关键是可见范围和生命周期。
浏览器 Agent 要限制导航与提交动作
浏览器能访问登录态页面，风险不仅是打开恶意网站，还包括读取跨页面数据、自动下载、上传文件、提交表单和确认支付。允许域名之外，还要区分导航、读取、下载、上传、输入敏感字段与最终提交。高风险按钮由外部批准控制，不依赖页面文字提醒。测试弹窗、新标签、重定向、iframe、下载协议和文件选择器，确认恶意页面不能把浏览器变成跨系统代理。
邮件与协作 Agent 要防止把消息当授权
来自邮件、Slack 或 Teams 的文本可能同时包含业务请求和不可信指令。Agent 不应因为消息中出现‘经理已批准’就扩大权限。发件人身份、频道、线程和附件来源属于输入证据，但真正授权要由独立系统确认。发送外部邮件、邀请成员、共享文件或创建公开链接前，预览接收方、字段、附件和权限。测试转发消息、伪造引用、隐藏文本与相似域名。
编码 Agent 要把代码修改与执行分开
允许编辑仓库不等于允许执行任意新代码。先在只读依赖和隔离网络中生成差异，再由受控测试环境运行；构建脚本、测试钩子和包安装可能产生网络或系统副作用，应使用锁文件、镜像摘要与允许源。创建 PR 可以自动化，合并、发布、修改 CI 密钥和基础设施则需更高审批。回执保存差异、测试命令、退出码、依赖变化和未运行项目。
数据库 Agent 要约束查询形状和结果字段
只授予 SELECT 仍可能允许全表导出、敏感字段联结或高成本查询。策略应限制 schema、表、列、过滤条件、行数、时间范围和超时，并在返回前移除不需要的字段。写操作使用专用存储过程或窄接口，禁止自由 SQL 直接修改生产。测试 UNION、子查询、编码、分页、聚合与推断路径。审计记录查询结构和结果规模，但不复制全部敏感数据。
工单和 CRM Agent 要保护批量动作
单条更新可能低风险，批量关闭、导出联系人、改变所有者或触发自动化会放大影响。为数量、状态转换、客户等级和外部同步设置上限；超过阈值转人工批准。工具返回中的客户文本视为不可信输入，不能改变策略。幂等键与变更前快照用于恢复，批量任务先做 dry-run，展示将影响的对象和字段，再允许执行固定集合。
资金与采购动作必须保持双重控制
Agent 可以整理报价、计算预算或生成采购草案，但创建供应商、变更收款账户、批准订单和付款不能由同一身份闭环完成。把建议、录入、审核和支付分离，金额、币种、收款方和合同版本绑定到批准记录。测试重复支付、相似供应商名称、汇率变化、过期报价与附件注入。任何无法撤回的资金动作都需要独立人类确认和银行侧限制。
策略静态检查应寻找宽泛与冲突
在上线前扫描通配域名、任意方法、根目录写入、特权容器、宿主套接字、无限资源、长期秘密和缺失到期时间。检查同一动作是否既允许又拒绝、子规则是否意外扩大父规则，以及不同环境的变量替换是否产生空值或全匹配。静态检查只能发现表达上的风险，不能判断业务需要，因此每条例外仍要有负责人、原因、期限和运行夹具。
建立运行指标但不要把请求当用户
可记录任务数、策略允许与拒绝数、人工批准等待、超时、重试、隔离、回滚和证据缺失率，用于判断控制是否可运营。网络请求、爬虫、工具调用或 IndexNow 等发现信号不能解释为真实用户或业务成功。安全指标也不能只追求拒绝越少越好；拒绝骤降可能意味着规则被放宽或日志失效。变化必须结合策略版本与任务组合解释。
设计样本时覆盖正常、边界与恶意输入
每类任务至少准备典型成功样本、最小和最大输入、空值、格式错误、权限不足、网络超时、工具错误以及包含隐藏指令的不可信内容。若只测试理想流程，Agent 的重试与恢复分支将没有证据。固定样本用于版本对比，新增真实故障转成回归夹具。样本不得包含真实秘密或未授权个人数据；需要逼真结构时使用合成但明确标注的数据。
红队结果要转化为可验证修复
发现越界后，不以补一句提示词作为默认修复。先定位是身份过宽、工具接口过宽、策略漏项、解析差异、批准缺陷还是日志缺失，再把禁止效果写成自动回归测试。修复应在相同输入与相邻变体上验证，并确认没有破坏允许路径。无法稳定复现或解释的事件保持未通过，必要时降低 Agent 自主级别，而不是依靠多次重试得到一次安全结果。
迁移现有 Agent 时先旁路观察
不要把已有生产 Agent 一次性迁入新运行时。先以只读或影子模式收集它实际访问的端点、文件、命令和工具，再根据业务意图建立最小策略。随后在预生产环境强制执行，处理误拒绝并删除无用途径，最后对小比例低风险任务启用。每阶段保留旧路径、数据同步和回退条件，但回退不能恢复到无审计、无限权限的危险状态。
估算总成本要包含安全运营
软件开源不代表总体成本为零。预算需包括基础设施、DPU 或云资源、镜像与策略维护、日志存储、安全监控、审批人时间、测试环境、升级演练、事故响应和供应支持。也要计入安全控制带来的延迟与任务失败成本。比较方案时使用同一任务和风险目标，分别计算建设、持续运营与退出成本；不能只比较许可证或硬件采购价。
用退出计划检验是否真正可控
在采用平台前就写明怎样导出策略、日志与证据，怎样撤销所有身份，怎样迁移 Agent 和工具接口，怎样处理硬件、镜像与数据残留。供应商、项目或版本停止时，组织应能回到受控的人工流程或替代运行时，而不是为了不中断业务关闭门禁。退出演练还能暴露隐藏依赖：如果没人知道凭据、规则和日志在哪里，当前运行也谈不上可治理。
最终验收会议要看原始回执
上线评审不要只看架构图和汇总分数。随机抽取允许、拒绝、人工批准、故障和回滚各一条，从任务输入沿着身份、策略、事件、工具结果追到业务副作用，确认时间、版本和哈希能够闭合。再由未参与实现的人复跑至少一个拒绝夹具。任何依赖口头解释、找不到原始日志或无法关联到实际资源的结论都应退回补证；只有证据链完整，才允许按既定范围逐步放量。评审结论还要写清适用环境、最大授权、遗留风险、复查日期和自动停用条件，防止一次批准被误当作长期或全局授权。
官方来源与进一步核验
- NVIDIA 官方发布：Open Agent Safety Platform：发布日期、平台组成、OpenShell 与 Sentry 的官方定位。
- NVIDIA OpenShell 官方仓库：开源状态、安装入口、运行环境、SDK 与策略示例。
- OpenShell 官方文档：Run Your First Agent：provider、凭据、策略建议与拒绝流程。
- HPE 官方集成说明：OpenShell、Sentry、BlueField-4 与计划可用性边界。
- 带外策略执行研究论文：独立于 Agent 推理的可信工具边界及其适用条件。
继续完成相邻任务
- 需要部署 OpenShell 沙箱时，阅读NemoClaw、OpenShell 权限、部署与验收指南。
- 需要缩小工具授权时，阅读Agent 工具调用与权限治理。
- 需要建立企业级责任边界时，阅读企业智能体治理框架。
常见问题
Open Agent Safety Platform 是一个新模型吗？
不是。它是安全软件平台与参考系统设计，围绕 Agent 运行时、基础设施和硬件监督建立控制。
只用 OpenShell、不用 Sentry 可以吗？
可以按风险选择组件。多数团队可先验证软件侧最小权限和审计；是否增加 Sentry 取决于高敏感任务、BlueField-4 路线与运营能力。
用了 Sentry 就不会发生提示注入吗？
不能这样承诺。带外控制旨在限制和监控副作用，不会自动消除恶意内容、错误判断、过宽授权或所有未知漏洞。
OpenShell 开源是否等于可以直接用于生产？
不等于。仍需锁定版本、审查安装与依赖、配置策略、运行正反夹具、建立日志和回滚，并确认支持范围。
本站是否验证了毫秒级隔离？
没有。该数字来自 NVIDIA 官方声明；本文给出采购验收方法，但未在 BlueField-4 上做性能测试。
随文 JSON 校验器能证明系统安全吗？
不能。它只验证验收记录字段与哈希格式是否齐全，不运行产品，也不替代安全测试和审计。
