GitHub提示注入攻击：一条评论即可劫持AI代理并窃取密钥

研究人员最近披露了一种被称为“Comment and Control”（评论与控制）的新型提示注入攻击方法。这种方法能够利用GitHub生态中的普通文本内容——例如Pull Request的标题、Issue的描述或者简单的评论——来劫持AI代理的预期行为。

其核心攻击原理在于，当这些AI代理执行代码审查、生成或安全分析等任务时，它们会自动读取仓库中的上下文信息，并将这些信息作为“输入提示”的一部分来处理。然而，当前系统普遍存在一个设计缺陷：它们未能清晰地区分“数据”与“指令”之间的边界。这使得攻击者能够在看似无害的文本中嵌入恶意指令，从而诱导AI执行非预期的危险操作。

从攻击路径来分析，该技术充分利用了AI代理与自动化流程（例如GitHub Actions）深度集成的特性。一旦开发者在代码仓库中启用了这类AI工具，代理通常就具备了访问仓库内容、调用外部工具甚至执行命令的较高权限。攻击者只需提交一个包含恶意提示的评论或PR，就能触发AI代理解析并执行其中隐藏的指令，例如导出敏感文件、读取环境变量或调用外部API。这种攻击完全绕过了传统的漏洞利用，也不依赖上传恶意文件，仅仅通过文本就能构建完整的控制链，本质上属于一种“语义层攻击”。

在实际的测试案例中，研究人员利用该方法成功窃取了多种敏感信息，包括API密钥、访问令牌以及仓库内的机密数据。例如，攻击可以诱导AI代理输出类似 ANTHROPIC_API_KEY、GEMINI_API_KEY 或 GITHUB_TOKEN 这类关键凭证，并通过GitHub平台自身的功能（如评论回复）将结果回传给攻击者，形成了一条完整且隐蔽的数据外泄链路。更关键的是，这种攻击完全依赖平台内部机制，无需架设额外的命令控制服务器（C2），攻击者仅需通过GitHub评论就能完成“指挥—执行—回传”的全过程。

该漏洞的根源在于当前AI代理架构的设计缺陷。一方面，系统将外部输入（如用户评论）直接拼接进提示词中，缺乏有效的输入清洗与上下文隔离机制；另一方面，AI代理通常被授予了过高的权限，可以调用命令行工具、访问文件系统乃至连接外部服务。这种“高权限”与“不可信输入”的危险组合，使得AI代理从一个辅助工具转变为了潜在的高风险攻击入口。

从影响范围来看，这个问题并不仅限于某几款特定的工具。研究人员指出，任何与GitHub或类似开发平台集成、并具备自动执行能力的AI代理——例如Slack机器人、CI/CD自动化工具、Jira集成代理等——都可能受到类似攻击手法的影响。这意味着该问题具有“架构级普遍性”，而非单一的、孤立的产品漏洞。目前，相关厂商（如Anthropic、Google、Microsoft）已确认问题的存在，并向研究人员发放了漏洞奖励，但尚未完全披露统一的修复方案。

从安全演进的角度看，这一事件标志着网络攻击正在迈入“AI代理时代”。传统的攻击往往依赖代码漏洞或系统配置缺陷，而此类新型攻击则利用了AI对自然语言的“信任”，巧妙地将“文本输入”转化为“执行指令”，彻底打破了长期以来“评论≠可执行代码”的安全假设。同时，这种攻击具备极高的隐蔽性，恶意内容可以完美地隐藏在普通的开发讨论中，人类开发者难以察觉，但AI代理却会忠实地严格执行。

总体而言，该事件揭示了一个关键趋势：随着AI开发工具从“辅助生成”向“自动执行代理”演进，其暴露的攻击面也在迅速扩大。提示注入已不再只是学术界讨论的理论问题，而是能够直接影响软件供应链和核心开发流程的现实威胁。未来的安全防护思路需要从简单的“过滤输入”升级为“重构信任模型”，包括严格限制AI代理的操作权限、构建安全的执行环境沙箱，以及对外部输入进行严格的指令验证。否则，日益强大的AI代理很可能成为攻击者眼中新的、极具价值的高权限入口。

对于关注此类前沿安全威胁的开发者，可以在云栈社区的安全板块找到更多相关的深度讨论和技术分析。