[Paper] 分析在软件开发中基于LLM的多代理系统的代码注入攻击
发布: (2025年12月26日 GMT+8 09:08)
8 min read
原文: arXiv
Source: arXiv - 2512.21818v1
概述
本文研究了由大型语言模型(LLM)驱动的多代理系统——其中自主的“编码器”“审阅者”和“测试者”机器人协同编写软件——如何受到代码注入攻击的威胁。通过构建具体的威胁模型并进行系统实验,作者表明,虽然这些代理能够生成高质量代码,但它们的自主性也使其对恶意输入视而不见,为计划采用 AI 驱动开发流水线的开发者和企业暴露出新的攻击面。
关键贡献
- 架构蓝图 – 提出三种基于 LLM 的多代理设计,用于软件工程的实现阶段:
- Coder‑only
- Coder‑Tester
- Coder‑Reviewer‑Tester(“三元组”架构)。
- 面向代理开发的威胁模型 – 正式化对手如何向代理的通信流注入恶意代码片段或“有毒”的 few‑shot 示例。
- 实证漏洞研究 – 证明所有三种架构均易受代码注入攻击,成功率从 0 %(基线)到 >70 %,取决于攻击者使用的精心构造的 few‑shot 提示。
- 安全分析代理 – 引入专用的“安全分析员”机器人,在代码到达审阅者或测试者之前检查生成的代码,提高韧性且不牺牲吞吐量。
- 定量权衡分析 – 测量每种架构对代码生成速度、正确性和攻击抵抗性的影响,揭示三元组 + 安全分析员是最稳健且仍然高效的配置。
方法论
- 系统原型 – 使用 OpenAI 的 GPT‑4(或可比的 LLM)作为底层代码生成器、审阅者、测试者和安全分析师,实现了三个代理管道。
- 攻击场景 – 构造了两类攻击:
- 直接注入:在问题描述中嵌入恶意代码。
- 少样本投毒:在示例(few‑shot)提示中放置恶意示例,LLM 在上下文学习时使用这些示例。
- 指标 – 对每个管道进行评估:
- 正确性:生成的单元测试通过率。
- 效率:每个特性的时间和 token 使用量。
- 韧性:导致恶意代码成功执行的攻击比例。
- 统计验证 – 在多样的编程任务(Python、JavaScript、Go)上运行每个实验 200 + 次,并使用卡方检验确认观察到的差异具有显著性。
结果与发现
| 架构 | 平均正确率 (✓) | 平均运行时间 (秒) | 攻击成功率 |
|---|---|---|---|
| 仅编码器 | 84 % | 12 | 48 %(直接) / 0 %(few‑shot) |
| 编码器‑测试器 | 78 % | 18 | 55 % / 0 % |
| 编码器‑审阅者‑测试器 | 81 % | 22 | 31 % / 0 % |
| 三元组 + 安全分析员 | 79 % | 24 | 5 %(直接) / 71.95 %(few‑shot 投毒) |
关键要点
- 添加审阅者可以降低天真注入攻击的原始成功率,但会减慢流水线速度。
- 安全分析代理显著降低直接注入成功率(降至 5 %),同时保持整体正确率相当。
- 然而,当攻击者嵌入恶意的 few‑shot 示例时,安全分析员本身可能被欺骗,成功率会升至约 72 %。
- 速度与安全之间的权衡显而易见:检查越多安全性越好,但延迟也会增加。
实际影响
- 工具供应商 – 构建 AI 辅助 IDE 插件或 CI/CD 机器人的公司应在代码合并之前嵌入专门的安全分析阶段(例如,静态分析 + 基于 LLM 的威胁检测)。
- DevOps 流水线 – 依赖 “一次编写、随处运行” LLM 代理的自动化流水线必须为任何来源于 LLM 提示的代码保留人工在环检查点,尤其是在提供少量示例时。
- 政策制定者 – 针对 AI 生成代码的安全指南应明确涉及提示层面的清理,并禁止使用不可信的少量示例数据。
- 开发者 – 使用 LLM 副驾驶时,应将提示示例中出现的任何代码视为不可信输入;在部署前运行代码检查工具、依赖扫描器以及沙箱执行。
- 未来产品 – 该论文的架构可以重新用于其他领域(基础设施即代码、数据流水线生成),在这些领域中自主代理生成的产物必须经过审查以防止恶意负载。
限制与未来工作
- Model Scope – 实验仅限于单一 LLM 系列(GPT‑4);使用拥有不同 token‑budget 或指令遵循行为的开源模型时,结果可能会有所不同。
- Attack Diversity – 只探索了两种攻击向量;更复杂的供应链或侧信道攻击仍未测试。
- Human Factors – 研究假设流水线完全自动化;实际部署中常保留一定的人工审查,这可能会改变威胁格局。
- Scalability – 增加安全分析员会提升延迟;未来工作应研究轻量级、设备端检测器或并行化验证,以保持流水线的高速运行。
- Robust Prompt Engineering – 开发系统化防御(例如提示清理器、对抗性训练)以抵御少样本投毒仍是一个开放的研究方向。
底线:随着 LLM 驱动的多代理系统从研究实验室走向生产软件工厂,安全已不能再是事后考虑。本文提供了首个具体证据,表明代码注入攻击能够瘫痪自主编码流水线——并通过专门的安全分析代理提供了一条实用但尚不完美的缓解路径。开发者和平台构建者应开始像对待人工编写代码一样,对 AI 生成的代码进行同等严格的审查,尤其是当提示中包含外部示例时。
作者
- Brian Bowers
- Smita Khapre
- Jugal Kalita
论文信息
- arXiv ID: 2512.21818v1
- 分类: cs.SE, cs.MA
- 出版时间: 2025年12月26日
- PDF: 下载 PDF