GitHub 最近推出了 Agentic Workflows——把 GitHub Actions 和一个 AI agent（Claude 或 Copilot）捆在一起，让团队用 Markdown 写工作流，agent 自动读 issue、调工具、回复评论。听起来很美好。
Noma Labs 的研究员看完之后问了一个很朴素的问题：如果 agent 读到了不该信任的内容，会发生什么？
答案是：攻击者只需要在一个公开仓库里发一条 issue，就能让 agent 把同组织下的私有仓库内容以公开评论的形式贴出来。不需要凭证、不需要代码能力、不需要任何系统访问权限。Noma Labs 把这个漏洞命名为 GitLost。
攻击是怎么工作的
GitLost 的根因是 prompt injection——对 agent 系统来说，这已经成了和 SQL 注入之于 Web 应用同等级别的漏洞类别。
GitHub Agentic Workflows 的工作方式是：agent 读取 issue 的标题和正文，然后调用工具执行操作。问题在于，agent 的上下文窗口本身就是攻击面。任何被 agent 读取的内容——issue、PR、评论、文件——只要 agent 把它当成指令来执行，就可能被武器化。
Noma Labs 发现的这个漏洞利用链路极其简单：
- 创建 issue：攻击者在组织下的一个公开仓库里提交一条看似无害的 issue，请求「从客户那边的仓库拉一下 README」
- 触发工作流：issue 被分配（
issues.assigned事件）后触发 Agentic Workflow - Agent 照做：agent 读取 issue 内容，将其中嵌入的指令当作正常任务执行——读取私有仓库的
README.md - 公开泄露：agent 将读取到的内容以公开评论的形式贴在 issue 下，任何人可见
攻击面不限于 issues.assigned。Noma Labs 测试确认，其他 GitHub workflow 触发事件同样有效。
「Additionally」一个词绕过了防护
GitHub 其实为此类场景设置了防护措施（guardrails），意图阻止 agent 读取和泄露私有仓库内容。但研究员发现了一个绕过的技巧——在指令末尾加一个「Additionally」，然后接一段看起来完全合理的后续请求。
这个单词改变了模型的行为：它不再拒绝执行，而是将前面的敏感操作「重新框定」为后续请求的上下文。防护措施识别的危险模式被绕过了，agent 照常执行了数据读取和公开回复。
这不是一个编码错误。这是模型层面的行为偏差——LLM 天然倾向于遵循指令，尤其是当指令被包装得合理且连贯时。无论 prompt 里写了多少安全规则，模型总有可能被巧妙的措辞说服。
从 GitLost 到整个 Agent 安全模型
GitLost 揭示的核心矛盾：传统安全模型靠代码强制执行信任边界，而 agent 系统的信任边界部分靠模型行为来维持。 模型本质上是「遵循指令」的机器，这个特性本身就是安全挑战。
Noma Labs 给出的建议很直接：
- 永远不要把用户可控的内容当作 agent 的可信指令输入
- 权限控制在最小必要范围，跨仓库访问权限的 agent 是最高价值目标
- 限制 agent 能公开发布什么，尤其是在响应 issue 内容时
- 在用户输入进入模型的指令上下文之前做清洗或隔离
GitLost 已通过负责任披露流程告知 GitHub，漏洞细节在 GitHub 知情的情况下公开。
Prompt injection 正在从学术讨论变为每个 AI agent 产品必须面对的安全基线。GitLost 的门槛为零——不需要社工、不需要破解、不需要内网权限。一行文字就够了。
Noma Labs 此前还披露过 GrafanaGhost、DockerDash、Context Crush、GeminiJack 等一系列 agent 安全漏洞。这些研究的共同指向是：agent 越有用，就越危险。有用意味着它能读更多数据、调用更多工具、跨越更多系统边界。每多一层能力，就多一层攻击面。
参考链接：Noma Labs - GitLost 原始报告 · The Register 报道
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
Prompt injection 之于 AI Agent，正如 SQL 注入之于 Web 应用——它是 agent 架构中「信任用户输入」这一假设的结构性代价。