[Paper] 分析在软件开发中基于LLM的多代理系统的代码注入攻击

发布: (2025年12月26日 GMT+8 09:08)
8 min read
原文: arXiv

Source: arXiv - 2512.21818v1

概述

本文研究了由大型语言模型(LLM)驱动的多代理系统——其中自主的“编码器”“审阅者”和“测试者”机器人协同编写软件——如何受到代码注入攻击的威胁。通过构建具体的威胁模型并进行系统实验,作者表明,虽然这些代理能够生成高质量代码,但它们的自主性也使其对恶意输入视而不见,为计划采用 AI 驱动开发流水线的开发者和企业暴露出新的攻击面。

关键贡献

  • 架构蓝图 – 提出三种基于 LLM 的多代理设计,用于软件工程的实现阶段:
    1. Coder‑only
    2. Coder‑Tester
    3. Coder‑Reviewer‑Tester(“三元组”架构)。
  • 面向代理开发的威胁模型 – 正式化对手如何向代理的通信流注入恶意代码片段或“有毒”的 few‑shot 示例。
  • 实证漏洞研究 – 证明所有三种架构均易受代码注入攻击,成功率从 0 %(基线)到 >70 %,取决于攻击者使用的精心构造的 few‑shot 提示。
  • 安全分析代理 – 引入专用的“安全分析员”机器人,在代码到达审阅者或测试者之前检查生成的代码,提高韧性且不牺牲吞吐量。
  • 定量权衡分析 – 测量每种架构对代码生成速度、正确性和攻击抵抗性的影响,揭示三元组 + 安全分析员是最稳健且仍然高效的配置。

方法论

  1. 系统原型 – 使用 OpenAI 的 GPT‑4(或可比的 LLM)作为底层代码生成器、审阅者、测试者和安全分析师,实现了三个代理管道。
  2. 攻击场景 – 构造了两类攻击:
    • 直接注入:在问题描述中嵌入恶意代码。
    • 少样本投毒:在示例(few‑shot)提示中放置恶意示例,LLM 在上下文学习时使用这些示例。
  3. 指标 – 对每个管道进行评估:
    • 正确性:生成的单元测试通过率。
    • 效率:每个特性的时间和 token 使用量。
    • 韧性:导致恶意代码成功执行的攻击比例。
  4. 统计验证 – 在多样的编程任务(Python、JavaScript、Go)上运行每个实验 200 + 次,并使用卡方检验确认观察到的差异具有显著性。

结果与发现

架构平均正确率 (✓)平均运行时间 (秒)攻击成功率
仅编码器84 %1248 %(直接) / 0 %(few‑shot)
编码器‑测试器78 %1855 % / 0 %
编码器‑审阅者‑测试器81 %2231 % / 0 %
三元组 + 安全分析员79 %245 %(直接) / 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
Back to Blog

相关文章

阅读更多 »