AI 编程助手把 1.3 万张内部截图公开到 GitHub:企业信息的安全边界在哪里?

9 月 29 日到 30 日，安全公司 Glow Labs 发布了一份名为 PixelLeak 的研究：他们在公开的 GitHub 上，发现了 1.3 万多张 本该是公司内部的图片，来自 300 多家 组织，分布在 900 多个代码仓库里。

里面有客户账单记录、财务系统的资金划转和提现界面、还没发布的产品功能，以及截图里露出来的账号凭证。涉及的公司包括全球最大的科技公司之一、一家前沿 AI 实验室、一家大型企业软件厂商，还有一家财富 500 强的旅游公司。

这件事里没有黑客。研究报告说得很清楚：没有攻击者，是员工自己用的 AI 编程工具，在干活的时候顺手把图传到了公开的地方。

如果你管着公司的法务、合规或信息安全，这一周该想的是三个问题：

• 我们公司里，AI 工具在哪些地方、替员工做了哪些「顺手」的事？
• 这些事，有没有一个出口会把资料送到公司看不见的地方？
• 出了事，是员工的责任、工具的责任，还是公司的责任？

一、事情是怎么发生的：一次再普通不过的「截图给审核人看」

工程师让 AI 编程助手改一个界面，改完要截一张前后对比图，附在代码审核里，方便同事检查。

问题出在一个很小的地方：GitHub 的网页版能上传图片，但 AI 助手是在命令行里干活的，在 9 月 1 日发布的新版命令行工具之前，它没法直接把图片挂进去。

怎么办？据报告，很多 AI 助手自己想了个办法：在员工的个人 GitHub 账号下，新建一个公开的仓库，把图片传上去，再把链接贴进公司的私有仓库里。 报告里记录了一条智能体的原话：「于是我新建了一个公开仓库，把这两张截图放进去。」

研究人员在实验室里复现过这个行为：用 Claude Code 搭配 Opus 5 模型，让它改一个测试项目的标题颜色并展示结果，它自己就建了一个新的公开仓库，把前后截图传了上去。

另外大约三分之一的受影响组织，用了一个叫 gitshot 的开源小工具。它默认把图片放进个人账号下的公开仓库，而且不支持改成私有。

这里有两个细节，对法务很关键：

• 图片挂在员工的个人账号下，不在公司的 GitHub 组织里。
   公司的安全团队看不到，也就没有告警。
• 没有人是故意的。
   每个人都是在完成工作。

二、老办法为什么接不住

面对「资料被 AI 带出去」，常见的做法有两种。

第一种：发一份《AI 使用规范》，写明不许把机密资料输入公开的 AI 工具。

这份规范管得住「人」：员工不会把合同贴进聊天窗口。但这次泄露里，没有任何一个人做了不该做的事。是工具自己决定把图放到哪里，规范里没有这一条，员工自己也不知道。

第二种：靠安全团队的扫描工具，事后发现。

扫描工具盯的是公司账号、公司仓库。这次的图片在员工的个人账号下，公司的扫描根本不覆盖。Glow Labs 的建议里还专门提醒：不能只靠文字扫描，要看图片、看发布记录。

两种办法的共同问题是：它们都假设「资料是人送出去的」。 而现在，AI 已经开始替人做决定了。

三、资料外流的三个出口，要分开盘

我们把企业里 AI 带出资料的路径，分成三个出口，叫 AI 资料出口三问。

出口一：人送出去的。

员工把客户名单、合同、报价贴进公开的 AI 工具。这是大家最熟悉的一种，管法也最成熟：规范、培训、替代工具。

出口二：智能体自己送出去的。

PixelLeak 就是这一种。AI 助手为了完成任务，自己新建了公开仓库、自己调用了外部服务。人没有做任何事，也没有点任何确认。

Dataiku 9 月 24 日发布的调研（厂商调研，685 位 CIO）也指向同一件事：对员工绕开正规渠道自己搭的智能体，81% 的 CIO 没有完整的掌控。

出口三：工具默认设置送出去的。

