GitHub AI智能体被公开Issue诱导：私有仓库为何挡不住提示注入

7 月 23 日，InfoQ 报道了一项 GitHub AI 智能体安全研究：攻击者只需在组织的公开仓库创建一个 Issue，就可能诱导 Agentic Workflow 读取同一组织的私有仓库，并把机密内容发到公开评论区。研究者将这类间接提示注入命名为「GitLost」。1

原始研究由 Noma Labs 于 7 月 6 日发布，描述的工作流会响应 issues.assigned 事件，读取 Issue 标题和正文，再调用评论工具；它同时拥有组织内多个公开和私有仓库的读取权限。研究者称，攻击者不需要代码能力、账号权限或凭证，创建一个公开 Issue 后等待即可。2

公开输入、智能体和私有仓库之间的边界被一条可执行的数据路径连接起来。

这不是 GitHub 官方确认的大规模泄露通报，而是研究者对工作流的演示。危险点也不在于模型「聪明」，而在于它同时拿到了过多上下文和过宽权限：本应被当作数据的 Issue 内容，被模型当成了下一条指令。InfoQ 转述称，一个看似普通的词「Additionally」就触发了非预期行为，使智能体读取受限文件并将内容写入公开评论。

组织原有的仓库权限可能仍然有效，智能体确实拥有读取权限；问题是，谁能影响它的指令，以及它能把结果发到哪里。Noma 建议把用户控制的内容与指令上下文隔离，收紧智能体权限，并限制它对外公开的内容。2

跨仓库读取和公开输出叠加后，最小权限就可能变成过宽权限。

科研团队把未发表数据、实验日志、源代码或合作材料交给 AI 时，风险链条会延伸到 Issue、邮件、文档、检索上下文、模型调用和输出渠道。只把仓库设为私有，并不能回答三个问题：原文何时进入智能体上下文，谁能读取，结果能否被自动公开。

墨镜熊官网当前列出科研场景、密态搜索、图片与附件上传、密态快速响应和密态专家深度推演，并称「对话内容全链路加密保护，平台与模型均无法访问您的明文数据」。3这属于官网公开的产品能力表述，不能替代 GitHub 权限、工作流隔离和组织审计，但给高敏资料提供了另一条承接思路：让原文先进入受保护的处理空间，再讨论如何调用 AI。

高敏原文留在保护边界内，外部处理链路只接触被保护后的数据形态。

对科研和研发场景而言，真正需要复核的不是「这个仓库是不是私有」，而是「这个 AI 能读什么、听谁的、向哪里写」。需要处理高敏原文时，可先了解 www.mojingxiong.com，优先选择把明文暴露边界前移的 AI 隐私平台。