智谱ZCode静默上传Git历史 代码外传风险与防护

一、事件回顾：默认开启的“代码库索引”

2026年9月18日，国内AI编程工具ZCode陷入信任危机。技术博主ferstar在清理本机配置目录时发现，ZCode登录后会在后台把整个工作区打包上传，其中包含完整的Git历史、LFS缓存、reflog操作记录与本地配置，加密后直传云端对象存储。文章发布后迅速在开发者社区扩散，并登上知乎热榜首位，讨论量超过五百万。

当天，智谱在官方社群中作出回应并致歉。官方解释称，相关行为源于ZCode的“代码库索引”功能，该功能用于在本地生成仓库索引，以支持历史版本回退、会话检查点恢复和Repo Wiki等能力；Wiki页面在云端生成后上传数据会立即销毁，不会保存。由于该功能上线初期默认开启，部分用户受到影响，问题目前已修复。作为补救，官方承诺近期开源ZCode代码库、邀请第三方评估人员审查，并为全体用户发放一次周额度重置。

二、技术复盘：全量快照为何更危险

社区复现的细节比官方解释更值得关注。ferstar通过本地取证与逆向分析还原了完整上传链路：ZCode会在提交提示词前或任务结束时，把工作区打成一个基线快照，其中一份样本包含42411个文件，.git目录占比高达86.6%，其中LFS缓存占56.8%、objects占29.6%、reflog占0.2%。

加密方式采用信封加密：先用对称密钥加密数据包，再用RSA-OAEP公钥包裹该对称密钥，公钥由服务端在下发上传凭证时提供，对应的私钥只存放在云端。用户即使抓到自己的上传包，也无法解开。开发者在社区Issue中提出的质疑很尖锐——上传范围为什么是“全部”而不是“当前任务上下文”，那些早就从代码里删掉的敏感配置、废弃的旧密钥、内部GitLab地址，是否也一并被带走。

更关键的分歧在于可验证性。官方称数据在Wiki生成后立即销毁，但解密私钥只由服务端持有，上传内容是否留存、何时删除，用户既无法自行验证，也无法通过关闭设置来终止行为——争议中一个细节是，该机制并不受遥测与索引开关控制。安全决策不能建立在厂商自证之上：没有可审计的客户端、没有透明的数据流向说明，任何“已删除”的承诺都无法被复核。这也是官方承诺开源客户端与引入第三方审查最被看重的部分，信任修复的关键不是道歉，而是把可验证性交还给用户。

三、自查与处置：四步走

对已经安装过ZCode的开发机，建议按以下顺序自查：第一步，检查本地残留目录 ~/.zcode/v2/checkpoints，查看快照体积、文件数量与生成时间，确认工作区是否被整体打包；第二步，在网关、代理或主机防火墙上回看出站流量，重点找对象存储域名的PutObject类请求，判断是否存在未经业务授权的大体量上传；第三步，核对代码仓库中曾经存在过的密钥、令牌与内网地址，凡是被提交过哪怕一次的内容，一律视为已泄露，直接轮换而非删除；第四步，保留审计日志，为后续追责或合规说明留证据。

处置层面，社区给出的临时手段是把 ~/.zcode/v2/checkpoints 目录设为不可写，例如用文件系统不可变属性锁定，代价是检查点回滚与时间线功能失效。更稳妥的做法是把AI编程工具放进隔离环境：使用独立账号与最小权限，禁止其在生产代码仓库上直接运行，凭据通过环境注入而非写入项目文件，源码目录内不存放任何真实密钥。

四、对青海政企的落地建议

这起事件的教训并不局限于个人开发者。省内不少软件企业、系统集成商和政企信息中心已经把AI编程助手纳入日常开发流程，而源码往往承载着业务逻辑、密钥体系和内网拓扑，属于核心资产。建议从三方面着手：一是建立AI开发工具清单与准入审批，明确谁在用、什么版本、数据流向哪里，采购前要求供应商书面说明上传范围、加密方式与留存期限；二是把“数据不出内网”写进工具选型与外包合同条款，涉及政府项目与关基业务时优先选择可私有化部署或可离线运行的方案，并在合同中约定违规传输的违约责任；三是对外传输路径做技术兜底，通过出口白名单、代码仓库密钥扫描与日志留存（不少于六个月）形成闭环，把等保2.0中数据安全与访问控制的要求真正落到工具层面。

对安全从业者而言，这又是一次提醒：AI工具的便利与代码资产的边界必须提前划清。工具可以换，泄露的密钥和内部信息换不回来。