AI安全是工程问题——如何在智能体栈的每一层解决它
内容提要
AI安全本质是工程问题，需明确需求、可执行控制、责任人和验证证据。智能体栈各层均需防护，运行时须独立限制文件、网络与进程，赋予可追溯身份和最小权限，关键操作需人工审批。部署前应测试越权、数据外泄等场景，失败须复现修复并转为回归测试。开源工具与共享研究有助于防御者持续加固系统。
延伸解读
智能体栈各层防护缺一不可
文章强调，AI智能体的安全不能只依赖模型本身，而需在模型、编排层和运行时环境等每一层都设置控制。例如，当智能体处理客户记录时，若文档中藏有恶意指令试图外泄数据，网络策略应阻止传输，受保护的日志需记录工具调用、授权决策和结果。权限更新客户记录不应自动扩展到导出数据，智能体可请求额外访问但不能自行授权。这要求安全边界独立于智能体的推理，通过文件、网络和进程限制来强制执行。
运行时独立限制与可追溯身份
文章指出，智能体运行的环境必须独立于其推理过程，对文件、网络目的地和进程施加限制。每个智能体需要可追溯的身份和仅限其任务的凭证，组织应明确策略定义智能体可访问的信息、可更改的系统以及需人工批准的操作。关键操作和权限变更仍需人工审批。此外，需验证智能体所用工具、技能和依赖的来源与完整性。一旦出现问题，受保护的工具调用、授权决策和结果记录能帮助调查人员重建事件，并支持撤销访问和遏制事件。
部署前测试与失败转化为回归测试
文章认为，部署前团队需获得证据，证明控制措施能阻止智能体获取超出范围的凭证或向未授权目的地发送敏感数据。测试还应覆盖更改权限或干扰监控的尝试，并在模型、工具或工作流发生重大变化后重复进行。指定负责人需根据结果决定系统是否就绪，并确保失败测试得到纠正。测试或运行中发现的失败应被复现、调查和解决，每个发现可转化为可重复的测试，以验证修复在后续版本中持续有效。
开源工具与共享研究加速防御
文章提到，调查失败需要适合任务、数据和环境的工具。开源和闭源模型满足互补需求：闭源模型提供托管能力，开源模型让防御者能检查组件、调整策略并在可控基础设施上工作。事件响应时，这种控制有助于在自有系统上复现失败并测试修复，同时将敏感证据保留在内部。NVIDIA OpenShell等开源安全运行时在智能体触及范围之外执行策略，Open Secure AI Alliance伙伴在此基础上构建治理和扫描层。共享失败证据、有效控制和验证方法能帮助更多团队加固系统。
Q&A
为什么说AI安全本质上是工程问题？
因为AI安全需要明确的安全需求、可执行的控制措施、指定的责任人和验证防护有效的证据，这些都属于工程实践范畴。
AI智能体栈包含哪些层次？各层有什么安全责任？
智能体栈包括模型（提供能力）、执行框架（组织上下文、工具和工作流）和运行时环境（提供执行基础设施）。每一层都承担安全责任，需要在各层部署控制措施，因为数据、指令和动作会流经整个系统。
如何防止AI智能体越权导出敏感数据？
需要网络策略阻止未授权传输，受保护的日志记录工具调用、授权决策和结果，并且权限不能自动扩展——更新客户记录的权限不应自动包含导出数据的权限。智能体可以请求额外访问权限，但不能自行授权。
AI智能体运行时环境需要哪些独立于智能体推理的限制？
运行时环境必须独立于智能体的推理，对文件、网络目的地和进程施加限制。每个智能体需要可追溯的身份和仅限于其分配任务的凭证。组织需要明确策略定义智能体可访问的信息、可更改的系统以及需要审批的操作。
部署AI智能体前需要验证哪些安全场景？
需要验证控制措施能阻止获取超出范围的凭证、阻止向未授权目的地发送敏感数据、阻止更改权限或干扰监控的尝试。在模型、工具或工作流发生重大变更后应重复测试。必须有指定负责人根据结果决定是否部署，并确保失败测试得到纠正。
开源工具和共享研究对AI安全防御有什么帮助？
开源工具和共享研究帮助防御者持续加固系统。分享失败原因、哪些控制有效以及如何验证修复，能帮助其他团队强化自身系统。NVIDIA的开源安全运行时OpenShell和Open Secure AI Alliance等举措促进了研究、实用工具和专业知识的交流。
