- ZCode 静默上传代码：9/18 技术博主逆向披露智谱 ZCode 在登录态自动打包上传工作区快照（单个加密包约 313MB），上传面含完整 Git 历史、reflog、凭据与个人信息；加密私钥仅存服务端
- 企业发函追责：9/20 太原承明科技发出承明〔2026〕法函字第 1 号，要求 10/10 前书面答复，并质疑数据是否跨境（英文协议主体为新加坡公司，中文协议主体为北京主体）
- 厂商三次回应：9/18 致歉（默认开启、用完即销毁）→ 9/19 推出 v3.14.0 移除 Repo Wiki 链路 → 9/21 宣布开源 ZCode 并邀中国信通院、绿盟科技审计
- 算数科技判断：AI 编程工具的安全评估重心，将从"聊天内容是否上传"转向索引/快照/检查点等衍生数据出口；采购侧应把出口声明、外传日志与删除证明写进合同
一、ZCode 事件：四天走完"披露→追责→审计"
本周最受关注的行业事件，是智谱旗下桌面 AI 编程工具 ZCode 的代码库上传争议。据公开报道与逆向分析，ZCode 客户端在用户登录状态下存在一套工作区快照机制：对工作区打包、加密，并经由阿里云 OSS 上传；加密所用 RSA 公钥由服务端动态下发，私钥仅保存在云端，用户无法自行解密。
触发披露的细节颇具戏剧性：技术博主 ferstar 在清理一台 256GB 设备的磁盘空间时，发现 ZCode 目录占用超过 700MB，其中一个约 313MB 的加密文件引起注意。该文件因体积过大连续失败 564 次，一直停留在本地重试队列；而他用规模较小的公开仓库做对照测试，确认存在被服务器接受的快照上传。
据披露，被上传范围远超官方所称的"代码片段"，可能包含项目完整源代码与系统架构设计、完整的版本控制历史（含已删除的历史提交与 reflog）、LFS 大文件缓存、全局开发配置文件，以及数据库口令、接口密钥、云服务凭证与证书、员工及终端用户个人信息、未公开的研发规划与商业计划。
二、企业发函：诉求清单几乎是一份事故应对模板
9 月 20 日，太原承明科技有限公司向北京智谱华章科技股份有限公司发出编号为"承明〔2026〕法函字第 1 号"的特急函，就客户端"擅自上传本公司数据资产及商业秘密"提出十余项要求，并保留索赔、向监管投诉举报与提起诉讼的权利。其核心诉求包括：
- 彻底删除已上传的全部数据及衍生数据、缓存、备份，并出具证明；
- 说明数据去向、是否共享第三方、是否用于训练、是否跨境；
- 公开私钥保管方式与访问、下载记录；
- 于 10 月 10 日前书面答复。
其中"是否跨境"是本轮新增的合规焦点。据报道，ZCode 客户端请求指向 zcode.z.ai 与 cdn-zcode.z.ai，而 Z.AI 平台的缔约主体及个人数据控制者为注册于新加坡的 JINGSHENG HENGXING TECHNOLOGY PTE.LTD（据智谱招股书，为 2023 年 11 月在新加坡注册的间接全资子公司），其隐私政策载明服务与数据处理"通常在新加坡"。与此同时，中文版用户协议与隐私政策规定的服务提供方与数据处理者则是"北京智谱华章"，并称境内收集的个人信息存储于中国境内、不会跨境传输或存储。
两套表述并存，正是合规审查最需要打通的地方：用户以为签约与处理主体在境内，实际数据可能由境外主体处理。若确属出境，依据《个人信息保护法》需满足第三十八条（安全评估／保护认证／标准合同三选一）并履行第三十九条的告知与单独同意义务。
三、厂商回应与第三方核查结论
| 时间 | 回应 | 要点 |
|---|---|---|
| 9/18 | 首次致歉 | 争议源于代码库索引功能（用于本地索引、会话检查点恢复、Repo Wiki）；生成 Repo Wiki 时可能触发仓库数据上传，生成完成后数据即销毁；该功能上线初期默认开启 |
| 9/19 | 修复版本 | 推出修复版本，移除 Repo Wiki 功能，切断本地仓库快照生成与上传链路 |
| 9/21 | 开源 + 第三方审计 | 正式将 ZCode 开源至 GitHub 接受社区监督；邀请中国信通院与绿盟科技开展安全审计；并表示将上线"数据内容不留存"功能 |
据 9/21 公开报道的首轮核查结论：中国信通院技术评测确认涉事的 zcode-prod 阿里云 OSS 存储桶（独立分区）当前处于"云端零数据"状态；绿盟科技审查结果显示该存储桶内全部数据对象及存储桶本身已删除，更新后的 v3.14.0 客户端已完成整改，Repo Wiki 入口及相应生成链路已移除，未发现可触发本地仓库快照或文件外发的功能路径。
仍需注意两点：其一，"数据已删除"与"是否曾被用于训练"是两个问题，公开报道中未见前者可以推出后者的结论；其二，第三方核查覆盖的是存储桶与客户端当前版本，企业侧若要确认自身历史影响面，仍需结合端点与网络日志自查。
四、行业面：同类机制并非孤例
此类争议在行业内并非首次。2026 年 7 月，xAI 的 Grok Build 曾被曝在违背用户意愿的情况下将代码库上传至云端，据报道其上传范围覆盖所有文件，包括用户在对话中明确要求不要读取的文件；在一个 12GB 的测试项目中，截至抓包中断时已确认上传体积超过 5GB，后续 xAI 关停服务端上传并加入退出选项。
与之形成对照的是公开文档中更为收敛的设计：有工具在做语义索引时主要处理代码文件与语法片段，文件变更时只同步对应分支与代码块；其 Agent 检查点保存在本地、独立于 Git，仅捕获被修改文件的状态，而不是把完整 Git 对象库作为回滚数据上传云端。
同样值得纳入观察的还有供应链侧风险：连接到 Agent 上的 MCP 服务器、插件、遥测服务、日志系统、模型供应商与云存储，每增加一个外部组件，数据就进入一套新的权限体系。
五、算数科技行动建议（三件事）
- ① 72 小时内完成端点与网络自查：统计客户端目录占用与异常加密包、检查外发域名与出网记录；无论结论如何，先轮换相关仓库中的口令、密钥、云凭证与证书——处置窗口按分钟计。清单见 事件深度解读。
- ② 把六个数据出口画成一张表：推理请求、索引/快照、检查点、遥测、插件/MCP、云存储，逐项标注"传输目的地／能否关闭／日志在哪"，再按插件层→网关层→模型层逐层收口。方案见 三道防线落地指南。
- ③ 采购与合同补齐六类数据行为条款：出口声明、留存与删除（含删除证明）、训练与退出、审计权与日志、子处理者/插件清单、违约与数据迁移；涉出境场景核对 PIPL 第 38/39 条。条款与 12 条 RFP 见 AI Agent 数据行为审计与合同条款。
六、标准与监管锚点
| 文件 | 状态 |
|---|---|
| 《代码大模型安全风险防范能力要求及评估方法》（中国信通院 / AIIA，近 30 家单位编制） | 2024 年 6 月定稿，已启动首轮试评估 |
| 国家标准计划《网络安全技术 人工智能代码生成服务安全要求》（20262852-T-469，TC260 归口） | 2026-05-22 下达，正在起草 |
| T/TAF 351-2026《基于生成式人工智能的代码生成产品和服务质量技术要求》 | 2026-06-17 发布并实施 |
| T/EJCCCSE 633-2026《智能代码生成智能模型安全技术规范》 | 2026-05-15 发布并实施 |
这些文件目前可作为选型与验收的客观锚点：让供应商逐条说明符合性，而不是笼统回答"符合国家相关标准"。
算数科技观点
「这次事件不是某个工具的安全故障，而是整个品类缺乏可验证数据边界。」 当 AI 编程工具为了"理解仓库"而自主决定打包什么、传到哪里，企业真正需要的是可枚举的端点、可导出的日志、可关闭的链路——而不是一篇隐私政策。判断标准很简单：它传走了什么、我能不能真的关掉、我能不能独立验证。
算数科技（上海思扬信息科技）11 年企业数字化与 16+ 平台渠道经验，提供 AI 编程工具选型对比、出口治理、私有化/信创部署与合同条款评审支持。咨询 400-678-7857 / 18016313342（微信同号）。
监控周期：2026 年 9 月 14 日 – 9 月 21 日 · 本文由算数科技竞品情报组整理；趋势判断基于公开报道与厂商声明，不构成投资或法律建议。转载请注明出处 micount.cn。