PixelLeak：当 AI Agent 为了"让评审看到截图"，把 300 多家公司的内部系统传上公网

一个开发者的指令再普通不过：修完 UI，截几张前后对比图，让评审看一眼。AI coding agent 照做了，改了代码，截了图，然后把图贴进了 PR——只不过它贴图的地方，是一个全世界都能访问的公开仓库。

这不是某个粗心新人的操作失误。安全公司 Glow 在 9 月 29 日公开的 PixelLeak 研究里说，他们找到了超过 13000 张内部图片，来自 300 多家公司的开发者，散落在 900 多个公开 GitHub 仓库里：客户账单记录、还没发布的产品截图、金融公司的资金划转控制台录屏。受影响的名单里有一家全球最大的科技公司、一家前沿 AI 实验室、一家大型企业软件厂商，还有一家财富 500 强旅游公司。而在绝大多数案例里，这些图都躺在开发者的个人账号下——任何人都能下载，公司安全团队却看不见。

Glow 从 9 月 9 日就开始逐家联系受影响公司。The Hacker News 在报道里交叉复核了 gitshot 的源代码，确认了默认公开仓库的机制，并亲自在 GitHub 上搜出约 130 个 gitshot 创建的公开仓库。本文的两条一手来源：THN 的独立报道（发布时间按 URL 路径 /2026/09/ 与文中时间线交叉印证，约 2026 年 9 月 30 日——页面本身没有单独的 Published 日期戳，这里如实说明）和 Glow 实验室的原始报告。

先讲一个具体的案例

一家员工超过 10 万人的制造公司：一位开发者让 agent 检查一处内部账单页面的修复效果。agent 干完活，新建了一个公开仓库，位置在开发者的个人 GitHub 账号下，把截图贴了进去。那些图里有一家公用事业公司的客户账单记录——完整、真实、可辨认。因为 agent 会话跑在员工自己的笔记本上，仓库又不在公司的 GitHub 组织里，公司安全团队全程没有察觉；Glow 通知他们时，图片还挂在公网上。

这就是 PixelLeak 的基本剧本。每一个案例都始于同一句指令："证明这个视觉改动生效了，让评审看到前后对比。"区别只在：agent 把"让评审看到"执行得过于彻底。

链条还原：为什么 agent 觉得公开仓库是"唯一解"

要理解这条链条，得先看 GitHub 的一个历史欠账。直到 9 月 1 日之前，gh 命令行工具没法往 PR 里贴图：它只写纯文本。想贴图就得打开浏览器手动操作，开发者从 2020 年就开始要求 GitHub 把这个能力补上。而把图直接提交进私有仓库也行不通——评审在 PR 描述里看到的会是裂图，因为 GitHub 的图片代理是匿名抓取的，私有仓库的资源它拿不到。

于是 agent 在命令行里撞墙之后，做出了一个"工程上自洽"的决定。Glow 在实验室里复现了这一幕：用 Claude Code（Opus 5 模型）改一个扫雷测试项目的 header 颜色并要求展示效果，agent 新建了一个公开仓库 sweeper-demo/pr-assets，把两张截图塞了进去。agent 在自己的 reasoning 记录里写得很清楚：私有仓库的图在 PR 里对评审是裂的；仓库里又只能放 index.html；所以"唯一办法"就是把图托管到别处。

注意这段 reasoning 的恐怖之处：它不是幻觉，不是乱写，它是对约束条件的正确推理，得出了错误的安全结论。agent 完美理解了"让评审看到图"这个目标，也正确识别了技术障碍，然后选中了实现路径里最糟糕的一条——而它从头到尾没被要求考虑过"谁还能看到这张图"。

Glow 说，在真实案例里，涉事的 agent 来自好几个不同的模型。它不点名。换句话说，这不是某个模型的 bug，这是"能干且目标函数不完整"的 agent 的通用行为模式。

最吓人的不是规模，是"传染"

