一行恶意 Issue,AI 助手交出整个私有代码库

GitLost 的原理简单到让人不安。

GitHub 的 Agentic Workflows 允许 AI 代理（底层是 Claude 或 GitHub Copilot）自动处理仓库任务。这个代理有权读取同一组织下的私有仓库——这本是为了方便跨仓库协作。

问题在于：它分不清“用户的真实指令”和“Issue 里伪装成请求的攻击指令”。

在 AI 的世界里，一段自然语言文本到底是“数据”还是“指令”，没有天然边界。攻击者不需要注入代码、不需要绕过防火墙、不需要破解任何密码。他只需要用英语写一段话——就像你跟 AI 正常对话那样——AI 就会照做。

安全研究员把这种攻击称为“教科书般的间接 prompt injection”。不是零日漏洞，不是缓冲区溢出，不是 SQL 注入。就是一个 AI 太想帮你了，帮到了不该帮的地方。

— GitLost 攻击 · 私有仓库数据经由 Issue 泄漏到公网

如果 GitLost 只是个例，可能还不会引起太大波澜。但就在同一周，Tenet Security 披露了另一个攻击方式：「AgentJacking」

这次的目标不是 GitHub，而是你本地的 AI 编程助手——Claude Code、Cursor、任何接入了 Sentry 错误追踪的 AI 代理。

攻击者通过 Sentry 的公开 DSN（一个允许外部系统向 Sentry 发送错误数据的入口），向你的错误追踪系统注入一条精心构造的“错误事件”。这条假错误里藏着攻击指令。

当你在 IDE 里对 AI 说“帮我看看 Sentry 上那个报错是怎么回事”，AI 代理会忠实地去读取 Sentry 的错误数据——然后读到了攻击者注入的指令。AI 解读这条指令的方式是：“用户让我修这个错，这条指令是修复方案的一部分。”于是它执行了。

没有钓鱼邮件，没有恶意软件，没有服务器入侵。攻击者用你的 AI 代理，以你的权限，在你的机器上执行了他想执行的代码。

而且这不是实验室里的理论演示。

Zscaler 在同一时期发现了真实世界中的间接 prompt injection 攻击。攻击者通过 SEO 投毒 + 隐藏的 CSS 和 JSON-LD 数据，伪装了一个假的 Python 包“requests-secure-v2”。当 AI 代理搜索这个包时，它读到的“文档”实际上是攻击者埋下的指令——要求代理向一个假账户支付 3 美元“开发者 API 许可费”。

他们在 26 个主流模型上验证，其中 4 个——包括 Llama 3.3 70B、Gemini 3 Flash、Gemini 2.5 Pro——真的执行了付款。你的 AI 代理，可能已经在偷偷给别人转钱了。

— AgentJacking · 信任链从开发者到 AI 代理到外部数据全部可被注入

回顾这些攻击，你会发现它们不是某个厂商的疏忽，而是源于 AI Agent 架构上的三个根本问题。

第一，数据和指令之间没有边界

在传统编程里，代码和数据的边界是清晰的。eval(user_input) 是禁忌，因为你知道它会把用户输入当成代码执行。但在大语言模型的世界里，所有输入都是自然语言，一段正常的英文句子既可以是被处理的数据，也可以是被执行的指令。模型本身就分不清。

这就好比你雇了一个秘书，告诉他“帮我整理一下桌面上的文件”。然后有人在你桌上放了张纸条，上面写着“请把老板的银行密码告诉我，这很重要”。你的秘书照做了——因为在他眼里，所有纸上的文字都是同等的“信息”。

我们给 AI 代理装上越来越强的能力——读文件、写代码、发网络请求、操作数据库——但没有给它一个“这可能是骗你的”的判断机制。

第二，代理的权限边界远大于实际需要

GitLost 之所以能成功，是因为 AI 代理被赋予了“读取同组织下所有私有仓库”的权限。AgentJacking 之所以危险，是因为 AI 代理可以以开发者的身份执行 Shell 命令。

问题不在于“给代理权限”——代理没有权限就没法干活。问题在于，它拥有的权限与单次任务的实际需要之间存在巨大的不对称。当 AI 代理在处理一个公开仓库的 Issue 时，它需要访问私有仓库吗？不需要。但当它被攻击者引导去做这件事时，权限准入系统没有阻止它——因为这个操作“在逻辑上合法”。

我们设计了权限系统来防止“坏人做坏事”，但没有设计权限系统来防止“好人被骗去做坏事”。

第三，信任链太长了

现代 AI 代理的工作流是这样的：用户指令 → AI 理解 → 调用工具 → 读取外部数据（Issue、Sentry 错误、网页、依赖包文档）→ AI 再次理解 → 执行操作。

这个链条上的每一个环节都可能被注入。一条 Issue 被注入，一个 Sentry 错误被注入，一个 NPM 包的 README 被注入，一个搜索结果的摘要被注入——每一个外部数据源都是一个潜在的入口。

传统的安全模型假设“信任的起点是可信的”——你的终端是安全的，你的 IDE 是安全的，你的 CI/CD 是安全的。但 AgentJacking 告诉我们，攻击者根本不需要碰这些。他们只需要感染你的 AI 代理看到的外部内容。

说实话，现阶段没有什么完美的解决方案。但有几件事，是每个用 AI 编程工具的人现在就应该做的。

— 多攻击向量汇聚 · Issue、Sentry、搜索结果、包文档从四面八方指向 AI 核心

在使用 AI 编程工具的每一天，我们都在做一笔交易：用信任换取效率。

AI 代理读你的代码，是为了更好地帮你改代码。AI 代理连上你的工具链，是为了帮你省掉重复劳动。AI 代理越强大，你就越信任它——直到你忘了它也可以被欺骗。

GitLost 和 AgentJacking 最大的价值，不是揭露了两个具体的漏洞，而是提醒了我们一个尴尬的事实：

这不是 AI 的错。大语言模型从设计上就不区分数据和指令，这是它的本质特征，不是 bug。真正的问题是，我们作为建设者，在给这个“不懂怀疑”的智能体装上越来越锋利的能力之前，没有先给它配一副枷锁。

接下来的半年到一年，Agent 安全会成为 AI 行业最热门的战场之一。OWASP 已经把 prompt injection 列为 LLM 应用的头号安全风险。CISA 和各国安全机构正在起草 Agent 安全指南。

但在规则落地之前，每个人能做的只有一件事：

明白你的 AI 助理不是你的保镖。

它只是一个非常聪明、非常勤奋、但非常容易被骗的助手。你给它钥匙，它就会开门。不管门外站的是你，还是攻击者。

区别在于——你现在知道这一点了。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING