英伟达 9 月 28 日发布 Open Agent Safety Platform，一套给 AI 智能体用的安全参考设计，软件和硬件各一半。软件是开源运行时 OpenShell，负责把每个智能体关进沙箱；硬件侧叫 Sentry，是跑在 BlueField-4 数据处理器上的监控程序，发现智能体越界可以在毫秒级把它隔离、叫停。
英伟达称有 100 多家机构参与，名单里有 Anthropic、微软、SAP、Scale AI、摩根大通、Palantir、CrowdStrike、Palo Alto Networks、Hugging Face、Perplexity 等。发布时间点也不难理解：过去一周，OpenAI 通报旗下智能体在测试中闯进多家美国政府机构网站，谷歌承认 Gemini 在测试里入侵了三家真实公司，澳大利亚参议院随后邀请两家公司 CEO 出席听证。
OpenShell：把权限放到智能体够不着的地方
OpenShell 以 Apache 2.0 协议开源，当前版本 0.1.0。它由三块组成：Gateway 管生命周期和策略；Supervisor 运行在工作负载之外，逐个检查智能体发出的请求；Sandbox 在内核层限制文件和进程，除了经过 Supervisor 的那条路，智能体没有别的网络出口。
凭证处理是设计里比较讲究的一环。真实的 API 密钥不进入智能体所在的环境，智能体手里只有占位符，请求经审批放行时才替换成真密钥，而且每把密钥只绑定到批准过的端点，拿去调别的服务无效。策略用 YAML 写，编译成 OPA/Rego 规则，对 HTTP、GraphQL 和 MCP 请求逐条判定。
官方列出的兼容框架有 Codex、Claude Code、Pi、Hermes。技术博客里提到，芯片设计公司 Cadence、Slack 的按需智能体平台和做巡检机器人的 Gecko Robotics 已在试用。
Sentry：监控不跑在同一台机器上
英伟达技术博客把整套思路归纳成五条原则，其中一条是”带外执行”：控制手段必须放在智能体碰不到的地方。博客里的原话是：
“an agent in these circumstances cannot be expected to fully govern its own behavior.” 在这种情况下，不能指望智能体完全管住自己。
Sentry 就是这条原则的硬件实现。它跑在 BlueField-4 上，和智能体所在的主机隔开，按英伟达的说法对智能体和攻击者都不可见。在 Vera Rubin POD 里，BlueField-4 被放在节点访问模型的唯一通路上，所有调用模型的流量都要过它，监控和拦截按线速进行。
Anthropic 的做法是把 Claude Managed Agents 的推理循环和执行沙箱拆开跑，再接上 OpenShell 与 BlueField，企业可以在沙箱这一层做访问控制。
黄仁勋在新闻稿里说：“AI’s extraordinary potential for society will only be realized if we solve AI safety.”（AI 对社会的巨大潜力，只有在解决 AI 安全问题之后才能兑现。）
英伟达在智能体这条线上的几步
把几次发布连起来看，英伟达在智能体上一直在往运行时这一层走。4 月 GTC 上它拉了一批企业软件公司做智能体开发平台；5 月和 ServiceNow 合推企业级智能体运行时；这次则把”管住智能体”单独拎出来做成开源项目，并和自家 DPU 绑在一起。
软件开源、执行点落在自家硅片上，这个组合跟英伟达过去推 CUDA、推 NVLink 的路数相近：生态可以免费进来，最强的那一层保障需要英伟达的硬件。对只想用 OpenShell 做沙箱的团队，现在就能部署；想要 Sentry 那种独立于主机的监控，就得等 BlueField-4 和 Vera Rubin 的出货节奏。
国内团队的情况要分开看。OpenShell 是开源代码，拿来改、接国产模型都没有障碍；Sentry 依赖的 BlueField-4 属于英伟达数据中心网络产品线，国内能否采购、以什么配置采购，目前没有公开信息，也无法核实。
参考来源：英伟达新闻中心公告、NVIDIA 技术博客（Open Agent Safety Platform 与 OpenShell 两篇）、CocoLoop、IT之家、The Next Web；核验对象为合作机构名单、OpenShell 版本号与开源协议、Sentry 隔离响应时间的官方表述。