AI生成的代码仓库为什么会泄露密钥？截图、配置文件和提交记录的防护清单

网络安全机构 Glow Security 近期称，多个 AI 智能体生成的公开 GitHub 仓库里含有大量截图，其中一部分泄露了科技公司的敏感信息，相关内容见 新浪的信息安全热点小时报。这条消息来自聚合转载，具体细节请以原始发布方为准。

不管细节如何，这类问题的原理并不神秘：让 AI 帮忙写代码、整理项目、自动提交时，它会把工作目录里能看到的东西一并放进仓库，其中就可能包括配置文件、日志、测试截图、含密码的笔记。而仓库一旦公开，或者被设成了公开，里面的内容会被各类扫描程序很快抓取。

对正在用 AI 辅助开发网站、小程序或后台系统的团队来说，这不是别人的事。下面按“为什么会泄露、怎么预防、泄露后怎么处理”三个部分，给出一套可执行的清单。

一、AI 辅助开发时，敏感信息是怎么进到仓库的

先弄清楚常见路径，才知道防哪里。

1. 配置文件被整体提交。 数据库连接、支付接口、短信平台、对象存储的密钥，往往集中放在一个配置文件里。AI 在“把项目全部提交”的指令下，会把它一起带上。
2. 密钥被写进代码。 为了让示例能跑通，AI 或开发者会把密钥直接写在代码里，想着“先用着，以后再改”，然后就忘了。
3. 截图和日志被带上。 调试时为了让 AI 看懂页面，会截图；这些截图里可能有后台页面、客户姓名、订单号、接口地址、令牌。截图被放在项目目录下，随后被一起提交。
4. 提交记录里留有历史。 即使后来把密钥从文件里删掉，旧的提交记录里依然能查到。很多人以为删除文件就安全了，其实不是。
5. 仓库可见性设置错误。 私有仓库误设为公开，或者把代码同步到了公开的演示仓库、分享链接。
6. 示例文件里放了真实数据。 为了方便，把真实的配置复制成示例文件，只改了文件名，没改内容。

二、预防第一层：让敏感文件根本进不了仓库

1. 配置 .gitignore

新建项目的第一步，就是写好忽略规则。至少包含这些类别：

• 配置与环境文件：例如 .env、各类 config 里放真实密钥的文件；
• 日志与缓存：*.log、缓存目录、临时目录；
• 截图与调试素材：专门建一个 debug 或 screenshots 目录并整体忽略；
• 备份与导出：数据库备份、导出的表格、压缩包；
• 编辑器与系统文件。

同时保留一个不含真实值的示例文件，比如 .env.example，里面只写变量名和占位说明。这样新成员知道要配置什么，仓库里却没有真实密钥。

2. 密钥放环境变量，不放代码

代码里只读取环境变量，真实值在服务器或部署平台里配置。好处是：代码可以放心分享，换密钥时也不用改代码。对于较复杂的项目，可以用专门的密钥管理服务。

3. 给 AI 的指令里明确边界

让 AI 助手操作项目时，在指令里写清楚规则，比如：

• 不要读取或输出 .env 和配置文件中的密钥；
• 不要提交截图、日志、备份目录；
• 提交前先列出将要提交的文件清单，等确认；
• 需要示例时一律用假数据。

这几句话能挡住相当一部分“顺手带上”的情况。

三、预防第二层：提交前和提交后的自动检查

人会疏忽，所以需要自动检查兜底。

1. 提交前钩子

在本地设置 pre-commit 检查，提交时自动扫描将要提交的内容，一旦发现像密钥的字符串、私钥文件头、常见云服务的访问密钥格式，就拦截提交。这是成本较低的一道防线。

2. 仓库端密钥扫描

主流代码托管平台通常提供密钥扫描和推送保护功能，建议开启。开启后，推送内容里如果包含识别出的密钥，会被拦截或提醒。

3. 提交前人工看一眼清单

每次提交前，花一分钟看“将要提交的文件列表”，特别注意这几类名字：配置、env、备份、dump、log、截图、导出、临时。看一眼比事后补救要省事得多。

4. 定期扫描历史记录

对已有仓库，用扫描工具检查整个提交历史，而不只是最新版本。历史里的旧密钥同样会被利用。

四、截图专项：容易被忽略的泄露源

新闻里提到的“大量截图”值得单独说。截图的特点是：看起来只是图片，却可能包含大量信息。

• 后台页面截图：可能带有账号、菜单、客户数据、接口地址；
• 报错截图：可能带有服务器路径、数据库名、版本号；
• 聊天截图：可能带有对方姓名、手机号、订单信息；
• 浏览器地址栏：可能带有令牌参数。

处理办法：

1. 截图统一放进被忽略的目录，不放项目根目录；
2. 需要公开的截图（例如文档里的示例图），先做遮挡处理，遮住姓名、手机号、令牌、域名和 IP；
3. 给团队约定：对外发布的图片必须经过一次检查；
4. 让 AI 看截图调试时，优先用已脱敏的版本。

五、一旦发现泄露：按顺序处理，别只删文件

很多人发现泄露后，第一反应是把文件删掉再提交一次。这不够，因为旧的提交记录还在，别人可能已经复制走了。正确的顺序是：

1. 第一步，立刻作废并更换密钥。 到对应的服务平台里，把泄露的密钥停用并重新生成。这一步优先于其他所有操作，因为只要旧密钥还有效，风险就还在。
2. 检查是否已被使用。 查看相关平台的访问日志、账单和异常调用记录，确认有没有陌生访问、陌生费用。
3. 清理仓库。 把仓库改为私有，必要时使用工具重写历史、移除含密钥的提交，并通知协作者重新拉取。
4. 排查影响范围。 泄露的是什么类型的信息，涉及哪些客户或系统，是否需要通知相关方。如果涉及个人信息，要按照合规要求处理。
5. 补上防线。 回头加上 .gitignore、提交前检查和仓库扫描，防止再次发生。
6. 复盘记录。 写清楚是怎么进的仓库、怎么发现的、怎么处理的，避免同类问题重复出现。

要点是：更换密钥必须放在第一步，清理历史只是补充。

六、团队落地：一页纸的规则

建议把下面这些内容整理成团队规则，新人入职时就看：

七、给做网站和小程序的企业的建议

如果你的官网、小程序或后台是外包开发的，也可以问开发方几个问题：代码仓库是谁在管、是否私有、密钥放在哪里、交付时是否会移交仓库和密钥清单、有没有提交前检查。这些问题不复杂，但能显著降低后期风险。

广州万户网络科技在交付官网、小程序和定制软件时，会把配置与密钥的管理方式写进交付说明，并在移交时一起核对。官网类项目 1280 元起，商城和定制开发 6800 元起，续费一般在 500 到 800 元每年，具体根据功能范围报价。如果你对现有项目的仓库安全不放心，可以先梳理一遍再决定是否需要整改。

结语

AI 让写代码变快了，也让“顺手把不该提交的东西提交了”变得更容易。真正有效的办法不是不用 AI，而是提前把规则定好：敏感文件进不了仓库，进了仓库会被拦住，泄露后能马上更换。把这三层做好，就能放心享受 AI 带来的效率。