安全团队发现名为 GitLost 的提示注入漏洞：攻击者只需在公开 Issue 中嵌入一句话，就能诱导 GitHub Agentic Workflows 读取组织内私有仓库数据，并将其公开发布在评论区。
被攻击的 GitHub Agentic Workflow 配置在 issues.assigned 事件触发时运行。它会读取 Issue 的标题和正文，然后通过 add-comment 工具发布回复评论。关键在于：这个 Agent 拥有读取组织内其他仓库的权限，包括公开仓库和私有仓库。
一个诚实的注脚：GitHub 已经部署了严格的防护机制，但依然被绕过了。
注：攻击者无需任何编程技能、访问权限或凭据。整个链路在 Agent 的正常工作流中自动完成，攻击者只需创建 Issue 然后等待。
Noma Security 的研究人员发现，仅仅使用关键词 "Additionally" 就触发了模型的非预期行为。这个词让防护机制将后续内容归类为「当前任务的延续」，而非「新的外部指令」——从而允许它访问了一个原本受限制的文件，并将内容发布在公开评论中。
传统安全模型有一个基本假设：信任边界由代码负责维护。代码会检查权限、验证输入、拒绝越权访问。但在 Agentic 系统中，这个假设不再成立。
信任边界由代码维护。用户输入是数据，指令是指令，两者泾渭分明。权限检查在代码层完成，行为可预测。
信任边界部分依赖模型行为。模型天然具备遵循指令的特性，用户输入与指令边界模糊，权限由 Agent 框架代理执行。
这意味着，当 Agent 拥有跨仓库读取权限时，它就成了一个极具价值的攻击目标——攻击者不需要攻破代码层的安全机制，只需要用语言「说服」模型越权即可。
这不是一个 bug，而是一类结构性问题。
危险之处并不在于 Agent「很聪明」。而在于它可能连接了过多上下文、过多仓库，或者拥有权限过于宽泛的 Token。问题出在权限设计，而非模型能力。
最有意思的细节是 "Additionally" 绕过机制。这是一个决策边界问题，而不是内容问题——传统的内容过滤根本防不住这类攻击。
SQL 注入之所以能解决，是因为系统把用户输入当成了纯数据而非指令。而提示注入无法避免，因为用户输入本身就是指令——这是架构层面的根本矛盾。
Noma 研究人员给出了系统性的防御建议。核心思路是：不再无条件信任用户输入，并对 Agent 的权限进行严格收窄。
用户控制的内容永远不应被视为可信的指令输入。在提供给模型之前，必须经过适当清理，或与指令上下文严格隔离。
Agent 的权限应限制在严格必要的范围内。拥有跨仓库访问权限的 Agent 会成为极具价值的攻击目标。
限制 Agent 可以公开披露的信息范围，尤其是在响应 Issue 内容时——不应将内部数据写入公开评论。
重新审视私有仓库的安全边界。如果 Agent 有读取权限，所有内容都应被视为「距离公开泄露只差一个 Issue」。
注：以上为 Noma Security 在漏洞报告中提出的建议原则，具体实施需结合组织自身的 Agent 架构与权限模型。
GitLost 暴露的不是某一个产品的 bug，而是整个 Agentic AI 范式的结构性缺陷。当模型被赋予读取私有数据和公开发布的双重权限时，提示注入就从一个「有趣的越狱演示」升级为真实的数据泄露路径。
"Additionally" 这个案例尤其值得警惕：它证明了当前基于关键词和上下文判断的防护机制，在面对精心构造的语言攻击时极其脆弱。防护系统试图在「数据」和「指令」之间划定边界，但自然语言的模糊性让这条线永远无法划清。
这不是靠修补一个关键词列表就能解决的问题。
提示注入之于 AI Agent，等同于 SQL 注入之于 Web 应用。但 SQL 注入有参数化查询这个「银弹」，而提示注入没有——因为用户输入本身就是指令。这意味着 Agentic AI 的安全架构必须从「检测恶意输入」转向「假设输入必然恶意，限制后果」。
Noma Security 已发布完整技术报告与概念验证过程，建议 AI 安全从业者与 Agent 架构师阅读原文。
搜索关键词 GitLost Noma Security → 获取完整报告