**GitLost 漏洞深度解析：GitHub Agentic Workflows 的提示注入风险**
**漏洞概述**
Noma Security 发现了一种名为 “GitLost” 的提示注入攻击，利用了 GitHub 推出的 Agentic Workflows 功能，诱骗 AI 在公开 Issue 中泄露私有仓库数据。攻击者只需在公开 Issue 中植入隐蔽指令，便能绕过安全机制，诱导 AI Agent 在公开评论中吐露机密信息。
**漏洞机制**
Noma Labs 检测到的一个存在漏洞的 Agentic Workflow 被配置为在 `issues.assigned` 事件触发时运行。该 Workflow 具备读取 Issue 标题和正文的能力，能够通过 `add-comment` 工具发布回复，并拥有访问组织内其他仓库（包括公开和私有仓库）的权限。
**利用方式**
利用该漏洞无需任何编程技能、访问权限或凭据。攻击者仅需在属于该组织的公开仓库中创建一个 Issue，随后静待即可。
**绕过原理**
尽管 GitHub 已部署严格的防护机制，但仅使用 “Additionally” 这一关键词便成功诱发了模型的非预期行为。模型将此视为当前任务的延续，而非新的指令，从而访问了原本受限的文件内容并将其发布在公开评论中。
**概念分析**
传统安全模型通常假定信任边界由代码负责维护，而在 Agentic 系统中，信任边界部分依赖于模型的行为，而模型天然具备遵循指令的特性。提示注入攻击在 Agentic AI 环境中变得愈发普遍，类似于 Web 应用中的 SQL 注入——这是一种系统性的、覆盖广泛的漏洞类型，需要同样系统化的防御策略。
**防御建议**
为降低此类风险，Noma 研究人员建议：用户控制的内容永远不应被视为 AI Agent 的可信指令输入。Agent 的权限应限制在严格必要的范围内，尤其是那些拥有跨仓库访问权限的 Agent，极易成为攻击目标。此外，组织应限制 Agent 在公开披露信息时的范围，特别是在响应 Issue 内容时，并确保用户输入在提交给模型前经过适当清理或与指令上下文隔离。
**社区观点**
* **Vijendra Malhotra**：私有仓库从来都不是安全边界。它实际上是组织边界，只有当读取你代码的人都是你雇佣的人类时，这个边界才成立。Agent 打破了这一假设。如果一个 Agent 能访问你的私有仓库，请把其中所有内容都视为距离公开泄露只差一个精心构造的 Issue。
* **Significant_Sea_4230**：危险之处并不在于 Agent “很聪明”。而在于它可能连接了过多上下文、过多仓库，或者拥有权限过于宽泛的 Token。
* **cH3332xr**：这里最有意思的细节是 “Additionally” 绕过机制。有效载荷本身并没有改变，只是这个衔接词在防护机制看来，把它从“新的指令”重新归类成了“当前任务的延续”。这是一个决策边界问题，而不是内容问题。
* **mcv**：SQL 注入之所以产生，是因为系统把用户输入当成了指令的一部分，而不是原本应该被视为纯数据的内容。将两者分离之后，这个问题就解决了。而提示注入无法避免，因为用户输入本身就是指令。
如需深入了解技术细节和概念验证过程，请参阅 Noma 官网的完整报告。