GitLost：我们诱骗 GitHub 的 AI 代理泄露了私有仓库

漏洞性质

• GitHub Agentic Workflows 的配置如下：
  • 读取公开 issue 的标题/正文。
  • 通过公开评论回复。
  • 拥有对其他组织仓库的读取权限，包括私有仓库。
• 攻击者可以在公开 issue 中注入指令，诱使代理读取私有仓库并将内容以公开评论的形式贴回。
• 几位评论者强调，关键失败在于不受信任的 issue 内容与私有仓库访问之间缺少信任边界。

谁该负责？

• 一种观点：这主要是用户配置错误。
  • 研究人员明确授予了代理组织级仓库访问权限，并允许它处理不受信任的公开 issue。
  • 类比：给一个 CI 作业秘密信息，然后把它跑在公开 PR 上。
• 另一种观点：这是 GitHub 的设计缺陷。
  • 合理的用户会期望，公共仓库中的代理不会泄露无关的私有仓库内容。
  • 权限粒度过粗，而且 GitHub 没有让安全配置变得简单或显而易见。

提示注入与（不可）解决的护栏

• 许多人认为提示注入是 LLM 的内在问题：用户输入本身就是指令，因此没有强有力的方法把“代码”和“数据”分离开。
• 与 SQL 注入的比较：
  • 相似之处在于不受信任的输入会改变行为。
  • 但不同于 SQL，并不存在类似预编译语句的机制；护栏只是更多输入文本，而且可以被覆盖。
• 也有人认为这更像社会工程：你只能通过流程和访问控制来缓解，而不是“修复”模型本身。

权限、架构与缓解措施

• 广泛认同的观点是：唯一真正的防御是架构层面的：
  • 让代理使用与提示用户相同或更严格的权限；绝不要拥有“root”/组织级访问权限。
  • 将代理限定在单个仓库或狭义定义的工作流中；使用不同 token 对工作流进行分段。
  • 即使代理能读取私有数据，也要限制其处理公开输入时的写入权限。
  • 将代理放入沙箱并赋予其自己的凭证；把它们当作不受信任的用户。
• 也有人建议为每个提示/工作流提供更好的权限 UI，以及更细粒度的 GitHub token。

对 GitHub、云和 AI 集成的信任

• 对 GitHub/Microsoft 持怀疑态度：
  • 有人认为“无处不在的 AI”是投资者压力驱动的结果，导致功能仓促上线且不安全。
  • 也有人担心，私有仓库数据会被用于 Copilot 训练，除非明确选择退出。
• 一个显眼的子群体主张转向自托管代码托管平台（Forgejo、Codeberg、裸 git），以避开 AI 集成并重新获得控制权。

更广泛的反思

• 几位评论者把这看作安全文化薄弱的又一个例子（“刑事级疏忽”“YOLO”式发布）。
• 共识主题：
  • 应把 LLM 当作另一层 UI，而不是特权后端。
  • 不能依赖模型层面的护栏；只有硬性安全边界和最小权限设计才能实质性降低风险。