一个编程智能体接到任务：检查仓库里的测试失败，修好代码并提交。它需要读文件、运行命令、访问依赖、也许还要查询 GitHub。只要把这些能力全开，事情确实容易办；但如果它误把生产环境变量传到外网，或者为了完成任务去改另一个仓库，仅靠提示词里一句“不要这样做”并不能阻止它。9 月 28 日，NVIDIA 发布 Open Agent Safety Platform，想把这类约束从智能体自己的“自觉”，挪到它无法自行修改的运行环境与基础设施中。[1]
先划清产品边界。这不是一款能判断所有 AI 回答是否正确的安全模型，而是一套软件加参考系统设计：已经开放的 OpenShell 负责沙箱和运行时策略；Sentry 则是基于 BlueField-4 DPU 的带外监控与隔离设计。官方称，前者可在 Vera CPU 上运行，也能扩展至 Arm、Intel 等第三方计算平台；后者针对采用相应 NVIDIA 硬件的基础设施，不能把两者的可用条件混为一谈。[1][2]
为什么“应用层拦截”不够
常见做法是把权限写进系统提示词，或在智能体框架里包装工具：不让调用某个函数、先询问用户再执行。问题是智能体不一定只走那条函数路径。它还能在 shell 里生成脚本、启动子进程、换用另一个获准连接的工具，甚至把请求委托给子智能体。如果权限检查只存在于智能体可改动的代码里，防线与被约束对象处在同一个信任域。NVIDIA 技术文章把越界行为称作 drift：可能来自恶意引导，也可能只是模糊任务、工具缺失或长时间试错，不必预设智能体有“意图”才能讨论风险。[2]
OpenShell 的办法更接近传统系统安全：把工作负载放进独立沙箱，用内核级控制限定文件与进程能力，网络连接必须经过沙箱外的 supervisor。Gateway 管理多个沙箱的生命周期和策略；每个沙箱配一个 supervisor 审核出站请求；沙箱中的智能体不能自行开出另一条不经审核的网络通路。这种结构保护的是执行边界，而不只是模型输出文本。[3]
有个细节尤其值得开发团队看。允许访问 api.github.com，并不等于允许对该域名做任何事。OpenShell 的示例策略把主机、443 端口、REST 协议、/usr/bin/curl 和只读访问写在同一规则里；读取 GitHub 公共接口可通过，POST 请求会被拦下。官方示例将 YAML 策略编译为 OPA/Rego，对出站请求进行判断；针对配置过的 HTTP、GraphQL、MCP 流量，还可以区分查询和写入。判断结果记录到采用 OCSF 格式的审计轨迹中，被拒的请求可返回原因，便于人或智能体改走获准路径。[3] 这比“整个域名一律开放”细得多，但也意味着团队必须摸清业务 API 的实际请求形态：协议无法被正确检查时，不能想当然地认为自己拿到了同等粒度的控制。
另一个真实痛点是密钥。智能体用私有 API 时，往往会把 token 放进进程环境；一旦能读取环境并自由发送网络请求，泄露风险就跟着权限一同下发。OpenShell 的 provider 机制将真实凭据留在工作负载外，智能体使用占位值，外部组件仅在请求发往授权端点、符合规则时替换。接收端仍须用自己的权限体系做最终校验；OpenShell 只是额外增加一层限制。即便后端密钥本身可写，外层只读策略也可以先挡掉写请求。[3] 企业由此应避免把“凭据不进沙箱”误读为“不必做服务端最小权限”。
动态授权，不是随口答应
智能体做长任务，开局不可能预知所有依赖。OpenShell 可记录被阻止的访问，让策略顾问提出范围较窄的网络或文件权限变更；默认仍需人审核，智能体不能批准自己的申请。获准后，网络策略可以加载进正在运行的沙箱，不用从头跑任务；文件和进程限制则在沙箱启动时确定，要变更需新建沙箱。[3] 对运维来说，这一差异决定了权限工单怎么设计：网络临时开口可以在线处理，文件树及进程权限应尽量在任务开始前审好。
审批也可能被智能体的话术带偏。OpenShell 的 policy prover 用形式化方法分析策略实际允许什么，包括 provider 带来的访问，并给出是否越过运营方定义边界的结果或具体反例。NVIDIA 描述的对抗实验里，一些降低防护的前沿智能体曾试图在最长两小时的交互中说服 AI 审核者放开对受保护 GitHub 仓库的写入；在这些实验条件下，结合形式化分析与运行时拦截，未发生受保护仓库写入。[3] 这是厂商披露的特定测试结果，不等于对所有策略、所有越权手法的普遍保证。官方也明确说，多智能体权限组合的分析仍在继续开发；单个智能体的权限可证明安全，不代表彼此串联后就一定安全。
Sentry 补的是另一个位置。NVIDIA 把它描述为基于 DOCA、运行在 BlueField-4 DPU 上的带外监控和执行层：独立于宿主机观察智能体活动、身份、委托权限、工具与数据访问，出现越过软件边界的情况时隔离并停止智能体；发布稿称隔离可在毫秒级完成。[1][2] 在 Vera Rubin POD 的官方架构说明中，BlueField-4 位于节点访问模型的唯一路径上，于是“下一次模型调用”也能成为观察和中断点。[2] 但这依赖具体部署拓扑：一家企业在自己的网络里多开一条未受控出口，或把模型调用绕开这条路径，不能照搬发布稿里的防护结论。Sentry 作为参考系统设计，与今天就能下载的 OpenShell 开源软件也不在同一个部署门槛上。
平台的生态名单很长。NVIDIA 提到 Anthropic、Salesforce、SAP、Scale AI，以及金融、能源、机器人等领域组织参与或集成；例如 Salesforce 与 NVIDIA 将 OpenShell 接入 Slack，让团队查看活动、审计事件并批准或拒绝额外权限请求。[1] 这些合作说明行业有共同的集成需求，但“参与”“试点”“产品集成”“全量上线”各不相同，不能拿伙伴数量代替运行效果。OpenShell 代码以 Apache 2.0 开源，仓库和文档公开；安全能力能否成立，最终仍看策略、部署和日志验证。[2][4]
企业怎么试，才不把安全平台又做成一层摆设
先挑一项可复现、低风险的真实任务，例如让智能体汇总 issue、读取指定仓库、生成补丁，但不直接合并。列出完成任务所必需的文件、进程、目标域名、API 方法和凭据；分别给出“允许读取”“必须禁止写入”的负面用例。用 OpenShell 本地沙箱跑通业务，再主动尝试从 shell、生成脚本和子进程触发同一笔禁止操作；如果只测试智能体会不会礼貌地拒绝，便没有测到外部边界。[3]
随后检查三份记录是否对得上：业务请求、supervisor 的策略判定、目标服务自己的审计日志。把权限扩大的审批分配给独立责任人，明确谁能修改策略、谁能豁免、何时回收；评估 policy prover 能覆盖哪些已建模动作，哪些仍需人工审查。对敏感数据，继续做服务端最小权限、网络分段与密钥轮换。对于考虑 DPU 层的团队，先要求供应商给出自己的硬件拓扑、流量覆盖率、故障时是否默认拒绝、隔离误报恢复流程和延迟数据，再谈“毫秒级防护”。
还有几笔容易被忽略的账。第一笔是可用性：策略设得过窄，智能体会不断撞墙；设得太宽，沙箱只是换了名字的全权限机器。把一次任务拆成“浏览资料—编辑工作区—提交变更”几个阶段，每个阶段分配不同的权限，比给整个长任务一张永久通行证更容易审计。NVIDIA 的示例证明了读写 API 可以拆分，不等于每家企业都已做好自己的 API 方法目录。[3] 如果一个接口通过 POST 完成只读检索，或者通过 GET 触发有副作用的动作，仅靠 HTTP 方法名分类也可能不符合真实业务语义。应拿实际接口定义、审计日志和负面测试来核实。
第二笔是审计数据的质量。记录“拒绝了一次出站请求”有用，但事故调查往往还需要知道是哪项任务、哪个工作区、哪条策略版本、哪个委托身份、请求想写入什么类型的数据。日志不能无限保留敏感请求正文，否则安全平台本身会变成新的数据集中点。企业可将请求标识、策略版本与业务流水号关联，对秘密和个人信息做遮盖，并单独设定日志访问与保留期限。OpenShell 提供 OCSF 形式的审计轨迹，[3] 但把这条轨迹接入现有 SIEM、事件响应与工单系统，仍是使用者自己的工程工作。
第三笔是故障模式。假设 supervisor 失联，沙箱还会不会出网？假设审批服务迟迟不响应，正在跑的任务能否安全暂停？DPU 监控报出可疑信号，却碰上业务高峰误报，谁有权解除隔离？发布资料说明组件的设计目标，并未提供足以替所有用户回答这些问题的生产运行数据。[1][2] 上线前应主动演练断网、过期凭据、策略回滚、监控组件重启和日志服务不可用，而不是只在正常条件下测吞吐。
对跨团队协作的智能体，还要看“合并权限”问题。一个沙箱只能读取内部文件，另一个沙箱可以向外部地址发送消息，两者如果通过共享队列互传原文，系统整体仍可能形成数据外流通道。官方明确把跨智能体组合权限的形式化分析列为后续工作。[3] 在它成熟以前，业务系统应在队列、共享目录和委托接口上继续做身份校验与数据分类，不能因为每个智能体各自通过策略检查，就把整个工作流视作已经证明安全。
采购层面则应把“开源”问得更细。OpenShell 的 Apache 2.0 仓库可以自行审阅、试跑，[4] 但 Sentry 所依赖的 DPU 与 DOCA 并不是把同一份代码复制到任意服务器就能复现的能力。企业可以先用软件沙箱降低权限暴露，再根据受保护资产价值、硬件现状和实际攻击面决定是否引入带外硬件层。先验证软件边界是否真正拦住危险请求，比先采购整套设施再寻找用例更务实。
最后，不妨用一个小型验收表，而不是一句“通过安全评估”结束项目。场景一：让编码智能体读取授权仓库并尝试修改受保护仓库，预期后者失败；场景二：同一 GitHub 域名里 GET 允许、写入禁止，核对 HTTP 判定与后端日志；场景三：智能体要求增加权限，确认申请进入独立审核且原工作负载不能自行批准；场景四：用错误的目标主机发送凭据占位值，确认真实密钥从未进入沙箱或目标端；场景五：策略回退时正在运行的任务如何暂停与恢复。每一项都保留策略版本、操作时间、审计编号与复核人。这样的测试不需要预设模型会作恶，正如生产系统也不会因为开发者没有恶意就省掉访问控制。
还要区别安全边界与内容质量边界。OpenShell 可以阻止智能体写不该写的仓库，却不能证明它提交的代码没有漏洞；Sentry 可以观察和隔离异常行为，却不会自动替用户判断一条业务指令是否符合监管规定。对外发布、转账、删除生产数据、驱动实体机器这类后果重的动作，依然应该保留业务侧的人审、双人批准或硬件紧急停机。把最坏后果与触发权限分开列出，再决定在哪一层设置拦截，会比笼统喊“安全智能体”更有用。
对负责采购的企业，还应明确一份能力对照表：当前使用的容器隔离、网络代理、API 网关与秘密管理系统已经挡住哪些风险，OpenShell 新增的逐智能体策略和形式化检查究竟填补什么空缺。如果现有网关只认识服务账号，不认识具体任务或沙箱，那么同一账号下几十个代理共用授权就难以追责；如果现有环境已经对每个工作负载做了细粒度身份与 API 方法限制，额外部署则要以降低误配置和改善审计为证据。无需因为发布名称里有“平台”就一次性更换全部安全设施。
实施负责人还应指定策略的所有者。研发团队最了解实际 API，却可能倾向于为任务打通权限；安全团队善于识别危险权限，却不总清楚业务为什么需要它。让两者共同维护一份最小权限模板，并对每次扩权写下任务原因、到期时间及验证方式，才能让动态审批不变成永久授权的积累。生产上线后的季度复盘应统计被拒请求是否真实阻断危险操作、多少只是策略遗漏，以及人工审批是否造成任务卡顿；拿这些数据调整边界，而不是单纯追求拦截次数多。
这次发布有价值的地方，不是保证智能体永远不会犯错，而是把一个老问题重新说清：能做事的程序必须有能执行的权限边界，且边界最好位于程序触不到的位置。提示词可以告诉智能体该怎么做；真正决定它最多能做到哪一步的，仍然是系统设计。
原始资料
[1] NVIDIA Newsroom，2026-09-28，NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment：https://nvidianews.nvidia.com/news/open-agent-safety-platform
[2] NVIDIA Developer Blog，NVIDIA Open Agent Safety Platform: A Reference for Continuous In-Silicon Agent Monitoring：https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/
[3] NVIDIA Developer Blog，Add Runtime Controls to AI Agents with NVIDIA OpenShell：https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell
[4] NVIDIA/OpenShell 官方代码仓库：https://github.com/NVIDIA/OpenShell