ARTICLE · 1125195
ZCode风波之后,你有做AI编码工具数据边界自查吗?
ZCode风波之后,你有做AI编码工具数据边界自查吗?ZCode 风波有触动你吗 9月18日上午，V2EX上出现一个帖子，标题原样是「有用 zcode 的，马上关闭！它打包上传了你整个代码库！」。楼主说自己亲自验证过，Windows 和 Mac 两台机器都中招。同一天傍晚五点四十四分，智谱在 ZCode 官方用户群发了致歉说明。第二天 v3.14.0 发布，更新日志里写着"修复仓库百科异常上传的问题"，不到两天ZCode开源了一个阉割版本，但是市场并不买账。 
在媒体报道中，ZCode最受争议之处，在于相关功能被指默认开启，客户端没有独立、明显的关闭选项，用户也无法自行查看或解密已生成的数据包，用户对数据处理既缺乏充分知情，也难以有效管理。从产品实现看，为保障任务效果，上传部分代码数据或许确有必要，但技术需要不能等同于无限制授权。上传哪些文件、作何用途、保存多久、是否进入其他系统、如何删除，都应在功能启用前明确告知。 十六天，从爆料到道歉到修复到开源，一个完整的危机周期跑完。中间股价先涨 1.79%，再跌 6.55%，再跌 12.4%，三个交易日累计跌掉逾 16%。 很多人觉得事情到这儿基本收尾，但其实这件事之前有grok数据收集的先例，后面有大佬反馈Trae也有类似行为，我们不能再把数据安全威胁的发现寄托于其他人的爆料。 
我们需要对自己的数据安全负责，作者千里也可以为各位朋友提供技术支持。在此基础之上，给大家分享一下，如何对你机器上正在跑的任何 AI 编码工具进行文件访问行为监控。 最佳示范 最好的示范来自于实战，最早那位对ZCode进行技术分析的师傅，来自一位自费买了Coding Plan的一线工程师，博客ferstar.org，9月18日上午发出，在他的报告里面，他没有停留在"我觉得它在上传"，而是把整条链路拆开进行分析。 参考：https://blog.ferstar.org/posts/zcode-silent-workspace-snapshot-upload/ 涉事版本是9月17日发布的v3.12.3，客户端先请求 在他的观测中，有 42411 个文件被打包，其中 后来V2EX上有人（t/1243017）逆向了这套加密规范，自己生成一对公私钥塞进 ZCode，成功解开了那个 
不止一家 7月10日，安全研究者cereblab 公布了 Grok Build CLI 0.2.93 的 wire-level 抓包结果。这个工具会把整个仓库静默上传到 Google Cloud Storage 的一个桶里，桶名 
同一个月，AIR Security 披露了一个叫 Plugin4Shell 的问题，影响面覆盖 Claude Code、OpenAI Codex、GitHub Copilot 和 Gemini CLI：插件在 checkout 到指定 commit 之后不再二次校验工作目录里的代码。四家的处理各不相同，Claude Code 在 2.1.179 修了，Codex 在 0.146.0 修了，Copilot 当时还没动，Google 的答复是 Gemini CLI 已弃用、不修。 
放在一起看，这已经超出某家公司的道德问题。AI 编码工具要工作就得上传上下文，把你正在编辑的文件发出去是功能必需，把整个工作区连历史一起打包传走就变味了，而事实上在代码里可能只是一个配置项的差别，结果就咫尺天涯了。 那么这种情况，边界由代码决定，不由声明决定，而且声明会随版本变，现在合规不代表明天还存在良心，现在没良心没被发现明天也可能悄悄伪装起来，我们该怎么做呢？ 所以，我经常提倡，要做“有兜底的安全”，我们现在最大的问题是看不到、分不清被盗取数据的行为。 有没有思考，电脑上EDR等主机类产品为什么不进行干涉呢？ 为什么谁都不来兜底 针对这个问题，我的结论如下： 首先，当前检测范式是错位的。现在的EDR、NDR基本都是特征匹配，靠已知的恶意样本和攻击模式。AI Agent读文件这个动作，在系统看来就是一个受信任进程在做正常的系统调用，没有什么异常特征，因为这个动作本身完全正常，出问题的是它触及的范围，而范围是策略问题，不能贸然说读敏感文件就是恶意软件，恶意软件引擎里肯定没有这个概念，不然可能误报特别多。就比如，你见过「ssh端口被登录」这种告警吗，不是没能力，是这种告警没价值。 再者，就是身份体系的坍塌。我们平时分析进程是否是恶意的，都会去看进程身份，做安全默认一个前提，进程身份约等于人身份，谁有权限出了事就找谁。AI Agent因为拿的是真人的token、真人的权限，它凭借真人身份开展内部行动。现有产品体系里尚没有"一个非人主体在你的身份里做事"这个类别，又怎么去分辨当前行为是AI还是真人呢？ 然后就是DLP也陷入自相矛盾的境地。数据防泄漏的立身之本是确保敏感数据不该流出去，AI Agent的立身之本是把数据发出去才能换回智能分析的结果。如果企业同时买了两者，DLP就陷入了尴尬的境地，所以厂商很少会去直接关注AI Agent的风险，只有防守方自己才有权力做这件事。 再深一层就是观测上的纰漏。因为agent的流量是到模型厂商的TLS，网络层看到的是到一家合法SaaS的密文，端点层看到的是一个受信任进程，它正好卡在两个产品品类的盲区中间，两边都没办法进行监测。 最后是驱动力。等保、PCI、HIPAA 里都没有"AI 助手的文件访问要审计"这一条，监管不问、审计不要，很多公司的安全预算里就没有这项，厂商“作恶”也会非常小，出了事厂商说是用户配置问题，用户说是产品缺陷，最后只可能是一场闹剧收尾，比如智谱这次的事件，并没有看到监管部门下场来进行干涉。 因此，千里在这里提出的方案，是参考蜜罐的思路，利用蜜饵文件来做主动防御，如果本地EDR、DLP支持规则定制或者插件，那可以直接关联相关能力，也可独立部署进行监控。最终只有一个目标，那就是“有兜底的安全”。 方案介绍 
先说蜜饵这个思路的支点。一个蜜饵文件跟普通文件唯一的区别是它没有合法的读者，配置会被程序读、代码会被编辑器读，而蜜饵从放进目录那一刻起就不该被任何正常流程碰。所以任何一次读取都是纯信号，零误报。你不需要去定义"什么算 AI 的异常行为"，只要定义"一个永远不该被打开的文件"，定义不变量比定义变量容易得多。服务拆成投放、观测、归因三段，链路可以参考上图。 首先，在投放层面，要挑agent会主动去翻的那些，比如.env、id_rsa、config/database.yml 、云厂商的凭据文件，每个文件里埋一段全局唯一的字符串，这样万一它出现在出口流量里，便于能反查是哪个文件、什么时候被谁带走的。一个位置只需要一个蜜饵文件就可以了，当然按照蜜罐的思路，可以布置多种类型的文件，但AI agent和勒索病毒有一定区别，比如他去ssh目录下就是寻找ssh key，别的文件可能也不会被获取。 链路中，最最关键和耗费精力的是观测，难在两点，既要拿到"读"这个动作，还要知道是谁读的。要知道，文件被创建、被修改，哪个平台都好抓，但是被读取是没办法同日而语的。比如Linux，它上面inotify的IN_ACCESS无法用来判断，它依赖atime，很多文件系统根本不触发，而且不给进程号，要带PID的读取事件得通过fanotify+FAN_REPORT_PIDFD，或者用eBPF挂载sys_enter_openat或LSM 钩子上，才能进行实现。而macOS，通过FSEvents只能获取读取路径，却无法获取进程，因为进程归属要靠 EndpointSecurity 框架的 NOTIFY_OPEN 事件，得有签名和root才能实现，临时排查可以用fs_usage来实现，但没法常驻。Windows的ReadDirectoryChangesW同样没有进程号，最终我这边的做法是ETW 的Microsoft-Windows-Kernel-File提供者或者写 minifilter驱动。 归因就是最后要锁定是谁读的，因为AI Agent是拿真人的权限运行的，系统看来它和真人操作没有区别，光有PID并不能说明什么，因此需要基于进程树，看这个PID的父链最后是不是落到某个AI工具上，比如，Linux可以使用cgroup轻松实现，当时Grok取证的人就是靠 cgroup 指向一个旧的 tmux 会话，才把异常进程和 always-approve 的 AI 助手对上号的，这个手法可以直接搬过来。 理论成立，那就开始行动！ 准备抓包环境与蜜饵文件 验证的入口是看流量，因为mitmproxy 免费、跨平台，命令行界面在这个场景下够用，所以我就使用这个了。 HTTPS抓包的原理很简单，大家平时用Burp Suite或者Yakit就会很容易明白，让工具的流量走你本机的代理，代理给流量重新签发证书，你就能在代理界面里看到明文。前提就是把代理的根证书装进系统信任区。 但是如果工具做了证书固定，只信任自己内置的那张证书，可能代理就拦不住它，请求直接失败。不过消费级编码工具很少这么做，真遇上了，可能需要去逆向或者其他方式了。 接着是蜜饵文件，文件内容应当从头编造，避免直接复制生产配置，因为即使改掉了密码，里面的内部地址、账号和项目关系也可能仍然有价值。最简单的观察办法，是生成一串随机字符，写进测试文件： 这串字符相当于给数据做了一个记号，后面如果在请求正文里发现它，就能追到对应的测试文件，常把这种标记叫金丝雀，不过，单独一个 canary.txt能覆盖的情况有限，因为真实项目里，工具更可能遇到的是 .env、数据库配置、包管理器认证文件，或者放在普通备份目录里的账号材料。 所以我在我的蜜饵监控项目里准备了九种假文件，尽量沿用这些文件常见的格式，分布在根目录、子目录和备份目录里，每份都带独立标记。给工具的任务也要明确，比如解释某个函数，或者修复一个只涉及单个文件的错误，这样才容易对照任务需要，判断它有没有读取无关内容。如果一开始就要求它“把整个目录都看一遍”，后面再讨论读取是否超出预期，就会含糊很多。 正式执行前，最好先留一段工具尚未启动时的记录，看看环境里本来就有哪些文件访问。编辑器索引、杀毒软件和备份程序也可能碰到这些假文件，如果不先了解背景活动，监控一响，大概率都是误报。 一旦出现蜜饵被读取，就可以出发检查动作了。 核对文件访问和网络请求 关于这两个层面的分析，文件侧聚焦访问时间、文件路径和进程，网络侧聚焦目标地址、请求内容和接收结果。例如，假的.env文件在14:03:12出现访问记录，随后某个请求正文里带上了它的独有标记，如果还能把请求对应到编码工具的进程，并看到服务端接收结果，就能比较具体地还原这份内容的流转过程。 相比之下，“后台突然多了几兆异常流量”或者“连上了一个陌生域名”，只能提供排查方向。更新、登录、错误上报都可能产生这些现象，必须继续看请求内容和触发条件。 抓包中，即使已经解开 HTTPS，请求体里面可能有另一层应用自行加密的压缩包，那金丝雀文件的特征还是没办法搜索到，因为压缩、编码、应用层加密，以及没有经过代理的连接，都会影响观察结果。因此，搜索到笔记只能算作上传文件的充分条件，没搜到标记不能直接作为“没有上传”的结论，必要时还得结合本地临时文件、上传接口和打包逻辑来进行关联分析。 案例Demo 为了观察任务如何被带偏，我在本地搭了一个能读文件、也能调用发送工具的最小助手。给它的要求只是总结一份供应商资料，但资料里夹了额外指令，诱导它读取假凭据，再调用 send_external。测试目录旁边放着9个蜜饵文件，用来记录它实际访问了哪些内容。已有实验记录中，这次运行用了 25.4 秒，完成了四次工具调用： 我解释一下这其中具体工具调用动作，send_external实际只把目标地址和待发送内容写进本地outbox.jsonl，没有向公网发送，所以这次验证的是助手有没有被文档里的指令影响，以及有没有把假凭据交给发送工具。 这条记录中，我最在意的是读取 .env 和 database.yml 的那两步，我作为用户要求总结供应商资料，凭据文件原本不属于任务范围，助手却因为资料里的文字转头去读了它们。如果没有展开工具调用记录，其实是没办法发现的。 然后，我在监控侧抓到了两次蜜饵读取，并且金丝雀标记也出现在本地模拟出口记录中，因此我们能把本轮的读取和模拟发送对应起来。 最后得出结论，此次打造的AI Agent Demo成功触犯了数据安全底线，而且成功被我们获取。 从“文件被读过”到“确认是谁读的”，有无技术gap 前面也提过，实际做监控时，比较费事的往往是归因。我们在无特权监控里用文件访问时间，也就是atime，作为观察线索，却发现同一个文件重复读取时，访问时间未必跟着更新。探针第一次有反应，第二次可能就没有变化，如果不先验证这个行为，很容易把探针没有报警理解成文件没有被碰过。 为此，这套实现会在记录事件后，把专用蜜饵的访问时间往回调，让后续访问能继续被观察到。这样做会改动元数据，因此只用在专门生成的假文件上，不拿真实业务文件来做；换了机器或者文件系统，也需要先验证探针是否有效。使用这种方式以后，复盘主要依赖保存下来的事件日志，不能再把经过修改的文件时间戳当成原始访问记录。 有了访问线索，接下来才是找进程。如果能捕获进程对文件的实际读取，那就直接破案，但是如果只看到某个进程持有文件句柄，还要结合读事件判断，因为打开文件不等于已经读取了内容。有些进程存活时间很短，查询时已经退出，就只能通过前后进程快照、命令行、工作目录和父子进程关系缩小范围。 如果实在找不到怎么办，那就在当前能做到的告警粒度里面，把依据和不确定的地方写出来，尤其是暂时对不上的部分，然后基于这个层面继续分析是补文件审计的能力，还是补网络观测的能力。 因此，针对AI数据安全，我倡议能携手同行，一起对更多的AI Agent工具、AI使用场景来进行监控，真正实现AI安全自治。 查完之后，权限该怎么收 实验最终要落实到日常使用，我们该如何进行整治呢？ 如果只需要处理一个项目，就尽量只让它访问这个项目，主目录里的 SSH 密钥、云账号配置和其他客户材料，没有必要一起交给它。对陌生仓库尤其要谨慎，涉及安装依赖、执行脚本时，优先放进隔离的测试环境，只挂载需要的文件，避免为了省一次配置，把整个用户目录和真实凭据都带进去。 网络出口也要和文件权限一起检查。先摸清正常工作需要访问的地址，对新增连接保留记录、按需限制，同时覆盖工具启动的辅助进程和命令行程序。如果只管住桌面应用的主进程，子进程仍能任意出网，限制就可能落空。另一方面，敏感内容也可能通过本来就允许访问的模型 API 发出去，因此域名白名单只能解决一部分问题，仍然需要从源头限制工具能读到哪些内容。 还有一个常被忽略的环节是更新。版本、插件或索引功能发生变化以后，原来的测试结论未必还能覆盖当前行为，所以每次测试都应保留版本、配置、任务和实际观察记录，方便后续对照。个人可以先拿最常用的工具做一轮小测试，企业则需要把它纳入准入和变更检查，避免拿半年前的评估结果替今天的版本作答。 采购和评估时，问题也可以问得更具体：默认上传哪些内容，排除规则实际约束哪些功能，服务端保存多久，哪些角色有解密权限，删除是否覆盖副本和备份。如果已经发生上传，还要继续追查历史数据的去向，仅凭“现在存储桶为空”，不足以回答此前有没有被读取、复制或备份，这些仍需要相应的历史日志和数据流转记录来说明。 总结 AI 工具的安全评估、企业网络的安全建设、中小公司的日常安全托管，这块我们都比较拿手，如果你的团队正在评估是否使用AI编码工具，或者已经使用了但不清楚它们在内网里做什么，或者想获取demo代码在本地自测，可以联系我提供前期建议或者深入服务，扫描下方的飞书群聊二维码进行沟通。 感谢少侠们的关注和支持。 
/api/v1/snapshot/upload-credential拿一份上传凭证，把仓库打包，用AES-256-CTR加密内容，再用RSA-OAEP-SHA256做信封加密，最后通过PostObject直传阿里云 OSS，传完还有一个callback确认。RSA的私钥只存在云端，用户手上没有，客户端本体也没有，也就是说这个包在我们自己的机器上是解不开的。.git目录占86.6%，光是LFS缓存就占56.8%，真正的源码和文档只占13.4%。让人绝望的是，把"优化体验"和"仓库快照索引"两个选项都关掉，v3.12.3 后台照样打包，照样尝试直传。tar.gz.enc。里面是全量的 .git 数据，还带着触发这次操作时输入的提示词全文。grok-code-session-traces，内容包含 .env 里的密钥和完整的 git 历史，客户端没有做任何脱敏。xAI 的反应是连夜把 Grok Build 开源，但媒体报道说那 84 万行代码里仍然留着上传的痕迹。opensslrand-hex 32 > canary.txt读供应商资料→ 读 .env→ 读 database.yml→ 调用 send_external