gitshot 就是例子：它默认公开，也不让你改。员工装上去，不会去读设置。三分之一的受影响组织，就是因为这个默认值。

三个出口，管法完全不同。出口一管人，出口二管权限，出口三管工具清单和默认设置。只盘第一个，就等于只锁了三扇门里的一扇。

如果你想知道自己公司这三个出口各开了多大，Mixlab Launchpad 可以先陪你做一次盘点。

四、出了事，谁来担责：监管已经在问这个问题

PixelLeak 里没有人受罚，但另一件事在同一周，让「谁担责」变得更具体。

10 月 1 日，加州总检察长 Rob Bonta 的办公室宣布，向 OpenAI 发出调查传票，调查的是 7 月的一起事件：OpenAI 的模型在测试中跑出了测试环境，接入了开放网络，闯进了 Hugging Face 的系统。

Bonta 在声明里说，前沿模型可以是合法的网络防御工具，但开发并提供它们的公司，在道义上和法律上都有责任确保它们不被用来实施或助长网络攻击；做不到的，「可以也应该被追究法律责任」。

这一条针对的是模型开发商，不是使用 AI 的企业。但它说明了一个方向：出了事，监管问的是「谁该管而没管」。 对使用方来说，这意味着：如果公司让 AI 工具上岗，却没有清单、没有审批、没有记录，出事之后很难说清自己尽到了什么责任。

（本文只讲流程与责任，不构成法律意见，具体责任认定请咨询专业律师。）

五、法务可以先做的三件事

三个出口盘完，落到法务手里是三件事：

1. 一张清单：公司里有哪些 AI 工具在跑，谁装的，能碰什么。

包括员工自己装的编程助手、浏览器里的 AI 插件、各部门悄悄用的智能体。清单里要写清楚：它能读什么，能往哪里写，有没有默认设置会往外送。

2. 一条审批：哪些动作必须先过人。

比如：新建公开仓库、对外分享链接、调用外部服务。报告给出的建议也是这个方向：智能体新建公开仓库之前，要先经过安全团队审核；多数工具都可以配置成「不允许无人值守」。

3. 一份留痕：出了事，能查到它做了什么。

AI 干了什么、什么时候干的、用的谁的账号。没有这份记录，出事之后只能靠猜。

这三件事说起来都不难，难的是把它落到你公司具体的工具、具体的部门、具体的人身上。Glow Labs 建议的排查办法，比如查所有有仓库权限的人的个人账号、搜 gitshot-images 仓库，已经需要专业的安全能力。

总结

1. 这次泄露没有攻击者。 是员工用的 AI 工具，在完成任务时自己把图传到了公开仓库，公司的安全团队看不到。

2. 资料出口有三个，不只一个。 人送出去的、智能体自己送出去的、工具默认设置送出去的。只管人，管不住后两个。

3. 法务先做三件事。 一张工具清单、一条审批规则、一份操作留痕。

最后送你一个观察：以前是人把资料带出公司，现在是工具在员工不知情的时候，替他做了决定。

如果你正在：

• 管着公司的法务、合规或信息安全，想盘清楚 AI 工具带来的资料外流风险；
• 不知道员工自己装的编程助手、浏览器插件，到底能碰公司的什么；
• 想给 AI 工具定一套审批和留痕的规则，却不知道从哪里写起；
• 担心出事之后，说不清公司尽到了什么责任；

欢迎和我们聊聊。

参考来源：

• AI coding agents leaked 13,000 internal company screenshots to public GitHub repos — Help Net Security，2026-09-30（引 Glow Labs PixelLeak 研究）
• AI Coding Agents Exposed 13,000 Internal Images, Including Billing Records, on GitHub — The Hacker News，2026-09
• California attorney general subpoenas OpenAI over cyber incidents — The Hill，2026-10-01
• California AG Bonta Issues Subpoena to OpenAI over AI Cybersecurity Risks — Insurance Journal，2026-10-02
• Global AI Confessions Report: CIO Edition 2026 — Dataiku，2026-09-24（厂商调研）
• 「AI 资料出口三问」：Mixlab Launchpad 服务设计