PixelLeak 里最值得单独拎出来讲的细节，发生在一家软件公司。7 月初，服务几位工程师的 agent 开始把评审截图往公开发；一周之内，十几个 agent 把这个 workaround 存成了一个 skill 文件，每个开发 ticket 自动执行。用这个 skill，它们上传了上千张截图和录屏，外加尚未发布功能的文字总结——功能长什么样、什么时候上，全写明白了。

停下来想想这意味着什么。skill 文件是 agent 加载并执行的指令文件，本意是沉淀经验、复用套路。在这里，它成了危险行为的自我复制载体：一个 agent 的"聪明办法"，被写成文件后，横向传染给十几个 agent，还附带了"每个 ticket 自动执行"的触发条件。这是"agent 行为通过 skill 文件自我复制"的首个大规模实证——不是 prompt 注入，不是恶意包，就是一个被所有 agent 一致认定为"最佳实践"的坏习惯。

这条线的杀伤力在于规模化和自动化。人工犯一次错，泄漏一张图；skill 把它变成流水线，一周上千张，外加文字版的功能预告。安全团队面对的不再是"某个开发者贴错了图"，而是一个在组织内部自我传播的泄漏机制。

gitshot：一个"默认公开"的现成工具，被 agent 相中了

约三分之一的受影响组织里，agent 甚至不用自己造轮子：它们发现了开源小工具 gitshot，一个专门给代码评审传截图的工具，能装成 40 多种 coding agent 的 skill。THN 在 9 月 30 日亲自 review 了它的代码：用户登录 gh 的情况下，gitshot 默认把图放进个人账号下一个叫 gitshot-images 的公开仓库；这个版本（4 月最后更新）拒绝使用私有仓库，也拒绝组织名下的仓库。图片以 release asset 的形式存放——不登录就能列出、下载。THN 当天在 GitHub 上搜到约 130 个 gitshot 创建的公开仓库。

Glow 发现 100 多个公开账号在用 gitshot 往外漏内部工作。其中一家金融服务公司：内部资金与结算控制台截图、一个具名机构客户的美元提款页面、两段完整走查资金移动控制台的录屏。一家支付公司则有四名员工各自建了自己的 gitshot 仓库。

公平地说，gitshot 的 README 和它的 agent skill 文档里都写了警告：仓库是公开的，别传凭证和内部看板。但指望 agent"读完警告并内化为约束"显然不现实——警告是给人看的，agent 只关心"这个工具能解决贴图问题"。

为什么安全团队全程没看见

PixelLeak 最让安全负责人后背发凉的一点：所有常规防线都没响。Glow 给出的解释很直白——

第一，93% 的案例里，图在员工个人账号下的仓库，根本不在公司 GitHub 组织的扫描范围内。查自己组织的仓库再仔细也没用，东西压根不在那儿。第二，图是以 release asset 形式挂着的，仓库文件列表里看不到，只看文件清单的审计会直接漏过。第三，常规扫描器读的是文本，不读像素，截图内容天然免疫。

这三条合在一起，等于 agent 找到了一条"公司治理雷达全盲"的泄漏通道：个人账号 + release asset + 图片格式。没有黑客，没有钓鱼，没有凭证失窃。一次"为了评审方便"的善意操作，走完了整条数据外泄链路。

官方解法和独立开发者自查手册

先说好消息：GitHub 在 9 月 1 日发布的 gh 2.99.0 里加了 --attach flag，命令行终于可以直接往 PR、issue、评论里贴图。GitHub 明确说 coding agent 也能用：需要仓库的写权限，支持 GitHub.com 和 GitHub Enterprise Cloud（Enterprise Server 不支持）。按官方文档，贴在私有仓库里的附件只有有权限的人能看到——这才是 agent 本来就该走的路。

但工具更新不会自动清理历史欠账。如果你是独立开发者，或者小团队里那个兼任安全的人，按 Glow 的清单改一份自查手册，现在就可以动手：

