据 NVIDIA AI Blog 发表的文章，AI 安全应当被视为一项工程问题来对待，这意味着需要定义明确的安全需求、可执行的控制措施、指定的责任人，以及证明防护机制确实有效的证据。互联网和云计算曾改变软件的运行方式，但建立身份、控制访问、限制暴露面和验证防护效果等核心安全责任并未改变。当 AI Agent 引入推理、使用工具和根据数据调整行为的能力时，这些既有原则需要被应用到新的运行条件中。
Agent 全栈的安全责任
应用程序依赖代码、数据、身份、服务和基础设施，而 AI Agent 扩展了这一系统。在这个技术栈中，模型提供能力，harness 负责组织上下文、工具和工作流，运行时环境则提供执行动作的基础设施。每一层都承担相应的安全责任，数据、指令和动作在系统中流转时需要跨层控制。
文章举例说明，当一个 Agent 更新客户记录时，如果在附件文档中遇到恶意指令并试图将客户数据导出到未授权目的地，网络策略应当阻断该传输。受保护的日志需要记录此次工具调用尝试、授权决策及结果，以便安全团队识别所使用的工具和目标地址。更新客户记录的权限不应自动延伸至导出数据；Agent 可以请求额外访问权限，但不能自行批准。
独立于 Agent 推理的执行边界
安全边界即使在 Agent 做出错误决策时也必须保持有效。Agent 的运行环境决定了它被允许执行的操作，因此必须独立于 Agent 的推理过程，对文件、网络目标和进程设置限制。每个 Agent 需要可追溯的身份，其凭证应限定在分配任务范围内。组织需要制定明确策略，规定 Agent 可访问的信息、可更改的系统以及需要审批的动作。在这些边界内，关键操作和权限变更仍需人工批准。
NVIDIA 推出的开源项目 OpenShell 是一个安全运行时，能够在 Agent 无法触及的层面强制执行策略，提供沙盒化执行环境，并管控 Agent 对数据、网络和系统资源的访问。Open Secure AI Alliance 的合作伙伴正在基于 OpenShell 进行开发：Cisco 的 DefenseClaw 增加了治理层，JFrog 则通过集成 OpenShell 来扫描和验证 Agent 技能，并对 Agent 可访问的技能执行策略。
部署前的控制验证
在部署之前，团队需要证据证明适当的控制措施能够阻止 Agent 获取超出其范围的凭证或将敏感数据发送至未授权目的地。测试还应覆盖试图更改权限或干扰监控的行为，并在模型、工具或工作流发生重大变更后重复进行。指定责任人需利用测试结果判断系统是否具备部署条件，并确保失败的测试能推动纠正措施。
在测试或运行中发现的故障应被复现、调查和解决，每项发现随后可转化为可重复执行的测试用例。CrowdStrike 的 SafeMind 通过反复的攻击模拟来测试和强化防御，Palo Alto Networks Prisma AIRS 则在模型和应用变化过程中提供持续的红队测试。
开放与闭源模型的互补作用
调查故障需要适配特定任务、数据和环境的工具。文章认为，开放模型和闭源模型满足互补的需求：闭源模型提供托管能力和服务，开放模型则让防御者能够检查相关组件、调整策略，并在自身控制的基础设施上开展工作。在事件响应期间，这种控制力有助于团队在不将敏感证据移出环境的前提下复现故障并测试修复方案。
具备能力的 AI 也可以支持防御工作，协助发现漏洞、验证修复和调查攻击，其价值应通过可复现的发现、可验证的修复和加速的响应时间来评估。例如 Capital One 的 VulnHunter 用于 AI 驱动的代码安全，ReversingLabs 的 Spectra Assure 用于分析软件包以检测恶意软件和篡改。
分享关于哪些环节失败、哪些控制有效以及如何验证修复的证据，能够帮助其他团队强化自身系统。NVIDIA 的安全研究和 Open Secure AI Alliance 旨在将研究成果、实用工具和专业知识引入更广泛的安全社区。