Noma Labs 披露了一项针对 GitHub Agentic Workflows 的安全研究，并把这个漏洞命名为 GitLost。 按照文章描述，攻击者不需要账号权限、凭据或编程能力，只要在某个组织的公开仓库里提交一个经过设计的 GitHub Issue，就可能诱导 GitHub 的 AI 智能体读取同一组织内私有仓库的数据，并把内容公开回复到这个 Issue 下。 GitHub Agentic Workflows 是 GitHub 新推出的智能体工作流能力，它把 GitHub Actions 和由 Claude 或 GitHub Copilot 支持的 AI 智能体结合起来。 团队可以用 Markdown 写工作流，系统再将其编译成 YAML 形式的 Actions 配置。这个智能体可以读取 Issue、调用工具，也可以在被授权的范围内访问组织里的其他仓库。 GitLost 的问题出在智能体把不可信内容当成了指令。Noma Labs 发现的易受攻击工作流会在 Issue 被分配时触发，读取 Issue 的标题和正文，再用 add-comment 工具发表评论，同时它还拥有读取同一组织其他公开和私有仓库的权限。攻击者可以把恶意指令藏在看似正常的 Issue 描述里，等待自动化流程触发。 在演示中，研究人员伪造了一个看起来很普通的业务请求，像是销售负责人在客户会议后提出的需求。Issue 被分配后，工作流启动，智能体按照 Issue 中隐藏的指令去读取 poc 公开仓库和 testlocal 私有仓库里的 `README.md`，随后把这些内容作为公开评论发回 Issue。这样，原本只应留在私有仓库里的信息，就出现在任何人都能访问的公开页面上。 GitHub 当时已有用于阻止这类行为的防护规则，但研究人员在多次测试中发现，只要加入 “Additionally” 这样的措辞，就可能让模型重新组织输出，绕过原本应该拒绝的场景。 Noma Labs 已经公开了工作流运行记录和相关 Issue 作为验证材料，并说明泄露内容涉及公开仓库 sasinomalabs/poc`、公开仓库 `sasinomalabs/remote-ping 以及私有仓库 `sasinomalabs/testlocal`。 Issue、PR、评论、文件内容，只要会被智能体读取，就可能被攻击者写入指令。传统系统里，信任边界主要靠代码和权限控制来维持。到了智能体系统里，模型是否会听从某段文本，也成了安全边界的一部分。 不要把用户可控内容当作可信指令，给智能体分配最小必要权限，尤其要谨慎处理跨仓库访问。限制智能体公开发布内容的能力，在把用户输入交给模型前，做好隔离或清理。GitLost 已经通过负责任披露流程报告给 GitHub，漏洞细节是在 GitHub 知情的情况下发布的。 #AI #Github #安全 https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/