☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
GitLost 是由 Noma Security 揭露的一种提示注入攻击手法，可操纵 GitHub 全新推出的 Agentic Workflows，使其意外暴露私有仓库中的敏感数据。攻击者仅需在任意公开的 GitHub Issue 中插入一段看似无害的自然语言指令，即可绕过现有安全机制，诱使 AI Agent 将本应严格保密的信息直接发布至公开评论区。
该漏洞所针对的 Agentic Workflow 由 Noma Labs 在审计中发现，其被设定为监听 issues.assigned 事件——一旦某 Issue 被指派给成员，Agent 即自动读取其标题与正文内容，并调用 add-comment 工具生成并发布回复；更关键的是，该 Agent 被授予了读取所属组织内全部仓库（含私有库）的权限。
利用此漏洞完全无需技术门槛：攻击者既不需要编程能力，也不需要账户凭证或任何访问权限。只需在目标组织已启用 Agentic Workflow 的公开仓库中新建一个 Issue，静待自动化流程触发即可。
Noma 指出，尽管 GitHub 已部署多层防护策略以抵御此类滥用，但一个极其普通的连接副词——“Additionally”，就足以让模型偏离预设行为轨道。该词被模型解析为任务延续而非新指令，从而突破防护逻辑，导致其擅自访问受保护文件，并将内容原样输出至公开评论。
传统安全范式默认信任边界由程序代码定义与守卫；而在 Agentic 架构中，这一边界部分交由模型自身的行为逻辑承担——而模型的核心特性恰恰是忠实执行所见指令。因此，提示注入正迅速演变为 AI 原生系统的“SQL 注入”：一种横跨整个智能体生态的结构性缺陷，亟需体系化防御框架予以应对。
为缓解风险，Noma 研究团队提出若干关键建议：
- 所有用户可控输入（如 Issue 内容、PR 描述等）必须被明确排除在可信指令源之外；
- Agent 权限须遵循最小必要原则，尤其应避免赋予跨仓库读取能力——此类高权限 Agent 天然构成极具吸引力的攻击靶心；
- 组织需严格约束 Agent 向外部披露的信息粒度，尤其在响应 Issue 场景下；
- 用户输入在送入模型前，必须完成语义清洗或实现与系统指令上下文的物理隔离。
Fractional CTO Vijendra Malhotra 在 LinkedIn 发表评论指出，Noma 的发现彻底颠覆了一个长期存在的认知误区：
私有仓库从来就不是真正的安全边界。它实质上只是组织边界的映射——唯有当阅读你代码的人全是你亲自雇佣并管理的人类时，这一边界才真正有效。AI Agent 的出现，直接瓦解了该前提。[……] 只要某个 Agent 拥有访问你私有仓库的权限，请视其中所有内容为“仅隔一个精巧构造的 Issue 即可曝光”。
Reddit 用户 Significant_Sea_4230 补充道：
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
真正的风险源头，并非 Agent 的“高智商”，而是它被赋予了过载的上下文关联能力、过广的仓库访问范围，或过于宽松的 Token 权限。
用户 cH3332xr 进一步点明技术要害：
“Additionally” 的绕过机制最具启发性——有效载荷本身未作任何修改，仅靠一个衔接词，便令防护系统将整段文本从“新增指令”重新判定为“当前任务的自然延伸”。这本质上是一个决策边界错位问题，而非内容本身存在异常。
作为社区共识性总结，Hacker News 用户 mcv 指出：
SQL 注入的根源在于系统错误地将用户输入当作可执行指令；只要将数据与代码明确分离，该问题便可根治。但提示注入无法通过类似方式消除——因为在此范式中，用户输入本身就是指令的合法组成部分。
如需获取完整技术分析、PoC 实现及防御验证细节，可查阅 Noma 官方发布的深度报告。
原文链接：https://www.php.cn/link/23d71e6d4234397289a175b92937f73e
本文源自微信公众号“AI前线”，作者：Sergio De Simone；译者：田橙；经 36氪 授权转载。
