AI安全是工程问题：智能体栈各层防护

AI安全不是一个等待更聪明模型来解决的研究问题，而是一个必须在Agent技术栈每一层落实的工程问题——它需要明确的安全需求、可强制执行的控制、有名字的责任人，以及能证明防护确实生效的证据。

这是NVIDIA在2026年9月21日发布的博文《AI Security Is an Engineering Problem — How to Solve It at Every Layer of the Agent Stack》给出的核心判断，作者是Saša Zdjelar。文章没有提出任何新算法或新模型，而是反复强调一件在AI热潮中容易被忽略的事：安全的基本功没有变，变的是它需要被应用到一个更复杂的系统上。

互联网和云计算教会我们的事，AI Agent必须重新学一遍

文章开篇就把AI安全拉回地面：互联网和云计算改变了软件的运行方式，但核心安全责任从未改变——建立身份、控制访问、限制暴露面、验证防护有效。这四件事在传统IT安全里是老生常谈，但AI Agent带来了新变量：推理、使用工具、根据遇到的数据动态调整行动。

这些新能力本身不是安全漏洞，但它们把老问题放大了。一个传统应用的行为路径相对固定，而一个Agent可能在运行过程中遇到一份被篡改的文档，然后"决定"把客户数据导出到未授权目的地。文章用这个具体场景说明：Agent的推理能力越强，越不能依赖它"自己判断该不该做"。

安全边界必须在Agent做出错误决策时依然成立。

这句话是整篇文章的工程哲学基础。它意味着安全不能建立在"模型足够对齐"或"提示词足够好"之上，而必须建立在Agent无法触及的外部控制上。

安全取决于整个Agent栈，而不是模型本身

文章明确拆解了Agent系统的构成：模型提供能力，harness组织上下文、工具和工作流，运行时环境提供行动执行的基础设施。数据、指令和动作在这三层之间流动，每一层都承载安全责任。

这个拆解的意义在于：它打破了"模型安全=AI安全"的简化思维。一个模型可能在基准测试中表现得很安全，但如果harness允许它调用未授权的工具，或者运行时环境没有网络出口限制，整个系统依然是不安全的。

文章举了一个具体的权限设计原则：更新客户记录的权限不应自动扩展为导出该数据的权限。Agent可以请求额外访问权限，但不能自己授权自己。这条原则在传统访问控制里叫最小权限原则，但在Agent场景下需要重新设计，因为Agent的行动是动态生成的，不能靠静态角色来穷举。

把安全建进Agent的运作方式里，而不是贴在表面

文章在这一节给出了几个可操作的工程要求：

每个Agent需要可追溯的身份和限定于其任务的凭证。组织需要明确策略，定义Agent可以访问什么信息、可以改变哪些系统、哪些动作需要人工批准。在边界之内，重大动作和权限变更仍然需要人类批准。

团队还需要验证Agent使用的工具、技能和依赖的来源与完整性。如果出了问题，受保护的工具调用记录、授权决策和结果要能帮助调查人员重建事件经过。清晰的撤销访问和遏制事件的程序，让这些证据变得可操作。

这里的关键词是"可追溯"和"可验证"。Agent的行为不是黑箱，至少不应该被当作黑箱来运营。每一次工具调用、每一次授权决策、每一次结果输出，都需要留下受保护的记录。这不是为了事后追责，而是为了让安全团队能在事件发生时快速定位问题。

文章在这里引入了NVIDIA的具体产品：NVIDIA OpenShell，一个开源安全运行时，在Agent触及范围之外强制执行策略，提供沙箱化执行，并治理Agent如何访问数据、网络和系统资源。

Open Secure AI Alliance的合作伙伴正在基于OpenShell构建：Cisco的DefenseClaw增加治理层，JFrog集成OpenShell来扫描和验证Agent技能，并强制执行哪些技能可以被Agent访问。这些细节说明NVIDIA的策略不是自己包揽一切，而是提供一个底层运行时，让安全厂商在之上构建垂直能力。

工程团队需要在部署前拿到安全证据

文章对"证据"的强调值得单独拎出来。部署前，团队需要证明适当的控制能阻止Agent获取超出其范围的凭证，或向未授权目的地发送敏感数据。测试还应覆盖尝试更改权限或干扰监控的行为，并且在模型、工具或工作流发生重大变化后重复测试。

这里有一个明确的组织要求：必须有具名的责任人使用这些测试结果来决定系统是否准备好部署，并确保失败的测试导致纠正行动。测试或运营中发现的失败应该被复现、调查和解决。每个发现可以变成一个可重复的测试，让团队检查修复在未来的版本中是否持续有效。

文章举了两个例子：CrowdStrike的SafeMind通过重复攻击模拟来测试和强化防御，Palo Alto Networks的Prisma AIRS在模型和应用变化时进行持续红队测试。这两个产品的共同点是持续性和可重复性——安全不是一次性的合规检查，而是随系统演进而不断重新验证的过程。

防御者需要在正确的时间拿到正确的工具

文章在这一节讨论了一个在AI安全圈有争议的话题：开源模型和闭源模型在防御中的角色。文章的立场是两者服务于互补的需求。闭源模型提供托管能力和服务，开源模型给防御者提供检查相关组件、调整策略、在可控基础设施上工作的选项。

在事件响应期间，这种控制权能帮助团队在自己的系统上复现失败并测试修复，同时将敏感证据保留在自己的环境中。这是一个很实际的考虑：安全团队在处理事件时，往往不能把敏感数据发给第三方API。

文章还提到，有能力的AI可以通过帮助发现漏洞、验证修复和调查攻击来支持这项工作。但它的价值应该通过可复现的发现、可验证的修复和加速的响应时间来评估。这句话实际上是在给AI安全工具设定评估标准：不要看它声称能做什么，要看它实际产出了什么可验证的结果。

例子包括Capital One的VulnHunter用于AI驱动的代码安全，ReversingLabs的Spectra Assure用于AI驱动的软件包分析以检测恶意软件和篡改。

通过开放工作把优势转向防御者

文章的最后一节回到生态层面：分享什么失败了、哪些控制有效、修复如何被验证，能帮助其他团队强化自己的系统。NVIDIA的安全研究和Open Secure AI Alliance通过将研究、实用工具和专业知识带入更广泛的安全社区来支持这种交流。

这个呼吁的紧迫性在于：攻击者已经在共享工具和技巧，防御者如果各自为战，差距只会扩大。文章没有明说但隐含的判断是：AI安全不是一个可以靠单点产品解决的问题，它需要整个行业在工程实践上达成共识并共享证据。

这对行业和从业者意味着什么

如果你是一个正在部署Agent的企业，这篇文章的实操含义是：不要等模型厂商解决安全问题，你的harness和运行时环境是你自己的责任。你需要定义Agent的身份、权限边界、工具调用记录和人工审批节点。你需要有具名的安全责任人和可重复的测试流程。

如果你是一个安全从业者，这篇文章的信号是：Agent安全正在从研究话题变成工程学科。需要的技能不是训练模型，而是设计访问控制、构建沙箱、编写可重复的安全测试、建立事件响应流程。这些技能在传统安全领域已经存在，现在需要被翻译到Agent的语境里。

如果你是一个AI产品开发者，文章里最值得记住的一句话是：

每个Agent部署都需要可强制执行的边界、一个负责任的所有者和证明其防护有效的证据。

这三件事没有一件是模型能力问题。它们都是工程问题。而工程问题的特点是：有明确的解法，需要的是执行而不是等待。