AI安全是工程问题——如何在Agent栈每层解决

AI安全是一个工程问题。这意味着明确的安全要求、可执行的控制措施、指定的负责人以及保护措施有效的证据。

随着AI变得更加强大，行业必须加快安全工程，扩大防御工具的访问权限，并更快地分享有效的方法。

技术改变，安全基础长存

互联网和云计算改变了软件的运作方式，而核心安全职责依然存在：建立身份、控制访问、限制暴露范围，并验证保护措施有效。

AI代理引入了新的能力——推理、使用工具和根据遇到的数据调整操作。这些能力需要将既定原则应用于新的运行条件。

这个步伐造成了压力。组织想要AI的生产力效益，但管理和保护这些系统的做法仍在开发中。

安全取决于完整的代理堆栈

应用程序依赖于代码、数据、身份、服务和基础设施。安全取决于这些组件如何协同工作——AI代理扩展了该系统。

模型提供能力；工具框架组织上下文、工具和工作流；运行时环境提供执行操作的基础设施。该堆栈的每一部分都承担安全责任，正确的保护需要跨每一层的控制，因为数据、指令和操作在系统中移动。

考虑一个更新客户记录的代理。假设它在附加文档中遇到恶意指令，并尝试将客户数据导出到未授权的目的地。

网络策略应该阻止传输，受保护的日志应该捕获尝试的工具调用、授权决定和结果，以便安全团队能够识别所使用的工具和它尝试到达的目的地。

更新客户记录的权限不应自动扩展到导出该数据。代理可以请求额外的访问权限，但它不能自行授权该访问权限。

将安全融入代理的运行方式

即使代理做出错误的决定，安全边界也必须保持。代理运行的环境决定了它被允许做什么，因此必须独立于代理的推理在文件、网络目的地和进程上安装限制。

指令和保护措施可以帮助指导行为，但安全还需要可执行的边界。

每个代理需要可追溯的身份和限制在其分配任务范围内的凭证。组织需要明确的策略，定义代理可以访问哪些信息、可以更改哪些系统以及哪些操作需要批准。在这些边界内，重大操作和权限更改仍需要人工批准。

团队还需要验证代理使用的工具、技能和依赖项的来源和完整性。如果出现问题，受保护的工具调用、授权决定和结果记录可以帮助调查人员重建发生了什么。清晰的撤销访问权限和控制事件的程序使该证据可采取行动。

NVIDIA OpenShell是一个开源、安全的运行时，在代理的范围之外执行策略，并提供沙箱执行，同时管理代理如何访问数据、网络和系统资源。开放安全AI联盟合作伙伴在OpenShell基础上进行构建：思科的DefenseClaw添加了一个治理层，JFrog与OpenShell集成以扫描和验证代理技能，并对代理可以访问的技能执行策略。

工程团队需要安全性证据

在部署前，团队需要证据表明适当的控制措施能够阻止获取超出代理范围的凭证或将敏感数据发送到未授权的目的地的企图。

测试还应该涵盖尝试更改权限或干扰监视的企图，并在对模型、工具或工作流进行重大更改后重复进行。

一个指定的负责人必须使用这些结果来决定系统是否准备好部署，并确保测试失败导致纠正措施。在测试或运行中发现的故障应该被重现、调查和解决。每个发现都可以成为一个可重复的测试，允许团队检查修复在未来版本中是否继续有效。

例子包括CrowdStrike的SafeMind，用于通过重复攻击模拟来测试和加强防御，以及Palo Alto Networks Prisma AIRS用于在模型和应用程序改变时进行持续的红队演练。

防御者需要在正确的时间拥有正确的工具

调查故障需要适合任务、数据和环境的有能力的工具。开放和封闭模型满足互补的需求。

封闭模型提供受管的能力和服务，而开放模型为防御者提供选项来检查相关组件、调整策略并在他们控制的基础设施上工作。

在事件发生期间，该控制可以帮助团队重现故障并针对其自身系统测试修复，同时将敏感证据保留在其环境内。

有能力的AI可以通过帮助发现漏洞、验证修复和调查攻击来支持这项工作。其价值应该通过可重复的发现、可验证的修复和加快响应时间来评估。

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

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

分享关于什么失败、哪些控制有效以及如何验证修复的证据，可以帮助其他团队加强他们自身的系统。

NVIDIA的安全研究和开放安全AI联盟通过将研究、实用工具和专业知识带入更广泛的安全社区来支持这种交流。