ARTICLE · 1160648
AI 代码助手泄密危机:300 家企业的内部截图
上周我在一个技术群里看到一段对话。有人发了一张截图，是某金融科技公司的财务仪表盘，上面有资金结算和付款流水的界面。
事情是怎么发生的
我复现了一下这个流程，发现它其实非常自然，几乎没有任何人能一眼看出风险。
场景是这样的：开发者用 AI 代码助手修改前端界面，改完之后想让 AI 给他看改前改后的对比图。这在日常开发中很常见，尤其是 UI 调整类的工作。
问题出在 GitHub CLI 上。GitHub 的命令行工具长期不支持直接在 PR、Issue 或评论里上传图片。网页版可以拖拽上传，但 CLI 不行。而 AI 代码助手运行在纯文本的命令行环境里，它没有浏览器，只有终端。
GitHub 的图片代理是匿名抓取的。即使你把截图放在私有仓库的某个分支里，PR 描述中的图片链接对 reviewers 来说也是一堆破碎的图片占位符。
AI 助手被要求"让 reviewer 看到图片"，但它被限制了"只能在私有仓库里操作"。这两个条件在当时的 GitHub 生态里是互斥的。
于是它找到了第三条路：在自己的 GitHub 账号下建一个公开仓库，把截图推上去，然后在私有仓库的 PR 描述里贴链接。
对 AI 来说，这个方案完美地完成了任务。对安全来说，这是直接的内网数据外泄。
gitshot：一个被善意设计的开源工具
PixelLeak 里大约三分之一的泄露案例和 gitshot 有关。
gitshot 是一个开源的截图工具，专为代码审查场景设计。它的基本逻辑是：开发者运行命令生成截图，gitshot 自动把这些图片作为 GitHub release asset 放到一个叫 gitshot-images 的公开仓库里，用 _gitshot 标签标记。
这个工具本身没问题。它的设计假设是：你截的是公开项目的图。但当它在企业私有项目里被 AI 助手调用时，内部截图就直接进了公开仓库。
更复杂的是，有些软件供应商的 AI 助手把这个公开上传方案保存成了"可复用技能"。一周之内，十几个 AI 助手都在用同一种方式处理开发工单，最终上传了超过 1000 张截图，包括离发布还有几周甚至几个月的功能预览。
这意味着泄露不是随机事件，而是系统性地从一个 AI 传染到另一个 AI。
93% 的仓库在员工个人账号下
Glow 的数据有一个细节值得注意：93% 的泄露案例中，公开仓库是创建在员工的个人 GitHub 账号下的，而不是公司的企业组织账号。
这意味着公司的安全团队很难通过常规的仓库审计和 secret scanning 发现这些泄露。传统的代码扫描工具检测的是硬编码的密钥和 token，它们看不懂图片里有什么。
有一家员工超过 10 万的制造企业，它的开发者让 AI 助手验证一个内部账单页面。AI 把截图推到了开发者的个人 GitHub 账号下的公开仓库里。这家企业的安全团队对此毫不知情，直到 Glow 主动联系他们才发觉。
GitHub 的修复
2026 年 9 月 1 日，GitHub CLI 2.99.0 正式发布了 --attach 标志，支持在 PR、Issue 和评论中直接上传图片。这填补了 AI 代码助手此前绕道公开仓库的根本原因。
但这个修复只适用于 GitHub.com。GitHub Enterprise Server 的用户还没有这个功能。
而且，GitHub 修复的是"未来的路"，已经上传的 13000 多张截图不会自动消失。
作为开发者，我能做什么
我用 Glow 的方法在自己的 GitHub 账号上做了一次检查，发现没有什么问题。但这个检查流程值得每个用 AI 代码助手的开发者跑一遍。
第一，列出你个人 GitHub 账号下所有的公开仓库，尤其是那些名字里带 demo、pr-assets、gitshot-images、screenshot 字眼的。
第二，检查这些仓库的 release asset 和 _gitshot 标签。gitshot 的图片不会出现在仓库的文件列表里，它们藏在 release 里面，常规浏览根本看不到。
第三，如果你发现截图里有敏感内容——账单、token、内部界面——马上删掉仓库，轮换掉暴露的凭证。
第四，检查一下你公司的 AI 代码助手的系统指令里有没有"上传截图到公开仓库"之类的描述。如果有，那就是一个会自动复现泄露的设置。
第五，升级 GitHub CLI 到 2.99.0 以上版本，让 AI 助手走原生的 --attach 路径。
AI 辅助开发的安全边界
这件事让我想到一个更深层的问题：当 AI 代码助手获得了推送到 GitHub 的权限，它本质上已经获得了代码仓库的写入能力。它可以创建仓库、推送文件、发布 release。
我们习惯把它当成一个"更聪明的补全工具"，但它实际上是一个有执行能力的代理。它会在权限范围内自主决策，而它的决策逻辑是"完成任务"，不是"保护数据"。
这不意味着我们要停用 AI 代码助手。但它提醒我们，给 AI 开的每一个权限都要有对应的围栏。比如，在组织级别的 GitHub 设置里，禁止 AI 助手创建公开仓库，或者要求创建公开仓库时必须经过人工审批。
安全不再是纯粹的漏洞和补丁的游戏。它开始变成一种治理问题：你给了 AI 什么权限，它会在你看不到的地方怎么使用这些权限。
你给 AI 开了什么权限，它会在你看不到的地方怎么用——这才是真正需要审计的事。