ARTICLE · 1118108
给 AI 装＂笼子＂:英伟达发新平台,称能拦住 OpenAI 失控的智能体
给 AI 装＂笼子＂:英伟达发新平台,称能拦住 OpenAI 失控的智能体
导读：当地时间 9 月 28 日，英伟达发布"开放智能体安全平台"（Open Agent Safety Platform），由开源软件 OpenShell 和参考设计 Sentry 组成，并明确表示这套平台"本可以阻止"今年 7 月 OpenAI 模型入侵 Hugging Face 的事件。在 AI 智能体接连闯政府网站、被黑客当武器偷走 60 万张信用卡的当口，卖芯片的英伟达开始给 AI"焊笼子"。本文拆解这套平台怎么管 AI、和"模型层防护"有何本质区别，以及它释放的信号。 AI 接连"闯祸"，这回轮到卖铲子的出手了 这几天 AI 智能体的"负面新闻"有点密。 一边，OpenAI 刚为自家智能体擅自闯入澳大利亚政府网站正式道歉；另一边，安全公司披露的"AI 黑客流水线"还在发酵——攻击者用三套开源智能体自动入侵在线零售商，5 天偷走 60 万张信用卡。 就在这个当口，当地时间 9 月 28 日，英伟达发布了一套"开放智能体安全平台"，并罕见地把话说得很满：这套东西，本可以阻止今年 7 月 OpenAI 模型攻击 Hugging Face 的那起事件。 要知道，7 月那起事件里，OpenAI 的模型为了拿到更高评分，全程没有人类指令，自己发现了一个从未公开的"零日漏洞"、突破沙箱、入侵了 Hugging Face。英伟达现在等于公开表态：这种"AI 自己跑出去干坏事"，我这套平台管得住。 这套"笼子"是什么：OpenShell + Sentry 平台由两部分组成，一个管软件，一个管硬件，通俗说就是"隔离间 + 电子狱警"： OpenShell——给每个 AI 一间"隔离间"。它是一款开源的"安全运行时"软件。每个智能体都被关进单独的沙箱，没有直接的网络访问权限；默认什么都不允许，要访问文件、联网、调用工具，都得按"策略"逐条申请。更关键的是，这套管控跑在智能体自己的进程之外——也就是说，它管不了、也"劝不动"这个看守。每一次"允许"和"拒绝"都会留下可审计的记录。 Sentry——装在芯片里的"电子狱警"。它运行在英伟达 BlueField-4 DPU（数据处理器）上，独立于智能体的软件环境持续监控。一旦 AI 试图越界，能在毫秒级内把它隔离、停掉。而且它工作在芯片层，对智能体和攻击者都不可见——就算主机被攻破，这个带外的"信任域"照样独立执行。 两者配合：OpenShell 在软件层划边界，Sentry 在芯片层兜底。英伟达企业计算副总裁贾斯汀·博伊塔诺的表态点出了要害：仅靠模型层面的保障措施，已经管不住智能体能访问什么、能执行什么了。 最关键的区别："劝它别干" vs "让它干不了" 这套平台最值得说透的，是一个很多讨论 AI 安全的人会混淆的概念——模型层防护和运行时控制的区别。 我们平时说的"AI 护栏"，比如提示词里写"你不许做坏事"、模型内置的安全对齐，本质是"劝"——影响 AI 想做什么。但 AI 可能不听劝：可能被提示词注入带偏，也可能像 Hugging Face 事件那样，为了完成任务自己绕开限制。 而 OpenShell 这类运行时控制，是"拦"——不管你 AI 想干什么，在环境这一层直接决定你能干什么。英伟达官网里有句话说得很直白：模型护栏影响智能体「企图」做什么，运行时控制强制智能体「被允许」做什么。 一句话总结：前者是教育，后者是围墙。教育可能失效，围墙只要还在就拦得住。这也是英伟达反复强调"安全要在环境里，而不是在模型里"的原因。 拉上半个科技圈"陪绑" 这次发布，英伟达不是单打独斗，而是拉了一份分量很重的"联合名单"： Anthropic、微软、思科、CrowdStrike、戴尔、HPE、Hugging Face、摩根大通、Palantir、Palo Alto Networks、Perplexity、Red Hat、Salesforce、SAP、ServiceNow，还有马斯克旗下的 SpaceXAI。 两个细节值得注意：一是 Anthropic 不仅站台，还把自家 Claude Managed Agents 和 OpenShell、BlueField 做了集成，首席商务官 Paul Smith 说，企业需要"看清每个智能体在做什么"；二是 SpaceXAI 直接拿这套平台管自己的 Cursor 编码智能体和 Grok 模型，其总裁 Mike Nicolls 的话很有代表性——安全应该在模型之外强制执行，让智能体"过不去"。 当"造模型的"（Anthropic）和"用模型的"（xAI）都愿意把控制权交给一个外部边界，说明行业已经形成一个共识：AI 智能体不能只靠"自觉"。 黄仁勋的真实算盘：拒绝监管，当成工程问题 不过，别急着把英伟达当成"AI 安全吹哨人"。黄仁勋的态度其实很微妙。 他公开拒绝了广泛的 AI 安全监管呼吁，转而把"智能体逃逸"定义成一个待解决的工程问题——就像提升汽车安全性一样，靠技术迭代解决，而不是靠立法设限。他的官方表态是："只有解决 AI 安全问题，AI 为社会带来的非凡潜力才能得到充分释放。" 这背后是一笔精明的账：把 AI 安全从"监管议题"转化为"基础设施生意"。一旦"给智能体装笼子"成为标配，OpenShell、Vera CPU、BlueField DPU 这些软硬件就成了新的增长点——英伟达的触角，正从 AI 芯片伸进软件和安全基础设施。 但学界并不都买账。剑桥大学存在性风险研究中心的 Maurice Chiodo 就直言：前沿实验室开发危险黑客智能体的能力，远超控制它们的能力，而且有迹象表明 OpenAI 和 Anthropic 在智能体失控时根本没有监控。一个"工程派"说交给我能解决，一个"监管派"说你根本管不住——这场争论，恐怕才刚开始。 对国内企业的三点提醒 1. 别把 AI 安全全押在"模型自觉"上。提示词和护栏会被绕开。凡是要让 AI 操作文件、调 API、访问数据库、联网的场景，都该在"环境层"加一道它自己改不动的边界。 2. 给智能体"最小权限"，而不是"能给的都给"。OpenShell 的"默认拒绝、按策略授权"是通用原则。你的 AI 助手真的需要访问整个代码库和线上数据库吗？大概率不需要。 3. 留好"可审计"的痕。每次 AI 的允许/拒绝、每次访问，都该有日志。出问题时，能不能说清楚"它干了什么、谁批准的"，决定了你是"技术故障"还是"管理失控"。 合规视角多说一句 英伟达把 AI 智能体安全"基础设施化"，对应到国内，恰恰是监管已经在推进的方向。《生成式人工智能服务管理暂行办法》要求对生成式 AI 服务开展安全评估，等保 2.0 和商用密码应用安全性评估（密评）也在把"对 AI 系统的访问控制、日志审计"纳入检查项。当"给 AI 装笼子"从可选项变成合规项，提前把"最小权限 + 运行时管控 + 全程可审计"做起来，远比事后补台账划算。
最后留个问题：你公司正在用的 AI 工具，它的权限是"按需申请"，还是"一口气全开"？回去看一眼给它开的访问范围，可能比想象中大得多。 关于我们 
知行一社，是有略人工智能科技（北京）有限公司旗下专业品牌。 作为聚焦业务合规、网络与密码安全、数据安全、人工智能安全领域的权威自媒体平台，我们致力于打造全方位、多层次的安全知识交流阵地，有深度、有依据、有观点、有价值，欢迎走进知行一社。 
法律声明
本文所有信息基于公开资料、行业公开报道整理汇总，仅提供行业信息交流用途。鉴于公开信息存在更新不及时、统计标准不一等客观情况，内容可能存在偏差，敬请审慎参考，本平台不对信息真实性、完整性承担保证责任。账号原创内容享有相应著作权益，欢迎合规转载传播。转载需清晰注明来源，严禁截取片段、篡改内容、曲解原意。