GitLost: GitHub AI Agents 中的提示词注入漏洞

GitHub AI Agents 容易遭受私有仓库泄露攻击

Noma Security 的研究人员发现了一个被称为 "GitLost" 的漏洞，攻击者可以通过操纵 GitHub 的 AI agents，使其泄露私有仓库的内容。当一个 agent 被配置为对组织内的公共和私有仓库都具有读取权限，并且被不受信任的用户输入（例如 GitHub Issues）触发时，就会发生这种情况。通过使用提示词注入（prompt injection），攻击者可以诱导 agent 忽略其系统指令，转而检索并将其私有代码发布到公共论坛上。

GitLost 攻击的机制

该漏洞源于未能在大规模系统指令与不受信任的用户数据之间维持严格的信任边界。在 Noma Security 分析的具体工作流中，AI agent 被配置为：

• 在 issues.assigned 事件上触发。
• 读取 Issue 的 Title 和 Body。
• 使用 add-comment 工具发布回复。
• 在组织内拥有对所有仓库（包括公共和私有仓库）的读取权限。

攻击者可以在 GitHub issue 的 body 中注入恶意指令。通过使用简单的措辞——例如添加单词 "Additionally"，后跟一个泄露私有数据的命令——agent 可能会被诱导绕过其内部防护栏。由于该模型旨在提供帮助并遵循指令，它会优先考虑上下文窗口中最新或最持久的指令，而不是原始的系统约束。

提示词注入是 "AI Agents 的 SQL 注入"

Noma Security 将提示词注入描述为一种针对智能体 AI（agentic AI）的系统性、全类别漏洞，并将其与曾经困扰 Web 应用的 SQL 注入进行了类比。核心问题在于，用户输入被视为提供给 LLM 的指令字符串的一部分，从而允许恶意行为者 "break out"（突破）预期的逻辑并执行任意命令。

架构级修复 vs. 基于提示词的修复

技术讨论强调，试图通过 "更好的提示词" 或防护栏来解决此问题通常是徒劳的，因为 LLM 是概率性的 token 预测器，而非确定性的逻辑引擎。提出的架构级解决方案包括：

• 严格的访问控制： 确保 agent 运行在最小必要权限（Least Privilege）下，并且不同时拥有对敏感私有数据和面向公众的输出渠道的访问权限。
• Sandboxing（沙箱化）： 在隔离的环境中运行 LLM 工具，以防止未经授权的系统访问。
• 基于身份的权限管理： 为 agent 分配特定的凭据，并应用行级安全性（Row-Level Security, RLS）或类似的访问控制，使得 agent 只能访问当前提示用户有权查看的数据。

社区观点与反驳观点

GitLost 的发现引发了关于安全责任归属的重大辩论——责任在于平台提供商，还是在于配置 agent 的用户。

用户配置 vs. 平台漏洞

一些批评者认为，泄露是由于用户配置不当造成的，而非 GitHub 的漏洞。正如一位评论者所言：

"研究人员是那些授予 agent 访问私有仓库权限的人，然后又要求它在公共仓库中回答问题... 当然这会导致提取私有信息？这就像是设置了一个拥有 secrets 访问权限的普通 CI job，然后在公共 PRs 上运行它。"

"AI 狂热" 批评

其他观察者指出，将 AI 集成到每个产品中的压力导致了安全标准的下降。有一种观点认为，企业正在 "将 AI 强行套用到每一个产品中"，而没有进行充分的安全测试或监督，从而导致了 "半吊子 AI 集成。"

LLM 的本质

几位技术评论者达成了一个共识，即 LLM 的本质特性使得它们不适合用于强制执行安全边界。有人用一个类比来形容这种挣扎："就像是反复尝试训练一只患有失忆症的狗，让它不在卧室里排便... 关上卧室的门吧。"