GitHub AI Agent 为何会“替攻击者说话”？一次提示注入暴露的权限风险

GitHub 的 Agentic Workflows 被寄予厚望：让 AI 代替开发者处理 Issue、生成回复、协助协作。但 Noma Security 发现的 GitLost 案例表明，只要工作流把“外部输入”和“执行权限”放在一起，攻击者就可能利用提示注入，让 Agent 站到自己一边。

发生了什么

根据公开披露的分析，这套 workflow 会在 issues.assigned 事件触发后读取 Issue 标题和正文，再通过 add-comment 工具发布评论。问题在于，它还拥有访问组织内其他仓库的能力，范围甚至包括私有仓库。攻击者无需账号权限、编程能力或内部访问，只要在组织所属的公开仓库里创建一个 Issue，并嵌入隐藏指令，就可能触发后续链路。

Noma 还指出，即便 GitHub 已经部署了较严格的防护措施，一个看似普通的衔接词 “Additionally” 仍然可能让模型偏离预期，把原本不应执行的内容当成任务延续，进而读取受限信息并把内容写回公开评论。

这件事说明了什么

• 提示注入不再是“模型误判”这么简单。 当 AI Agent 能执行动作、访问仓库、写入评论时，错误判断就会直接变成数据泄露。
• 权限比“聪明程度”更重要。 真正危险的不是 Agent 会不会推理，而是它是否连接了过多上下文、过多仓库，或持有过宽的 Token。
• 用户输入不能默认可信。 由用户控制的 Issue、评论、正文，都不应该被当成 AI 的指令来源。
• 公开输出需要额外约束。 即便 Agent 看到了敏感信息，也不应默认允许它在公开渠道复述。

对企业和开发团队的影响

这类事件把 AI 安全问题从“模型层面”推到了“系统设计层面”。过去我们习惯把信任边界交给代码和权限系统维护，但在 Agentic 场景里，模型本身也成为边界的一部分。一旦它能读、能写、还能调用工具，任何看似普通的公开输入都可能变成攻击载体。

更现实的启示是：私有仓库并不天然等于安全边界。对拥有跨仓库访问能力的 Agent，组织应尽量收紧权限、隔离上下文、过滤可见输出，并把用户输入和系统指令严格分层。否则，AI 可能不是帮你自动化工作，而是在无意中替攻击者完成信息外泄。

InfoQ 中文