AI安全是工程问题：如何在智能体栈的每一层构建防御

事件概述

随着AI智能体具备推理、工具使用和自适应能力，传统的安全边界面临挑战。文章强调，AI安全并非单纯的技术特性，而是一个需要定义需求、强制执行控制、指定负责人并提供有效性证据的工程问题。尽管技术迭代迅速，但确立身份、控制访问、限制暴露范围及验证防护效果等核心安全原则依然适用。

核心信息

1. 全栈安全架构

AI应用依赖于代码、数据、身份、服务和基础设施的协同工作，安全保护必须覆盖整个智能体栈：

• 模型层：提供基础能力。
• Harness层：组织上下文、工具和流程。
• 运行时环境：提供执行基础设施。

案例说明：当智能体尝试更新客户记录时，若遇到恶意指令试图将数据导出至未授权目的地，网络策略应直接阻断传输，受保护的日志需记录工具调用、授权决策及结果，以便安全团队追溯。智能体无权自我授权扩展权限，关键操作仍需人工审批。

2. 强制性的安全边界

无论智能体做出何种决策，运行环境必须独立于其推理逻辑，对文件、网络目标和进程施加硬性限制：

• 身份与凭证：每个智能体需具备可追踪的身份，且凭证仅限于分配的任务。
• 策略定义：明确智能体可访问的信息、可更改的系统及需审批的动作。
• 溯源与响应：保留受保护的工具调用记录，确保在发生错误时可重建事件现场，并有明确的权限撤销和事件遏制程序。

3. 开源运行时与生态合作

NVIDIA OpenShell 是一个开源的安全运行时环境，它在智能体无法触及的范围外强制执行策略，提供沙箱执行机制，并管控智能体对数据、网络和系统资源的访问。

Open Secure AI Alliance 合作伙伴正在基于此构建更广泛的防御体系：

• Cisco DefenseClaw：增加了治理层。
• JFrog：集成以扫描和验证智能体技能，并强制执行访问策略。

4. 部署前的证据与持续测试

在部署前，团队必须提供证据证明控制措施能有效阻止越权获取凭证或敏感数据泄露。测试需涵盖权限变更尝试及对监控系统的干扰，并在模型、工具或流程发生重大变更后重复进行。

• 责任归属：由指定负责人根据测试结果决定系统是否就绪，并确保失败测试引发纠正行动。
• 闭环改进：发现的所有故障应被复现、调查并解决，转化为可重复的测试用例，确保持续修复。

相关工具示例：

• CrowdStrike SafeMind：通过反复的攻击模拟来测试和加强防御。
• Palo Alto Networks Prisma AIRS：针对不断变化的模型和应用进行持续红队演练。

5. 防御者的工具与优势转移

调查失败案例需要适配任务、数据和环境的专用工具。开放模型与封闭模型互补：封闭模型提供托管服务，而开放模型允许防御者检查组件、调整策略并利用自有基础设施进行测试，从而在事件中更好地复现故障并验证修复方案，同时确保敏感证据留在本地环境中。

相关工具示例：

• Capital One VulnHunter：利用AI进行代码安全分析。
• ReversingLabs Spectra Assure：利用AI分析软件包以检测恶意软件和篡改行为。

值得关注

AI安全的提升依赖于开放研究、实用工具的共享以及专家知识的交流。通过分享失败案例、有效控制和已验证的修复方法，行业整体防御能力得以增强。每一处智能体的部署都需要可执行的边界、问责制的主人以及证明防护有效的证据。