这周中文技术社区讨论最多的安全事件，主角是一家头部大模型公司，但出问题的既不是模型也不是提示词注入。独立开发者 Ferstar 只是发现磁盘占用不太对劲，顺着查下去，牵出了一个值得整个编码智能体赛道记笔记的案例。
发生了什么
按其博客与多家媒体核实的时间线：登录状态下，Z.ai 旗下编码助手 ZCode 会静默打包用户整个工作区——不只是打开的文件，还包括完整的 .git 历史、LFS 资产缓存、reflog 与全局应用配置——加密后上传到阿里云对象存储。触发源是 Codebase Indexing 功能：它用于会话检查点、版本回滚与 Repo Wiki 生成，默认开启，没有用户开关，隐私政策中也未提及。
细节比结论更扎眼。一个 313MB 的商业项目加密包生成了 564 次上传尝试，全部失败，另有一个 15KB 的文件成功发出。有企业用户一度自述 6 个工作区被上传、内含数据库口令与员工个人信息，次日撤回称证据有误。更麻烦的是验证难题：上传的包用 Z.ai 后端持有的私钥加密，用户既打不开自己被收走的文件，也无法独立确认「已删除」是不是真的。
Z.ai 的响应，教科书在哪里
平心而论，这家公司的善后动作密度不低：ZCode v3.14.0 移除 Repo Wiki 入口与快照上传工作流；删除涉事的 zcode-prod 存储桶，安全厂商绿盟 NSFOCUS 确认桶与数据对象均已删除；请中国信通院与绿盟做独立评估；开启零数据保留；声明相关数据从未用于模型训练；把客户端代码开源供社区审查；承诺建立持续的产品漏洞报告响应机制，并按严重度向报告者发放奖励。
但透明化也有边界。独立评估的完整报告截至发稿尚未公开，用户对加密黑箱的质疑只能靠「评估已确认」来背书——信任重建的最后一步，要等报告全文落地才算走完。
背景板：不是孤立事件
放在更大的背景里看，这是中国头部大模型公司少有的公开安全事件披露。Z.ai（智谱）上个月刚因安全评审推迟了两周发布 GLM-5.3，成为明确为此推迟发版的国内实验室；中国网信部门近期也更新了 AI 安全框架，点名关机抗拒、评估欺骗与沙箱逃逸等风险。监管、社区、厂商三方在这起事件里同时在场，这个组合本身值得记录。
对企业用户的现实建议
在评估报告全文公开之前，使用这类编码助手的团队不必等答案，有几件事现在就能做：把 AI 编码工具当成能碰专有代码的普通软件来审——隔离环境先跑、盯出站流量、限制密钥与敏感目录的可见范围；核对工具的数据留存与外传条款，确认与自家合规要求匹配；关注版本更新日志里对数据流的改动，而不是只看功能清单。eSecurity Planet 的建议与此一致：修复移除了被报告的上传工作流，但组织仍需独立验证后续版本的行为。
三层教训，都不新，但都常犯
Semgrep 的安全倡导者 Cris Thomas 的判断一针见血：这不是 AI 模型问题，是老式的安全架构问题——访问与权限怎么执行的问题。拆开看三层：默认权限应该是最小集而不是最大集，「功能有用」与「默认全开」之间必须隔着用户知情这一步；数据离开本机、去了哪里、留存多久、谁能访问，要在隐私政策里先说清楚；删除要说得起「可验证」，让用户能自己确认，而不是听厂商宣布。编码智能体天然需要大范围的工作区访问才有用，这个张力是结构性的——所以每家厂商都该自问：我的「Codebase Indexing」此刻在干什么。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。