英伟达提出：AI 安全是工程问题，需在智能体全栈每一层落实可验证的控制

英伟达在官方博客发表了一篇由 Saša Zdjelar 撰写的文章，日期为 2026 年 9 月 21 日，标题直截了当：AI 安全是工程问题。文章的核心观点是，安全不能停留在口号和提示词里，而要落实为明确的安全要求、可强制执行的控制措施、有名有姓的负责人，以及能证明防护有效的证据。随着 AI 能力继续增强，行业需要加快安全工程的步伐，把防御工具推向更多使用者，并更快地分享哪些做法真正有效。 文章先从一个朴素的事实说起：技术在变，安全的基本职责没变。互联网和云计算改变了软件的运行方式，但建立身份、控制访问、限制暴露面、验证防护有效，这些要求一直都在。AI 智能体带来了新的能力：它们会推理，会调用工具，还会根据遇到的数据调整自己的动作。这些能力并不否定旧原则，而是要求把旧原则放到新的运行条件下重新应用。文章也坦率指出了压力的来源：企业想要 AI 带来的生产力，而治理和保护这类系统的方法仍在形成之中。

理解全文的关键，是「全栈」这个视角。应用依赖代码、数据、身份、服务和基础设施，安全取决于这些部件如何协同，而 AI 智能体扩展了这个系统。文章把智能体拆成三层：模型提供能力；harness（编排层）组织上下文、工具和工作流；运行时环境提供动作得以执行的基础设施。每一层都有各自的安全职责，数据、指令和动作在系统中流动时，每一层都需要控制，而不能指望某一层单独兜底。 文章用一个具体场景说明这一点。假设一个智能体正在更新客户记录，却在附件文档里读到了恶意指令，并试图把客户数据导出到未授权的地址。此时，网络策略应当拦截这次传输，受保护的日志应当记下被尝试的工具调用、授权决定与结果，让安全团队能查清用了哪个工具、想去往哪个目的地。更重要的是权限的粒度：更新客户记录的权限，不应自动延伸为导出这些数据的权限。智能体可以申请额外权限，但不能自己批准自己的申请。

由此引出文章最有分量的一句话：安全边界必须在智能体做出错误决定时依然成立。这意味着，限制不能依赖智能体自己的判断。智能体运行的环境要在它的推理之外，对文件、网络目的地和进程设置约束。指令和护栏可以引导行为，但真正的安全还需要可强制执行的边界。落到工程上，文章列出了几项要求：每个智能体要有可追溯的身份，凭据只限于分配给它的任务；组织要有清晰的策略，规定智能体能访问哪些信息、能改动哪些系统、哪些动作必须先经批准；重大动作和权限变更仍然需要人工批准；团队还要核实智能体所用工具、技能和依赖项的来源与完整性。 出事之后怎么办，文章同样有交代。对工具调用、授权决定和结果的受保护记录，能帮助调查人员还原经过；而撤销访问、遏制事件的明确流程，则让这些证据能够转化为行动。换句话说，日志不是为了好看，而是为了让响应有据可依。 在产品层面，英伟达推出了 NVIDIA OpenShell，这是一个开源的安全运行时，在智能体够不到的位置执行策略，提供沙箱化执行，并管控智能体对数据、网络和系统资源的访问方式。文章提到，Open Secure AI Alliance 的合作伙伴正在基于 OpenShell 构建：Cisco 的 DefenseClaw 增加了一层治理，JFrog 则与 OpenShell 集成，用于扫描并验证智能体技能，并对智能体可使用哪些技能实施策略。

文章的第二个重点是证据。上线之前，团队需要看到证据，证明控制措施能挡住两类尝试：获取超出智能体范围的凭据，以及把敏感数据发往未授权目的地。测试还应覆盖修改权限、干扰监控这类尝试，并且在模型、工具或工作流发生实质变化后重复进行。需要一位指名的负责人，用这些结果判断系统是否可以部署，并确保失败的测试带来整改。测试或运行中发现的故障要被复现、调查和处理，每个发现再变成可重复的测试，以便在以后的版本里确认修复依然有效。文中给出的例子包括 CrowdStrike 的 SafeMind（通过反复的攻击模拟来测试和加固防御）和 Palo Alto Networks 的 Prisma AIRS（在模型和应用不断变化时做持续红队测试）。 第三部分谈防御者手里的工具。文章认为，调查故障需要与任务、数据和环境相匹配的能力，开放模型与封闭模型满足的是互补的需求：封闭模型提供托管的能力和服务，开放模型则让防御者可以检查相关组件、调整策略，并在自己控制的基础设施上工作。事件发生时，这种控制权能帮助团队复现故障、在自己的系统上验证修复，同时把敏感证据留在自己的环境里。文章还提到，能力强的 AI 可以帮助发现漏洞、验证修复和调查攻击，其价值应以可复现的发现、可验证的修复和更快的响应时间来衡量。示例包括 Capital One 的 VulnHunter（AI 驱动的代码安全）和 ReversingLabs 的 Spectra Assure（用 AI 分析软件包，检测恶意代码与篡改）。文章末段以「通过开放协作让优势向防御者倾斜」为题，主张分享哪些环节失败、哪些控制有效；我们拿到的原文摘录在这里中断，因此该部分的细节不在此展开。

需要说明的是，这是一篇理念与框架性质的博客文章，原文没有给出性能基准、成本数字或量化的防护效果，所以我们不能据此判断这些方案在多大程度上降低了风险。以下是基于文章内容的分析。对开发者而言，最直接的启示是把权限模型和隔离放在智能体之外：给每个智能体独立身份、最小权限的凭据，把网络和文件限制交给运行时来强制，而不是写进系统提示。对企业而言，要为每个智能体部署指定负责人，把「红队测试通过」设为上线门槛，并把每一次事故沉淀为回归测试。对生态而言，OpenShell 加合作伙伴的组合显示出一种分工：运行时负责强制，治理层、供应链扫描和持续红队测试各自补位。 挑战同样明显。第一，策略要写得足够细，才能做到「能更新记录但不能导出」这样的区分，而细粒度策略的维护成本不低。第二，供应链问题不会消失：技能和依赖项的来源核验，需要生态内的共同标准。第三，持续测试意味着持续成本，文章没有讨论由谁来承担。第四，这篇文章出自一家销售相关平台的厂商，读者在采纳其框架时，应当结合自身环境独立评估。不过，把安全表述为可验证、可归责的工程项，而不是一次性的承诺，这个方向对整个行业都有参考价值。