AI安全是一个工程问题——如何解决代理堆栈每一层的安全问题
摘要
本文将AI安全视为一个工程问题,强调需要在代理堆栈的所有层面实施安全控制,并介绍了如NVIDIA OpenShell等工具来执行策略。
<div id="bsf_rt_marker"></div><p><span style="font-weight: 400;">AI安全是一个工程问题。这意味着需要明确的安全要求、可执行的控制措施、指定的责任人以及保护措施有效的证据。</span></p>
<p><span style="font-weight: 400;">随着AI能力不断增强,行业必须加速安全工程的发展,扩大防御工具的访问权限,并更迅速地分享有效实践。</span></p>
<h2><b>技术变迁,安全基础不变</b></h2>
<p><span style="font-weight: 400;">互联网和云计算改变了软件的运行方式,但核心安全职责依然不变:建立身份验证、控制访问、限制暴露并验证保护措施的有效性。</span></p>
<p><span style="font-weight: 400;">AI代理引入了新能力——推理、使用工具以及根据遇到的数据调整操作。这些能力需要将既定原则应用于新的操作条件。</span></p>
<p><span style="font-weight: 400;">这种快节奏带来了压力。组织希望获得AI的生产力优势,而治理和保护这些系统的实践仍在发展中。</span></p>
<h2><b>安全依赖于完整的代理堆栈</b></h2>
<p><span style="font-weight: 400;">应用程序依赖于代码、数据、身份、服务和基础设施。安全取决于这些组件如何协同工作——而AI代理 </span><a target="_blank" href="https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack/"><span style="font-weight: 400;">扩展了这一系统</span></a><span style="font-weight: 400;">。</span></p>
<p><span style="font-weight: 400;">模型提供能力;工具链组织上下文、工具和工作流;运行时环境提供操作执行的基础设施。堆栈的每个部分都承担安全职责,适当的保护需要在每个层面实施控制,因为数据、指令和操作在系统中流动。</span></p>
<p><span style="font-weight: 400;">考虑一个代理更新客户记录的场景。假设它在附加文档中遇到恶意指令,并尝试将客户数据导出到未授权的目标。</span></p>
<p><span style="font-weight: 400;">网络策略应阻止传输,受保护的日志应捕获尝试的工具调用、授权决定和结果,以便安全团队能够识别所使用的工具和试图到达的目标。</span></p>
<p><span style="font-weight: 400;">更新客户记录的权限不应自动扩展到导出该数据。代理可以请求额外访问权限,但它不能自行授权该访问。</span></p>
<h2><b>将安全构建到代理的操作中</b></h2>
<p><span style="font-weight: 400;">安全边界必须在代理做出错误决策时仍然有效。代理运行的环境决定了它被允许做什么,因此必须独立于代理的推理,对文件、网络目标和进程设置限制。</span></p>
<p><span style="font-weight: 400;">指令和保障措施可以帮助引导行为,但安全还需要可执行的边界。</span></p>
<p><span style="font-weight: 400;">每个代理需要一个可追溯的身份和仅限于其分配任务的凭证。组织需要明确的策略,定义代理可以访问哪些信息、可以更改哪些系统以及哪些操作需要批准。在这些边界内,重要操作和权限变更仍需人工批准。</span></p>
<p><span style="font-weight: 400;">团队还需要验证代理使用的工具、技能和依赖项的来源和完整性。如果出现问题,受保护的工具调用、授权决定和结果记录有助于调查人员重建发生的情况。明确的撤销访问权限和遏制事件的程序使这些证据可操作。</span></p>
<p><a target="_blank" href="https://build.nvidia.com/openshell?nvid=nv-int-solr-662458-vt53&_gl=1*18jmge8*_gcl_au*MjEyMzE0NzgxOS4xNzg4MjE0MjE4Li0uLS4xNzg4MjE0Mjc3LjE3NzIyOTMxNy4xNzg5NjcwMDk0LjE3ODk2NzAxMTA."><span style="font-weight: 400;">NVIDIA OpenShell</span></a><span style="font-weight: 400;">是一个开源、安全的运行时,它在代理无法触及的范围内执行策略,并提供沙箱执行,同时管理代理如何访问数据、网络和系统资源。</span><a target="_blank" href="https://secureaialliance.org/"><span style="font-weight: 400;">Open Secure AI Alliance</span></a><span style="font-weight: 400;">的合作伙伴正在基于OpenShell构建:</span><a target="_blank" href="https://blogs.cisco.com/ai/cisco-announces-defenseclaw"><span style="font-weight: 400;">Cisco的</span><span style="font-weight: 400;">DefenseClaw</span></a><span style="font-weight: 400;">添加了治理层,</span><span style="font-weight: 400;">而</span><a target="_blank" href="https://investors.jfrog.com/news/news-details/2026/JFrog-Delivers-Trust-Layer-for-AI-Driven-Software-with-NVIDIA/default.aspx"><span style="font-weight: 400;">JFrog</span></a><span style="font-weight: 400;">与OpenShell集成以扫描和验证代理技能,并执行关于代理可以访问哪些技能的策略。</span></p>
<h2><b>工程团队需要安全证据</b></h2>
<p><span style="font-weight: 400;">在部署之前,团队需要证据证明适当的控制措施能够阻止试图获取超出代理范围的凭证或将敏感数据发送到未授权目标的尝试。</span></p>
<p><span style="font-weight: 400;">测试还应涵盖试图更改权限或干扰监控的尝试,并在对模型、工具或工作流进行重大更改后重复进行。</span></p>
<p><span style="font-weight: 400;">指定的责任人必须使用这些结果来决定系统是否准备好部署,并确保测试失败导致纠正措施。在测试或操作中发现的故障应被重现、调查和解决。然后,每个发现都可以成为一个可重复的测试,让团队检查修复在未来的版本中是否继续有效。</span><span style="font-weight: 400;"> </span></p>
<p><span style="font-weight: 400;">示例包括CrowdStrike的</span><a target="_blank" href="https://www.crowdstrike.com/en-us/press-releases/crowdstrike-launches-frontier-models-for-cybersecurity-with-nvidia/"><span style="font-weight: 400;">SafeMind</span></a><span style="font-weight: 400;">,用于通过重复攻击模拟测试和加强防御,以及Palo Alto Networks的</span><a target="_blank" href="https://www.paloaltonetworks.com/blog/2026/06/reinventing-security-for-the-agentic-nvidia-ai-factory/"><span style="font-weight: 400;">Prisma AIRS</span></a><span style="font-weight: 400;">,用于在模型和应用程序变化时进行持续红队测试。</span></p>
<h2><b>防御者需要在正确的时间获得正确的工具</b></h2>
<p><span style="font-weight: 400;">调查故障需要适合任务、数据和环境的强大工具。开放和封闭模型满足互补的需求。</span></p>
<p><span style="font-weight: 400;">封闭模型提供托管功能和服务,而开放模型让防御者可以选择检查相关组件、调整策略并在他们控制的基础设施上工作。</span></p>
<p><span style="font-weight: 400;">在事件期间,这种控制可以帮助团队重现故障并在自己的系统上测试修复,同时将敏感证据保留在其环境中。</span></p>
<p><span style="font-weight: 400;">强大的AI可以通过帮助发现漏洞、验证修复和调查攻击来支持这项工作。其价值应通过可重复的发现、可验证的修复和加速的修复来评估。</span>
查看缓存全文
缓存时间: 2026/09/21 14:55
# AI安全是一个工程问题——如何在代理技术栈的每一层解决它
来源:https://blogs.nvidia.com/blog/ai-security-agent-stack/
AI安全是一个工程问题。这意味着需要明确的安全要求、可执行的控制措施、指定的负责人,以及证明防护措施有效的证据。
随着AI能力日益增强,行业必须加速安全工程发展,扩大防御工具的可及性,并更快地分享有效实践。
## **技术在变,安全基础永恒**
互联网和云计算改变了软件的运行方式,但核心安全职责依然如故:建立身份、控制访问、限制暴露范围并验证防护措施是否有效。
AI代理引入了新能力——推理、使用工具,以及根据遇到的数据调整行动。这些能力要求将已确立的安全原则应用于新的运行条件。
这种发展速度带来了压力。组织希望获得AI带来的生产力效益,而治理和保障这些系统的实践仍在发展中。
## **安全取决于完整的代理技术栈**
应用程序依赖代码、数据、身份、服务和基础设施。安全则取决于这些组件如何协同工作——而AI代理扩展了这一系统(https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack/)。
模型提供能力;框架组织上下文、工具和工作流;运行环境提供行动执行的基础设施。技术栈的每一部分都承载着安全责任,适当的保护需要跨每一层的控制,因为数据、指令和行动在系统中流动。
想象一个代理更新客户记录的场景。假设它在附加文档中遇到恶意指令,并试图将客户数据导出到未经授权的目的地。
网络策略应阻止数据传输,受保护的日志应记录工具调用尝试、授权决策和结果,以便安全团队能识别所用工具及其试图到达的目标。
更新客户记录的权限不应自动延伸至导出数据。代理可以请求额外的访问权限,但不能自行授权。
## **将安全内建于代理的运行方式中**
即使代理做出错误决策,安全边界也必须有效。代理运行的环境决定了它被允许做什么,因此必须独立于代理的推理,对文件、网络目的地和进程设置限制。
指令和保障措施可以帮助引导行为,但安全还需要可执行的边界。
每个代理都需要一个可追溯的身份和仅限于其分配任务的凭证。组织需要明确的策略,定义代理可以访问哪些信息、可以更改哪些系统,以及哪些操作需要批准。在这些边界内,重大行动和权限变更仍需人工批准。
团队还需要验证代理使用的工具、技能和依赖项的来源和完整性。如果出现问题,受保护的工具调用、授权决策和结果记录有助于调查人员重构事件。明确的访问撤销和事件遏制流程使这些证据具有可操作性。
NVIDIA OpenShell(https://build.nvidia.com/openshell?nvid=nv-int-solr-662458-vt53&_gl=1*18jmge8*_gcl_au*MjEyMzE0NzgxOS4xNzg4MjE0MjE4Li0uLS4xNzg4MjE0Mjc3LjE3NzIyOTMxNy4xNzg5NjcwMDk0LjE3ODk2NzAxMTA.)是一个开源、安全的运行时环境,它在代理无法触及的层面执行策略,并提供沙盒化执行环境,同时管理代理如何访问数据、网络和系统资源。开放安全AI联盟(https://secureaialliance.org/)的合作伙伴正基于OpenShell进行构建:思科的DefenseClaw(https://blogs.cisco.com/ai/cisco-announces-defenseclaw)增加了一层治理,而JFrog(https://investors.jfrog.com/news/news-details/2026/JFrog-Delivers-Trust-Layer-for-AI-Driven-Software-with-NVIDIA/default.aspx)与OpenShell集成,以扫描和验证代理技能,并对代理可访问的技能实施策略控制。
## **工程团队需要安全证据**
在部署之前,团队需要证据,证明适当的控制措施能够阻止代理试图获取超出其范围的凭证或向未经授权的目的地发送敏感数据的尝试。
测试还应涵盖更改权限或干扰监控的尝试,并在模型、工具或工作流发生重大变更后重复进行。
指定的负责人必须利用这些结果来决定系统是否准备好部署,并确保失败测试能导向纠正措施。在测试或运行中发现的故障应被重现、调查和解决。每个发现随后都可成为可重复的测试,使团队能够检查修复是否在未来的版本中继续有效。
示例包括CrowdStrike的SafeMind(https://www.crowdstrike.com/en-us/press-releases/crowdstrike-launches-frontier-models-for-cybersecurity-with-nvidia/),通过重复攻击模拟来测试和加强防御;以及Palo Alto Networks的Prisma AIRS(https://www.paloaltonetworks.com/blog/2026/06/reinventing-security-for-the-agentic-nvidia-ai-factory/),在模型和应用变更时进行持续红队测试。
## **防御者需要在正确的时间获得正确的工具**
调查故障需要与任务、数据和环境相匹配的强大工具。开源和闭源模型服务于互补的需求。
闭源模型提供托管的能力和服务,而开源模型为防御者提供了检查相关组件、调整策略以及在自己控制的基础设施上工作的选择。
在事件发生时,这种控制可以帮助团队重现故障并在自己的系统上测试修复,同时将敏感证据保留在其环境中。
强大的AI可以通过帮助发现漏洞、验证修复和调查攻击来支持这项工作。其价值应通过可重现的发现、可验证的修复和加速的响应时间来评估。
示例包括Capital One的VulnHunter(https://www.capitalone.com/tech/open-source/announcing-vulnhunter/)用于AI驱动的代码安全,以及ReversingLabs的Spectra Assure(https://www.reversinglabs.com/solutions/secure-software-release)用于AI驱动的软件包分析以检测恶意软件和篡改。
## **通过开放工作将优势转向防御者**
分享关于什么失败了、哪些控制有效以及修复如何被验证的证据,有助于其他团队加强他们自己的系统。
NVIDIA的安全研究(https://research.nvidia.com/ai-security)和开放安全AI联盟通过将研究、实用工具和专业知识带入更广泛的安全社区,支持这种交流。
AI安全是一个工程问题。每一次代理部署都需要可执行的边界、负有责任的负责人,以及证明其防护措施有效的证据。开放的研究和共享工具帮助更多防御者达到这一标准,并随着能力的提升而不断完善它。
*了解更多关于**NVIDIA的安全研究*(https://research.nvidia.com/ai-security)*并加入**开放安全AI联盟*(https://secureaialliance.org/#join)*。
相似文章
如何借助 NVIDIA OpenShell 实现自主 AI 智能体的“内置安全”设计
NVIDIA 推出 OpenShell,这是一款专为自主 AI 智能体打造的“内置安全”运行时环境。它通过将智能体操作隔离在沙箱中,并在系统级别执行安全策略,而非依赖行为提示词来保障安全。作为 NVIDIA Agent Toolkit 的一部分,该工具包使企业能够在统一的策略管理和合规监管下,运行代码编写智能体和智能体工作流。
实用的 AI 智能体安全工作流是怎样的?
本文探讨了在整合了自研系统、商业软件及云服务的环境中,针对 AI 智能体设计的实用安全工作流。
企业使用代理安全工具,你们的代理真的可用吗?
本文探讨了为AI代理创建策略层的挑战,即在安全性和可用性之间取得平衡,其中人工在环审批可能会减缓决策,但更严格的防护措施可能会妨碍可用性。
我认为大多数AI代理的安全性远低于其开发者的预期
文章认为,AI代理安全常被过度强调,尤其是对提示注入的关注,而忽视了更广泛的风险,如未授权工具使用、数据访问和金融交易。它呼吁更多地关注代理在生产环境中实际可能被操控执行的任务。
通往AGI之路中的安全保护
OpenAI 概述了在通往 AGI 过程中的全面安全措施,包括由 AI 驱动的网络防御、与 SpecterOps 的持续对抗性红队测试,以及为 Operator 等新兴 AI 代理设计的安全框架。该公司强调主动威胁检测、业界合作,以及安全措施与基础设施和模型的深度集成。