智谱 ZCode 静默上传代码事件深度解读 2026：313MB 加密包撕开的 AI 编程工具数据边界
- 9/18 技术博主 ferstar 逆向发现：智谱 ZCode 桌面客户端在登录态下自动把工作区整体打包、加密并上传至阿里云 OSS；加密 RSA 公钥由服务端动态下发，私钥仅存云端
- 被曝上传面覆盖完整源码、Git 全历史（含已删除提交与 reflog）、LFS 缓存、全局开发配置、数据库口令、接口密钥、云凭证、个人信息——远超官方所称"代码片段"
- 9/20 太原承明科技发函追责，要求 10/10 前书面答复，并质疑是否数据出境；9/21 智谱宣布开源 ZCode 并邀信通院、绿盟科技审计，称涉事 OSS 桶已"云端零数据"
- 算数科技视角：这不是"某家厂商的意外"，而是AI 编程工具的数据出口缺乏可验证边界——采购与治理必须补齐"上传什么、谁能关、谁能验"三问
发布日期：2026-09-21 · 算数科技安全与治理研究组。适用读者：CTO / 安全负责人 / 研发效能与采购团队。
一、事件时间线：四天，从博客到法函
这起事件的推进速度，本身就是一次教科书式的"技术披露 → 企业追责 → 厂商整改与第三方审计"演进。按时间梳理：
| 时间 | 节点 | 关键内容 |
|---|---|---|
| 9/18 | 技术披露 | 技术博主 ferstar 发文：清理磁盘时发现 ZCode 目录占用异常，逆向出工作区快照打包 + 加密 + 上传阿里云 OSS 的链路 |
| 9/18 | 厂商首次回应 | 智谱致歉：争议源于代码库索引 / Repo Wiki 功能，生成 Wiki 页面时可能触发仓库数据上传，数据在生成完成后销毁；该功能上线初期默认开启 |
| 9/19 | 修复版本 | 推出修复版本（v3.14.0），移除 Repo Wiki 入口与相应生成链路 |
| 9/20 | 企业发函 | 太原承明科技发出承明〔2026〕法函字第 1 号特急函，提出十余项要求，保留索赔、向监管投诉举报与提起诉讼的权利 |
| 9/21 | 开源 + 审计 | 智谱宣布开源 ZCode 并邀请中国信通院、绿盟科技开展安全审计：信通院评测称涉事 zcode-prod OSS 桶为"云端零数据"；绿盟称桶内对象及桶本身已删除 |
注意一个细节：厂商"数据已销毁"的结论由第三方核查背书，这是本次事件处置中相对规范的一步；但企业真正关心的"我的数据有没有被用于训练""有没有出境"，在首轮核查口径里并未直接回答。
二、技术解剖：那个 313MB 的加密包是怎么来的
根据 ferstar 公布的逆向分析，触发点很日常：他在清理一台 256GB 的 MacBook Air 空间时，发现 ZCode 相关目录占用超过 700MB，其中一个约 313MB 的加密文件格外显眼。
进一步分析后，链路浮现为四步：
- 打包：在用户登录状态下，对工作区进行归档打包；
- 加密：使用 RSA 公钥加密，而该公钥由服务端动态下发，私钥仅保存在云端；
- 上传：通过阿里云 OSS 上传；
- 重试：上传失败进入本地重试队列。
这里面有两个非常有说明力的技术事实：
- 313MB 那份快照其实"没传上去"——因为体积过大，它连续失败 564 次，一直停留在本地重试队列里。换句话说，发现者是因为上传失败才在磁盘上"看见"了这个包；成功上传的包不会留下这么显眼的痕迹。
- 用较小的公开仓库做对照测试，确认了存在被服务器接受的快照上传——也就是说"上传能力"是真实生效的，不是纯理论风险。
第三个事实更关键：私钥只在服务端。这意味着即便企业在自己机器上截获了加密包，也无法独立解密自证自己到底被传走了什么。把"可验证性"交给被审计方，是这类设计的根本问题。
三、上传了什么：与隐私政策收集范围的对照
承明科技在法函中的说法与官方"代码片段"的表述存在明显落差。前者认为被上传的是结构完整的归档文件。我们按"数据类别 × 敏感度 × 治理归属"整理如下：
| 数据类别 | 具体内容 | 泄露后果 |
|---|---|---|
| 源代码与设计 | 项目完整源代码、系统架构设计 | 核心资产与竞争壁垒 |
| 版本控制历史 | 完整 Git 历史，含已删除的历史提交与 reflog | "删掉了就没了"的假设失效 |
| 依赖与缓存 | LFS 大文件缓存、全局开发配置文件 | 暴露工程结构与工具链 |
| 凭据与密钥 | 数据库口令、接口密钥、云服务凭证及证书 | 可直接被利用的入侵面 |
| 个人信息 | 员工及终端用户个人信息 | 触发个人信息保护合规责任 |
| 商业秘密 | 未公开的研发规划与商业计划 | 战略级商业风险 |
请特别注意第二行：reflog 与已删除提交。很多团队的安全习惯是"误提交密钥 → 赶紧删掉并重写历史"。但如果打包对象是把整个 Git 对象库作为回滚数据，那么历史里曾经存在过的敏感信息会一并被带走——这是"顺手删掉"类补救措施的失效场景。
四、三个设计缺陷：为什么"关掉开关"不管用
比"传了什么"更值得警惕的，是这套机制的产品设计。综合公开信息，至少有三个问题：
缺陷一：默认开启
官方承认该功能"上线初期默认开启"。安全默认值（secure by default）原则要求：涉及数据外发的功能应默认关闭，或至少在首次触发时给出显著、可拒绝、可追溯的告知。默认开启把决策成本转嫁给了不知情的用户。
缺陷二：界面开关与实际行为不对应
ferstar 的逆向结论指出，即便关闭与体验优化、仓库索引相关的选项，快照捕获与上传机制仍可能运行。这已经超出"配置繁琐"的范畴——它破坏了用户对"开关"这一基本契约的信任：用户在 UI 上做的选择，应当真实、完整地约束客户端行为，并可被独立验证。
缺陷三：私钥单边持有
公钥服务端下发、私钥仅存云端，用户无法解密本地包，也就无法审计"到底传走了什么"。对企业而言，这等于把数据流向的举证责任完全交给供应商。
五、机制对照：ZCode / Grok Build / Cursor
同类问题并非孤例。2026 年 7 月，xAI 的 Grok Build 就曾被曝在违背用户意愿的情况下上传代码库，据报道其打包范围覆盖所有文件，包括用户在对话中明确要求不要读取的文件；一个 12GB 测试项目在抓包中断时已确认上传体积超过 5GB，xAI 后续关停服务端上传并加入退出选项，马斯克公开承诺删除此前上传的数据。
把三者的机制放在一起对比，差异一目了然：
| 维度 | ZCode（本次） | Grok Build（2026-07） | Cursor（公开文档口径） |
|---|---|---|---|
| 上传对象 | 工作区快照，含完整 Git 对象库 | 整个项目打包 | 代码文件与语法片段 |
| 范围控制 | 忽略设置与实际上传不一致 | 未正确尊重排除项与隐私设置 | 文件变更时只同步对应分支与代码块 |
| 能否关闭 | 界面开关未真正阻断链路 | 后续补充退出选项 | 检查点保存在本地 |
| 可验证性 | 私钥云端独有，用户无法解密 | 靠第三方抓包才被发现 | 检查点独立于 Git、仅捕获被修改文件状态 |
结论：差别不在"是否上云"，而在三件事——上传范围能不能被约束、开关能不能真正关掉、行为能不能被独立验证。 以"回滚能力"为名上传完整 Git 对象库，是把一个可以本地解决的问题（检查点只存被改文件）做成了云端全量归档。
六、企业 72 小时自查清单（可直接执行）
如果你所在团队使用过 ZCode（或任何具备"仓库索引 / 代码库快照"能力的桌面 AI 编程工具），建议按下面的顺序做一轮排查。顺序很重要：先取证，再清理。
| 阶段 | 动作 | 判定线索 |
|---|---|---|
| ① 端点取证 | 统计 ZCode 目录占用，查找异常大的加密文件与重试队列 | 目录占用数百 MB～1GB 以上、存在孤立大体积加密包 |
| ② 网络取证 | 查 DNS / 代理日志中的外发域名与 OSS 出网记录 | 出现 zcode.z.ai、cdn-zcode.z.ai 等端点 |
| ③ 凭据轮换 | 假设相关仓库内的口令、密钥、云凭证、证书已进入风险面，立即轮换 | 优先级最高，不要等"确认是否上传成功" |
| ④ 历史排查 | 扫描 Git 历史与 reflog 中是否曾出现 .env、密钥、连接串 | 曾"删除过"的敏感提交尤其要查 |
| ⑤ 合规留痕 | 固定版本号、时间窗、抓包与日志证据，走内部安全事件流程 | 涉及个人信息时同步法务评估通报义务 |
| ⑥ 处置升级 | 升级到已移除上传链路的版本；向供应商索取数据删除证明与审计报告 | 要求书面、可追责的答复 |
第三行的凭据轮换是整张表里唯一"不必等结论"的动作。数据是否真的上传成功、是否被留存，往往需要供应商配合才能确认；而密钥泄露的处置窗口是按分钟计的。
七、行业含义：能力跑在治理前面的典型案例
把这起事件放回行业背景，它暴露的是能力与治理的错位：
- 动机层面：真实的工程结构、调试过程与业务逻辑，对模型后训练确有价值。但需要强调，目前没有证据表明本次事件中数据被用于模型训练——这恰恰说明"有没有被用"必须由可验证机制回答，而不是靠信任。
- 机制层面：AI 编程工具的"数据出口"已经从单一的"推理请求"扩展为索引、快照、检查点、遥测、插件/MCP、云存储多入口平面。任何一条链路的默认值失控，都会绕过此前基于"聊天内容"建立的合规假设。
- 治理层面：Agent 的数据行为缺少外部审计与出口声明。当一个工具会自主决定"打包什么、传到哪里"，企业需要的是可枚举的端点清单、可导出的外传日志、可关闭的链路，而不是一篇隐私政策。
还有一层容易被忽视的同意断层：点下"同意"按钮的往往是开发者个人，而承担数据泄露后果的是他的雇主和客户——后者从头到尾没有出现在任何同意流程里，也无从知道自己的代码曾被上传。这意味着企业级的授权与审计不能寄望于消费级弹窗，必须由采购合同与端点策略来补。
八、常见问题 FAQ
Q1：我把 ZCode 的索引/体验优化开关关掉了，就安全了吗？
按公开的逆向结论，不能这样假设。该机制被指在关闭部分相关选项后仍可能运行。应以供应商修复版本 + 网络侧验证为准。
Q2：313MB 那个包没上传成功，是不是等于没泄露？
那一个包确实因体积过大反复失败，但公开披露同时确认了存在被服务器接受的快照上传（用较小仓库对照测试）。所以"我没看到大包"不能推出"我没有数据外发"。
Q3：数据在 Wiki 生成后销毁，风险就没了吗？
"用完即销毁"是很有价值的承诺，但它需要满足三个条件才构成风险闭环：覆盖备份与衍生数据、可出具删除证明、可被第三方验证。首轮核查中"云端零数据 + 对象与桶已删除"的表述，方向是对的。
Q4：这类工具还能用吗？
可以，但要按数据分级来决定用法：核心算法与含密钥的仓库走私有化/内网推理；一般性、已开源的代码可评估云端工具；并且把忽略清单、端点策略、网络白名单作为前置条件，而不是事后补救。具体三道防线落地见 企业 AI 编程工具防外泄三道防线。
Q5：如果我是采购方，这次事件应该改哪几条合同？
至少要补：出口声明、留存与删除（含备份/衍生数据、删除证明）、训练使用与退出选项、审计权与日志导出、子处理者与插件清单、违约与数据迁移。条款模板与 12 条 RFP 见 AI Agent 数据行为审计与合同条款。
对照工具页：私有化与信创部署对比 →
算数科技观点
「AI 编程工具的安全边界，不写在隐私政策里，写在网络出口和开关的代码里。」 本次事件最有价值的启示，不是"某个工具不能用了"，而是让企业第一次具体地问出三个问题：它到底传走了什么、我能不能真的关掉、我能不能独立验证。 这三个问题答不上来的工具，就不该接触核心代码资产。
算数科技（上海思扬信息科技）11 年企业数字化与 16+ 平台渠道经验，提供 AI 编程工具的选型对比、私有化/信创部署、出口治理与合同条款评审支持。咨询 400-678-7857 / 18016313342（微信同号）。
九、延伸到技术层：为什么"代码索引"会变成"全量归档"
很多人第一反应是："索引仓库不是很正常吗？IDE 也要建索引。" 这恰恰是需要说清楚的地方——本地索引与云端归档是两件完全不同的事，被混为一谈才让风险被系统性低估。
| 对比项 | 本地代码索引（常见做法） | 云端仓库归档（本次争议） |
|---|---|---|
| 处理对象 | 符号、函数签名、语法片段、向量片段 | 整个仓库工作区（含版本库对象） |
| 数据形态 | 结构化索引，存于本机 | 打包归档（packfile 类） |
| 是否离开设备 | 默认不离开 | 上传至对象存储 |
| 可关闭性 | 关闭即停 | 界面开关与行为可能不一致 |
| 信息完整度 | 片段级，缺上下文 | 完整上下文 + 历史 + 配置 |
为什么"归档"比"索引"危险得多？关键在于版本控制系统的打包机制：一次仓库打包会把全部对象（含历史提交、已被删除的数据对象、引用日志）压缩进单一文件。这类压缩包体积小但信息完整——这也解释了为什么一个 313MB 的文件会引起开发者警觉：它说明压缩包内容远不止"当前分支的代码片段"。
更麻烦的是三个"隐形夹层"：
- LFS 大文件缓存：为版本控制准备的大文件（模型、数据集、安装包、设计稿）可能一并进入打包范围；
- reflog 与悬空对象：被
reset、rebase、commit --amend"甩掉"的提交，在垃圾回收前仍以对象形式存在； - 工作区未提交内容：包含开发者本地正在调试的配置、临时密钥文件与实验代码——这些从未进入过仓库，却最可能含有明文凭据。
换句话说，"我们没往仓库里提交密钥"这个说法，并不能推出"没有密钥外发"。工作区归档的边界是"目录里有什么"，而不是"仓库里提交了什么"。
十、企业最容易忽略的四类数据
| 类别 | 常见位置 | 后果与处置 |
|---|---|---|
| ① 本地环境文件 | .env、.env.local、config/*.local.* | 含明文口令与第三方密钥，必须轮换 |
| ② CI/CD 与云凭证 | .aws/、kubeconfig、部署脚本、.npmrc、.pypirc | 可直接导致云资源被接管，优先轮换 + 复核审计日志 |
| ③ 测试与生产数据样本 | fixtures、SQL dump、CSV 样例 | 常含真实个人信息，触发个人信息保护义务 |
| ④ 未公开的业务文档 | 技术方案、报价、客户名单、路线图 | 商业泄密，需评估合同与竞业影响 |
第四类经常被工程师忽略，因为"它不在代码里"。但工作区性质的上传不看文件类型——只要在目录内，就可能在打包范围内。
十一、自查方法：四个口径交叉验证
单看一个指标容易得出错误结论，建议四个口径一起看：
- 端点占用口径：检查客户端数据目录体积。
du -sh（macOS/Linux）或资源管理器（Windows）排查异常大的目录与孤立加密文件；对照"目录占用远超正常缓存"这一特征。 - 版本库口径：在关键仓库执行
git count-objects -vH查看对象库体积与松散对象数量；用git log --diff-filter=D --name-only找出曾被删除的文件，重点检查密钥与配置文件。 - 网络口径：在企业出口 DNS 日志、代理日志中检索客户端相关域名与对象存储出网记录。这一口径最难被客户端行为绕开，是验证"设置是否真的生效"的关键。
- 工作区口径：扫描未提交内容中的高敏模式（私钥头、连接串、token 前缀），这一层往往才是明文凭据最集中的地方。
四个口径的结论要交叉：端点有加密包但网络无出网记录，说明上传尝试失败（如本次 313MB 案例）；网络有出网记录但端点已清理，则必须以网络日志为准——这也是处置顺序上"先取证、再清理"的原因。
十二、常见误区（比技术细节更容易害人）
- 误区一："我关了开关。" 在设置与行为一致性未经验证前，开关不构成有效控制。
- 误区二："我把密钥从仓库删了。" 已删除的提交与 reflog 可能仍被打包带走，且工作区文件从未受"提交"约束。
- 误区三："我用的是个人账号，和公司无关。" 恰恰相反——用个人账号打开公司仓库，是企业最没有可见性的场景，且事故后果仍由雇主承担。
- 误区四："包很大没传上去，就没泄露。" 公开披露同时确认了较小仓库可被服务器接受，说明链路是通的。
- 误区五："厂商说数据销毁了，就不用轮换密钥。" 轮换的成本远低于假设错误的代价，且不必等结论。
十三、给研发效能团队的一条经验
把"AI 工具"当成新入职的远程外包工程师来管理，很多决策会立刻变清晰：他能否看到生产配置？能否读取客户数据？他在本地产生的临时文件归谁管？他每次读取了什么、发到了哪里，有没有日志？
这个类比的价值在于：企业对"人"早有一套权限与审计制度，而对"工具"却常常只凭一篇隐私政策就放行。把工具纳入既有权限模型，而不是为它新开一条豁免通道，是本次事件最重要的组织级启示。
十四、场景推演：同一个事件，三类企业三种后果
"代码被上传"在不同行业造成的后果差异极大。下面用三个典型场景说明为什么企业不能只依赖工具方的通用整改结论：
| 场景 | 最敏感的内容 | 主要后果 | 优先动作 |
|---|---|---|---|
| 金融 / 持牌机构 | 核心风控规则、交易逻辑、客户个人信息 | 合规报告义务、监管沟通、客户信任 | 凭据轮换 + 法务评估 + 监管口径确认 |
| 制造业 / 研发型 | 工艺参数、设备控制逻辑、供应商体系 | 技术秘密外流、供应链议价能力受损 | 技术秘密范围界定 + 竞对影响评估 |
| 互联网 / SaaS | 架构设计、增长策略、未发布功能 | 竞争窗口丧失、估值与融资叙事受影响 | 路线图影响评估 + 对外沟通口径 |
三类企业的共同点是："数据已删除"不能替代"影响已评估"。删除解决的是"未来还会不会继续外发"，而影响评估回答的是"过去这几天已经外发了什么、对谁有影响、需要向谁说明"。这两件事必须分开推进，且由不同角色负责——前者是 IT/安全，后者是法务/业务。
十五、供应商尽调：八个必须问清的问题
本次事件之后，AI 编程工具的选型尽调清单应当补上下面八问。建议要求书面答复，并作为合同附件：
- 产品在运行过程中会连接哪些域名与端点？清单是否会随版本变化？变化如何通知？
- 是否存在默认开启的数据外发功能？分别在哪些版本、哪些场景下触发？
- 除推理请求外，是否会上传工作区文件、版本库内容或索引快照？范围如何界定？
- 忽略清单 / 排除规则的配置项是什么？是否有独立验证手段确认其生效？
- 传输数据的加密方式是什么？密钥由谁持有？客户能否解密自查？
- 数据的留存期限与删除流程？能否出具删除证明？备份与衍生数据是否覆盖？
- 数据是否用于模型训练？退出机制如何生效、如何证明？
- 是否接受第三方安全审计？能否提供审计报告与可导出的传输日志？
这八问与后续的合同条款一一对应：尽调问的是"你实际怎么做"，合同写的是"你必须怎么做"。两者结合才能在事故发生时形成可追责的证据链。
十六、对低代码 / 私有化交付的连带启示
本次事件对采购低代码平台与私有化交付的企业同样有参考价值，因为两者的底层问题是同一个：当系统为了"理解你的数据"而需要把数据搬到一个你能控制的范围之外时，边界如何界定？
- AI 连接 / MCP 类能力的治理：低代码平台开放 AI 连接给第三方助手时，"哪些表单可读、哪些字段可写、日志在哪"应形成与本文同源的台账口径；
- 私有化交付的边界表述：合同中"数据不出域"必须写明哪些数据、不出哪个域、允许哪些例外（如许可证校验、更新检查）——笼统承诺在审计时无法验收；
- 索引与训练语料的隔离：若平台提供"用企业数据优化建议"之类的功能，应默认关闭，且明确与生产数据隔离。
算数科技在企业项目中的经验是：边界写得越具体，后期争议越少。一句"数据安全合规"对双方都没有约束力；一张列明端点、数据类别与留存期的附件，才是可执行的条款。
十七、术语速查：给非技术决策者的 12 个词
数据安全事件的沟通成本高，很大一部分来自术语。下表用于把技术语言翻译成管理语言，可直接用于向管理层或客户说明情况：
| 术语 | 通俗解释 | 为什么与管理相关 |
|---|---|---|
| 工作区 | 你电脑上这个项目文件夹的全部内容，含未提交的临时文件 | 范围大于"仓库"，容易漏管 |
| 代码库索引 | 为了让工具看懂代码而建立的结构化清单 | 本身不一定外发，但可能带出上下文 |
| 仓库快照 / 归档 | 把整个仓库打包成一个文件 | 信息完整度最高的形态，风险最大 |
| packfile | 版本控制的压缩打包格式，体积小但包含全部对象 | 解释了"小文件大泄露" |
| reflog | 本地操作日志，记录历史变更轨迹 | 可复原"已删除"的提交 |
| LFS | 用于存放版本控制中的大文件（模型、数据集） | 可能夹带非代码资产 |
| 检查点 | AI 修改前的文件备份，用于回滚 | 应本地保存，不应上传整库 |
| RSA 公钥/私钥 | 加密与解密的一对钥匙 | 私钥只在对方手里 = 你无法自查 |
| opt-out | 退出某项数据使用的开关 | 需确认默认状态与生效证明 |
| DLP | 数据防泄漏措施，用于发现并阻断外发 | 是发现手段，不是绝对防线 |
| 单独同意 | 针对特定事项专门取得的用户同意 | 出境场景的法定要求 |
| 删除证明 | 对方书面确认数据已彻底删除 | 索赔与向监管说明的关键证据 |
十八、怎么向管理层汇报这件事（一段可复用的口径）
事故沟通最容易犯两个错误：一是过度技术化，让决策层抓不到重点；二是轻描淡写，等真相浮现后失去信任。建议用"事实—影响—已做—待决"四段式，并把不确定的部分明确标出：
事实：某 AI 编程工具被公开披露存在自动上传工作区快照的机制，涉及范围可能包括源代码、版本历史与凭据。我们使用过该工具，覆盖 <X> 名开发者、<Y> 个仓库。
影响：已识别的高风险项是 <凭据/密钥>，正在评估对 <客户数据/个人信息> 的影响；公开信息显示涉事存储桶已被清空，但"是否曾被用于训练"暂无公开结论。
已做：已完成相关凭据轮换、版本升级、端点与网络取证，并固定了证据；已向供应商提出书面问询。
待决：是否需要向客户/监管说明，取决于影响评估结论，建议在 <N> 个工作日内给出判断。
这段口径的关键在于把"不确定"当成正常内容写进汇报。安全事件中，承认"暂时不知道"比给出过早结论更专业——后者一旦被推翻，代价是团队公信力。
十九、要点回顾与相关阅读
📋 十分钟速记
- 触发点：客户端在登录态自动打包上传工作区快照，单个加密包约 313MB
- 上传面：完整源码与架构、完整 Git 历史（含已删除提交与 reflog）、LFS 缓存、全局配置、数据库口令、接口密钥、云凭证、个人信息、商业计划
- 三个设计缺陷：默认开启、开关与行为不一致、私钥仅服务端持有
- 进展：9/18 致歉 → 9/19 v3.14.0 移除上传链路 → 9/20 企业法函 → 9/21 开源 + 信通院/绿盟审计
- 企业动作：先取证后清理、立即轮换凭据、四口径交叉自查（端点/版本库/网络/工作区）
相关阅读：
- 企业 AI 编程工具防外泄：插件层、网关层、模型层三道防线——本文的"怎么防"部分
- AI Agent 数据行为审计与合同条款——本文的"怎么追责"部分
- 私有化与信创部署对比 · 国产 AI 编程工具 20 维评测
资料来源：技术博主 ferstar 逆向报告与公开披露、智谱（2513.HK）9/18–9/21 三次公开回应、太原承明科技有限公司 承明〔2026〕法函字第 1 号、中国信息通信研究院与绿盟科技首轮核查结论、界面新闻/新浪财经/虎嗅/观察者网等公开报道。本文为技术与管理视角整理，不构成法律意见；具体责任认定以监管与司法结论为准。