英伟达推开放智能体安全平台,企业需自主界定AI代理权限边界
英伟达发布Open Agent Safety Platform,通过OpenShell与Sentry实现智能体运行时管控;但平台不定义权限边界,企业须自行划分可自主执行、需审批及禁止的操作,并协调供应商工具、自身政策与新兴监管要求。

供应商正在为日益自主的AI智能体开发管控措施,而监管机构尚未就何为‘安全’达成共识,这使得企业必须自行决定智能体应被赋予多大权限,以及何时需要人工监督。
英伟达(Nvidia),这家AI芯片巨头 于周一推出了其Open Agent Safety Platform(开放智能体安全平台) ,为企业提供了一层新的管控能力,用于管理智能体的访问权限与操作行为。
此举正值人们对AI智能体绕过应用级防护措施的担忧日益加剧之际。它也凸显了一个 治理缺口:在供应商构建管控智能体行为的工具、监管机构确定适用哪些要求的同时,企业必须将供应商提供的管控措施与新兴监管要求同自身政策相协调。
英伟达围绕智能体设置管控措施
英伟达该平台结合了OpenShell(一种开源运行时环境,可在智能体运行期间管控其访问权限与操作行为)与Sentry(一种参考设计方案,利用独立的控制层对上述限制进行监控与强制执行)。
这一方法反映了组织在AI系统日趋自主化背景下,对其治理方式所发生的转变。 传统AI防护措施 主要在模型或应用层面运行,而智能体管控措施则可转而限制智能体的访问权限、操作行为及自主性。
网络安全模拟公司SimSpace的首席技术官兼联合创始人Lee Rossey表示,随着智能体获得调用工具、访问系统及自主决策的能力,这些管控措施应独立于智能体本身运行。
Rossey表示:“模型级护栏只是安全架构中的一层。企业还需要围绕智能体设置管控措施,明确其可访问的内容、可抵达的位置,以及必须停止运行的时机。”
这种分离至关重要,因为智能体即使未采取恶意行为,也可能引发安全问题。它可能严格遵循指令行事,却仍执行了组织本不打算允许的操作。
Rossey表示:“实施边界的系统不应依赖智能体自身来尊重该边界。”
英伟达表示,已有超过100家组织正在使用其智能体安全技术,其中包括微软(Microsoft)、Salesforce、SAP、ServiceNow、思科(Cisco)和Scale AI。
然而,此类参与并未使英伟达的方法成为监管标准。但若获广泛采用,则可能影响企业在评估智能体安全管控措施时对供应商的期望。
界定智能体权限
英伟达的智能体安全平台可提供用于强制执行智能体边界的各类技术工具,但并未指明这些边界应划在何处。该决策权仍属于组织自身,尤其当智能体获得更强的独立行动能力时更是如此。
AI合规平台供应商IO公司首席执行官Chris Newton-Smith表示:“技术无法决定这些边界应如何设定。这一责任仍由部署智能体的组织承担。”
网络安全咨询公司Gadget Access的首席信息安全官Andrew Curtis举例说明了限制智能体访问权限与其行为是否适当之间的区别。
Curtis表示:“智能体可能始终处于其沙箱之内,却仍批准了错误的付款。”他指出,智能体可能有权访问财务应用程序,但未必被授权执行该程序所提供的全部交易。
因此,企业需区分三类操作:智能体可独立执行的操作、需经人工审批的操作,以及智能体绝不可执行的操作。
最终,这意味着须依据业务需求而非简单接受供应商框架内预设的权限,来定义智能体的角色与权限。
立法者正采取不同路径
联邦政策制定者也在权衡应如何处理AI自主性相关责任问题。
《 AI Kill Switch Act(AI紧急关停法案)》由加州民主党众议员Ted Lieu与得克萨斯州共和党众议员Nathaniel Moran共同提出,该法案将要求某些强大AI系统的开发者维持技术能力,以减缓或关停这些系统。
《Stop Rogue AI Act(遏制失控AI法案)》由新泽西州民主党众议员Josh Gottheimer与纽约州共和党众议员Mike Lawler共同提出,采取了不同路径,指示 美国国家标准与技术研究院(NIST) 制定标准,供组织用于发现、监控与管控AI智能体。
这两项提案体现了针对AI自主性的两种路径:一是监管开发者对强大系统的控制能力,二是为部署智能体的组织确立标准。
IO公司首席执行官Smith表示,组织不能仅依赖供应商开发的框架或新兴法规来确立适当的边界。
他表示:“组织需要超越单一供应商的治理机制,明确问责制、权限划分、风险评估、访问控制、监控及人工监督,无论其部署的是何种智能体或平台。”
英伟达的平台并未解决这一政策辩论。其管控措施运行于部署层,为企业提供了在其自有环境中建立并强制执行智能体边界的机制。
供应商可能影响AI自主性的治理方式
对企业而言,由供应商定义的技术标准即便缺乏政府强制要求,也可能影响治理实践。
倘若主流科技供应商围绕兼容的智能体防护方法构建产品,企业采购方在评估AI平台时便可能开始期待具备此类能力。即便未获正式监管认可,供应商框架最终也可能成为智能体治理的实际基准。
Curtis表示:“供应商框架可影响实际标准,因为开发者倾向于采用最易实现的接口、策略模板及日志格式。久而久之,这些选择可能进入企业的采购要求与保障流程。”
然而,各公司可能开发相互竞争的方法,而监管机构亦可能出台与行业实践不同的要求。这将迫使企业协调供应商防护措施、自身政策及任何新兴监管规定。
企业仍须设定限制
由于企业治理必须超越任一单一供应商,组织必须应对三个重叠层面:监管机构设定要求、供应商构建技术管控措施、企业决定赋予其智能体多大权限。
Curtis表示:“对于已超越试点阶段的企业而言,维护一份智能体清单至关重要,清单内容应包括智能体本身、其所有者、所连接系统及其获准执行的操作。”组织还应区分 智能体可独立执行的操作、需经审批的操作,以及应予禁止的操作。
技术控制措施可使这些决策具备强制执行力,但无法取代企业界定这些决策的责任。
随着AI代理承担起更具重大影响的工作,“足够安全”这一问题因此不仅关乎某项技术控制措施能否约束住一个代理,还取决于由谁来界定该代理的权限、由谁对该决策负责,以及组织能否验证自身是否正在切实执行这些边界。
英伟达(Nvidia)最新举措表明,用于强制执行代理边界的工具正逐步成形;然而,决定这些边界应设于何处,仍属于企业的责任。
JOTO 企业落地观察
- 对企业部署而言,英伟达平台虽提供运行时管控能力(如OpenShell限制访问、Sentry强制执行),但未预设任何业务级权限规则——企业必须基于自身风控体系,明确每类智能体在财务、系统调用等场景中的操作红线,否则技术工具无法自动规避‘合规但有害’行为。
- 对智能体工程而言,文章强调管控层须独立于智能体本身运行(如Sentry作为外部控制层),这要求工程架构从‘模型护栏’转向‘智能体沙箱+外部仲裁’双层设计;开发者不能再依赖提示词或微调约束行为,而需构建隔离的权限决策与审计通道。
- 对AI安全治理而言,当前存在供应商框架(如Nvidia)、立法提案(如AI Kill Switch Act)与企业策略三重割裂:技术工具可执行边界,但谁定义边界、谁担责、如何验证执行效果,仍无统一答案——这意味着FDE落地必须将‘治理流程’而非‘防护模块’作为核心交付物。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们


