AI代理已经到来，威胁也随之而来
执行摘要
代理应用程序是利用AI代理——为自主收集数据和采取行动以实现特定目标而设计的软件——来驱动其功能的程序。随着AI代理在实际应用中得到越来越广泛的采用，理解其安全影响至关重要。本文研究了攻击者可以针对代理应用程序的方法，提出了九个具体的攻击场景，这些攻击会导致信息泄露、凭证盗窃、工具利用和远程代码执行等后果。
为了评估这些风险的适用范围，我们使用不同的开源代理框架——CrewAI和AutoGen——实现了两个功能相同的应用程序，并在两者上执行了相同的攻击。我们的研究结果表明，大多数漏洞和攻击向量基本上与框架无关，它们源于不安全的设计模式、错误配置和不安全的工具集成，而不是框架本身的缺陷。
我们还为每个攻击场景提出了防御策略，分析了它们的有效性和局限性。为了支持可重现性和进一步研究，我们已在 GitHub 上开源了源代码和数据集。
主要发现
- 并非总是需要进行提示注入才能破坏AI代理。范围不当或不安全的提示可以在没有明确注入的情况下被利用。
- 缓解措施：在代理指令中强制实施保障措施，明确阻止超出范围的请求和指令或工具模式的提取。
- 提示注入仍然是最强大和多功能的攻击向量之一，能够泄露数据、滥用工具或颠覆代理行为。
- 缓解措施：部署内容过滤器，在运行时检测和阻止提示注入尝试。
- 错误配置或易受攻击的工具显著增加了攻击面和影响。
- 缓解措施：清理所有工具输入，应用严格的访问控制，并执行常规安全测试，如SAST、DAST或SCA。
- 不安全的代码解释器使代理面临任意代码执行和对主机资源及网络的未经授权访问。
- 缓解措施：实施具有网络限制、系统调用过滤和最小权限容器配置的强沙箱。
- 凭证泄露，如暴露的服务令牌或机密，可能导致冒充、权限升级或基础设施泄露。
- 缓解措施：使用数据丢失防护(DLP)解决方案、审计日志和机密管理服务来保护敏感信息。
- 没有任何单一的缓解措施是足够的。需要分层的、深度防御策略来有效降低代理应用程序中的风险。
- 缓解措施：在代理、工具、提示和运行时环境中结合多种保障措施，构建弹性防御。
需要强调的是，CrewAI和AutoGen本身都不是易受攻击的。本研究中的攻击场景突显了系统性风险，这些风险根植于语言模型在抵抗提示注入方面的局限性以及集成工具的错误配置或漏洞中——而不是任何特定的框架。
AI代理概述
AI代理是一种软件程序，旨在自主地从其环境收集数据、处理信息并采取行动以实现特定目标，无需直接的人工干预。这些代理通常由AI模型驱动——最值得注意的是大语言模型(LLM)——作为其核心推理引擎。
AI代理的一个决定性特征是它们能够将AI模型连接到外部功能或工具，使其能够自主决定在追求目标时使用哪些工具。功能或工具是一种外部能力——如API、数据库或服务——代理可以调用它来执行超出模型内置知识的特定任务。
典型AI代理架构
一个典型的AI代理架构包括：
- 规划与推理：使用LLM进行任务规划和决策
- 执行循环：自主执行任务的循环机制
- 函数调用：连接外部工具和服务
- 内存系统：短期和长期内存管理
- 输入输出接口：通常以API形式暴露
AI代理的安全风险
由于AI代理通常建立在LLM之上，它们继承了 OWASP LLM Top 10 中概述的许多安全风险，如提示注入、敏感数据泄露和供应链漏洞。然而，AI代理通过集成通常用各种编程语言和框架构建的外部工具，超越了传统的LLM应用程序。
包含这些外部工具使LLM面临经典的软件威胁，如SQL注入、远程代码执行和破坏的访问控制。这种扩大的攻击面，加上代理与外部系统甚至物理世界交互的能力，使保护AI代理变得特别关键。
关键威胁类型
根据 OWASP 代理AI威胁和缓解指南，主要威胁包括：
- 提示注入：攻击者向GenAI系统偷偷插入隐藏或误导性指令，试图使应用程序偏离其预期行为
- 工具滥用：攻击者操控代理滥用其集成工具
- 意图破坏和目标操控：通过巧妙改变AI代理的感知目标或推理过程
- 身份欺骗和冒充：利用弱或受损的身份验证冒充合法的AI代理或用户
- 意外的RCE和代码攻击：利用AI代理执行代码的能力
- 代理通信中毒：向通信通道注入攻击者控制的信息
- 资源过载：压垮AI代理的分配资源
研究案例：投资顾问助手
为了研究AI代理的安全风险，我们使用两个流行的开源代理框架（CrewAI和AutoGen）开发了一个多用户、多代理的投资顾问助手。
系统架构
投资顾问助手由三个协作代理组成：
- 编排代理：管理用户交互，解释请求，委派任务，整合输出
- 新闻代理：收集和总结财经新闻
- 搜索引擎工具
- 网页内容阅读器工具
- 股票代理：管理股票投资组合
- 数据库工具
- 股票工具
- 代码解释器工具
九大攻击场景
| 攻击场景 | 描述 | 威胁类型 | 缓解措施 |
|---|---|---|---|
| 识别参与代理 | 揭示代理列表及其角色 | 提示注入、意图破坏 | 提示强化、内容过滤 |
| 提取代理指令 | 提取系统提示和任务定义 | 提示注入、通信中毒 | 提示强化、内容过滤 |
| 提取工具模式 | 检索工具的输入/输出模式 | 提示注入、通信中毒 | 提示强化、内容过滤 |
| 未经授权访问内部网络 | 使用web阅读器获取内部资源 | SSRF、工具滥用 | 工具输入清理、网络隔离 |
| 挂载卷数据泄露 | 读取并泄露挂载卷中的文件 | RCE、数据泄露 | 代码执行器沙箱 |
| 元数据服务令牌泄露 | 访问并泄露云服务账户令牌 | 身份欺骗、RCE | 沙箱、元数据服务限制 |
| SQL注入 | 通过SQL注入提取数据库内容 | 工具滥用、数据泄露 | 输入清理、参数化查询 |
| BOLA攻击 | 通过操作对象引用访问他人数据 | 访问控制破坏 | 严格的授权检查 |
| 间接提示注入 | 通过恶意网页泄露对话历史 | 提示注入、数据泄露 | 内容过滤、输出清理 |
防御策略
1. 提示强化
在代理指令中明确禁止：
- 提取系统提示或工具模式
- 超出范围的请求
- 绕过安全策略的尝试
2. 内容过滤
部署运行时检测机制：
- 检测提示注入模式
- 过滤敏感信息输出
- 监控异常行为
3. 工具安全
- 输入验证和清理
- 最小权限原则
- 网络隔离和访问控制
- 定期安全扫描（SAST/DAST/SCA）
4. 代码执行沙箱
- 网络限制
- 系统调用过滤
- 最小权限容器配置
- 资源限制
5. 数据保护
- DLP解决方案
- 审计日志
- 机密管理服务
- 敏感数据脱敏
6. 深度防御
结合多层保障措施：
- 代理层：提示强化
- 工具层：输入验证
- 运行时层：沙箱隔离
- 监控层：异常检测
结论
AI代理应用带来了强大的自动化能力，但也引入了新的安全挑战。本研究表明：
- 框架无关性：大多数漏洞源于设计模式和配置，而非特定框架
- 多层防御必要性：单一缓解措施不足以应对复杂威胁
- 持续监控重要性：需要建立完善的可观测性和审计机制
开发者在构建AI代理应用时，必须从设计阶段就考虑安全性，采用深度防御策略，并持续监控和改进安全措施。
研究团队：
- Jay Chen - Palo Alto Networks Unit 42
- Royce Lu - Palo Alto Networks Unit 42
开源代码：https://github.com/PaloAltoNetworks/stock_advisory_assistant