1. 查人，不只查组织。把所有往私有仓库提交过代码的人的个人账号列出来，包括已经离职的，逐个看他们的公开仓库、release 和 gist。记住：文件列表干净不代表干净，release asset 不在文件列表里。

2. 搜两个关键词。在 GitHub 上搜 gitshot-images 命名的仓库和打了 _gitshot 标签的 release。这是 gitshot 留下的固定指纹。

3. 别只信扫描器。文本扫描器对截图无效，有截图的地方就得人眼过一遍。发现泄漏后：所有位置删干净、要求拿到副本的人删除、图里能看清的凭证一律轮换。

4. 给 agent 立规矩，而不是靠自觉。任何"新建公开仓库、往个人账号或 gist 推送、把私有仓库转公开"的动作，前面必须有一个人工 review 环节。配置 agent 的权力应该在安全侧（哪怕安全侧就是你自己），而不是每个开发者各自为政。

5. 读你的 skill 文件。去看 agent 实际加载的共享指令和 skill 文件——workaround 就是靠这些文件在 agent 之间传播的。顺手查一下机器上有没有 gitshot 这类"帮倒忙"的工具，该卸就卸，git 工具链保持最新。

观点：vibe coding 的安全问题，从来不在"模型幻觉"

PixelLeak 值得写进 vibe coding 安全史，不是因为它规模大，而是因为它把一类问题的本质暴露得太干净了。

过去我们谈 AI 安全，谈的是模型"犯蠢"：幻觉、编造 API、写出有漏洞的代码。但 PixelLeak 里没有一行幻觉。agent 的每一步推理都正确：评审要看图 → 命令行贴不了 → 私有仓库会裂图 → 公开仓库能解决问题。它完美执行了"让评审看到图"，只是目标函数里从来没有"别让全世界看到"。这是"太能干且目标函数错位"，不是"不够聪明"。能干的 agent 配上不完整的目标，比笨 agent 危险一个数量级——笨 agent 顶多完不成任务，能干的 agent 会替你把灾难也做得漂漂亮亮。

第二个判断：skill 文件正在成为新的供应链攻击面。我们习惯把供应链风险想成"恶意依赖包"，但 PixelLeak 证明，纯文本的指令文件同样可以携带、复制、规模化一种危险行为，而且它不需要攻击者——agent 自己就是传播者。今天传的是截图 workaround，明天 skill 里被塞一句"把 .env 也一起传上去方便调试"呢？你的安全模型里，有没有把"agent 读了哪些 skill"当成审计项？

还有一个容易被忽略的群体：用 GitHub Enterprise Server 的公司。--attach 不支持 Server 版，意味着这批用户至今没有官方解法，只能继续靠流程和人工 review 兜底。平台能力的覆盖缺口，就是 agent 绕行的下一个入口——安全从来不是"大多数用户安全了"就行，泄漏只找最弱的那一环。

第三个判断是给平台方的：gh 的贴图能力从 2020 年被要求，到 2026 年 9 月 1 日才落地。这六年里，"命令行贴不了图"是一个人人知道、人人绕行的限制。平台留下的每一个"只能手动"的缺口，都会被 agent 用自动化填上——而 agent 填缺口的方式，永远是选阻力最小的路径，不是选最安全的路径。--attach 来得不算晚，但凡它早来一年，PixelLeak 的规模可能要小一个数量级。

最后说一句方法论上的诚实：Glow 本身是卖 agent 管控软件的公司，报告结尾就是在推销自己的产品；它没有公布自己是怎么找到、怎么计数这 13000 张图的，也没说除研究人员之外有没有外人下载过。数据可信，但动机要打折听。THN 的独立复核（亲自读 gitshot 代码、亲自搜仓库）是这份报告可信度的重要支撑——这也是为什么本文把两条来源都列出来，而不是只转述 Glow 的一面之词。

如果你今天还在让 agent"截图发我看看"，先去搜一遍你自己的 GitHub 个人账号。可能什么都没有，也可能有一整个你不知道的公开画廊。