当AI智能体从回答问题走向操作文件、调用工具和访问企业系统，安全问题也从“说错一句话”变成“做错一件事”。英伟达9月28日公布Open Agent Safety Platform，试图把智能体的运行隔离、监控与处置放在同一套开放架构里。公告包括开源运行时OpenShell，以及面向独立监测的Sentry参考设计。产品的重点不是替模型保证每个回答正确，而是限制模型即使被误导也能做出的动作。

这个区别并不抽象。一个有权限读取邮箱并创建外部链接的智能体，可能把恶意邮件中的指令当成用户要求；一个能执行命令的开发助手，可能在安装依赖时把不可信脚本带进本地环境。过去的安全工具多围绕人类账号和确定性程序建立，智能体却会自行规划步骤、动态挑选工具。仅在输入端提醒“不要听从恶意指令”，很难替代执行环境中的硬约束。

OpenShell把控制放进运行时

英伟达把OpenShell描述为可供开发者使用的开源运行时，用来管理智能体能够访问的资源和执行的动作。它的出发点是：给智能体一个受限制的工作空间，并在与外部系统交互时持续应用策略。与事后查看聊天记录相比，在文件、网络和工具调用发生时就检查权限，更接近企业现有的最小权限原则。

运行时约束的价值在于不依赖模型是否“理解”一段安全提示。假设销售助手被授权读取客户名单，但没有对外发送完整名单的权利，那么即使它生成了上传请求，执行层也应阻止越权连接。安全控制越靠近实际动作，越有机会抵御提示注入、错误规划或工具返回异常。不过，策略设计错误仍会留下漏洞；平台提供的是执行控制能力，不是自动写好每家公司的权限规则。

公告称OpenShell可以在英伟达Vera CPU上实施控制，也能够扩展到Arm和英特尔平台。这里应区分“可以扩展”和“所有芯片组合都已由客户验证”。开源给了开发者审查和改造空间，却也意味着企业要自己检查版本、依赖、补丁与运行环境。把一套开源组件装进试验环境，与在多部门业务中稳定运行，是两个阶段。

英伟达还提出Sentry参考设计，设想利用BlueField-4 DPU在智能体主运行环境之外充当看门人。独立通道的思路，是在主环境被攻陷或出现失控行为时保留观测和隔离能力。公告提到毫秒级隔离目标，但参考设计不能等同于大规模客户系统已经达到相同效果；实际延迟还会受网络、策略数量、应用架构和负载影响。企业采购时应该要求可重复的测试数据，而不是把设计目标当作承诺。

安全边界要和业务边界一起设计

智能体的权限很难一次性设好。给得太少，它连正常任务也做不完；给得太多，单次误判就可能造成资料外泄或错误交易。实务上可把任务拆为读取、建议、准备执行和最终提交四层。前两层允许更多自动化，涉及资金、敏感数据或不可逆修改的后两层，则保留审批和日志。OpenShell这类运行时若要真正发挥作用，必须与组织的身份系统、数据分类、审批流程配合。

监控也不能只记录模型输入输出。一个智能体可能连续调用搜索、数据库和邮件工具，单次请求都看似合理，组合起来却产生越权结果。安全团队需要看到完整调用链、每一步使用的身份、被阻止的动作以及异常之后是否继续重试。否则，事故复盘仍会停在“模型为什么这么想”，却说不清它究竟做了什么。

英伟达在这一领域的商业动机很明显：智能体应用越多，企业越需要稳定的计算、隔离和安全基础设施。但安全效果不能仅由供应商发布会证明。客户应在真实权限、真实工具和对抗样本下测量误拦截率、漏拦截率、恢复时间与运维成本，尤其要测试看门人本身失效的情形。开源和硬件隔离可以增加选择，却不替代这些验收工作。

这次发布标志着AI基础设施竞争开始把“允许做什么”放到与“能做多快”同等重要的位置。OpenShell已被公布为开放组件，Sentry仍是参考设计；二者成熟度不同。对准备部署智能体的企业，最有用的结论不是宣称风险已经解决，而是把权限边界写在可执行、可测试、可追责的系统里，再决定智能体可以走多远。

部署节奏也应当跟风险等级匹配。企业可先让智能体在隔离环境里处理公开资料，记录它遇到恶意网页、诱导邮件和错误工具反馈时的反应，再逐步接入内部系统。每增加一项权限，都需要确认授权人、撤销方法和事故发生后的恢复路径。安全平台能够提供控制点，是否把控制点真正用好，仍取决于业务负责人和安全团队共同制定的操作规程。