最近一周开发群里聊得最多的不是某个新框架发布而是智谱ZCode的“偷传代码”风波。ZCode本质上是一个具备代码补全、项目理解和自动执行能力的Agent式AI编程助手它接入DeepSeek等多个模型支持日常补全和终端命令执行。但问题恰恰出在“能力太强”上有开发者用抓包工具和文件监控日志发现它在本地上传了与当前项目无关的文件内容甚至出现了疑似读取用户目录、SSH密钥目录的行为。网络上“扫盘”“偷代码”的说法一出来整个AI辅助编程圈子的情绪一下就起来了。这不是一个可以简单站队“谁对谁错”的问题。作为经常被团队拉去帮做安全评估的开发者我更关心的是另一件事Agent的数据行为到底谁来审计怎么审计一个会在本地执行命令、自动调用工具、自己决定读取哪些文件的AI编程助手它对文件的每一次访问、每一条出网请求、每一个终端命令是否处于可控可查的状态如果你也在用AI编程助手或者你正在给团队评估是否可以引入这类工具这篇文章值得认真看完。我会从事件本身拆起讲清楚Agent架构下数据行为审计为什么那么难然后给出一套自己实测过的、完全能落地的审计方法和防护思路。1. ZCode风波到底是怎么回事1.1 事件缘起从“本地补全”到“云端上传”的信任断层ZCode在国内AI编程赛道里算是动作比较快的一个定位不只是“IDE里的补全插件”而是更接近Agent形态它能理解项目结构、自动修改多个文件、根据用户问题执行终端命令。社区里最初对它的评价并不差直到有人说“我用代理抓包发现ZCode把我的代码文件内容传上去了”。这句话之所以能在开发群里炸开是因为它踩中了一个关键的心理落差。大多数开发者默认的信任模型是IDE插件会做本地索引代码补全会把当前文件和附近片段发给模型这是行业普遍做法大家能接受。但“自动执行终端命令”和“上传超出当前项目的文件内容”超出了这个默认许可范围信任裂痕就此产生。社区随后出现更多“复现实验”有用户反馈它在自己的用户目录下创建了脚本也有用户观察到它请求了与当前编辑器打开项目无关的路径。事态发展到这个阶段已经不是某一个功能好用不好用的问题而是“AI助手是否越权”的问题。1.2 被质疑的三种高风险行为在社区讨论和复现过程中被集中质疑的行为大概可以归纳为三类我直接给一个表格方便快速对比行为类型具体表现风险点本地代码读取与上传将项目文件内容作为上下文发送到云端模型接口甚至读取仓库之外的文件商业源码、未公开算法、客户数据可能外泄终端命令自动执行自动运行诊断脚本、临时生成并执行命令比如网络探测、配置读取攻击面扩大恶意仓库可能诱导Agent执行有害命令动态脚本与Skill扩展从仓库或外部加载插件、Skill定义执行其中包含的脚本或IDE命令供应链投毒风险仓库本身成为攻击入口这里要特别说明一点目前还没有任何官方结论认定ZCode就是“恶意偷代码”。但从工程审计的角度看这些行为如果真的存在哪怕只发生一次也已经足够说明问题。信任不是靠一句“我们不会偷”建立的而是靠清晰的数据行为声明、默认的本地处理能力、以及可供用户开启的审计日志来建立的。1.3 为什么开发者对此格外敏感很多人问不就是一个IDE插件吗它能看你电脑上的文件这不是常识吗问题就在于“看哪些文件”和“执行哪些命令”完全不一样。IDE要索引项目文件这是它的工作但它没有合理理由去读~/.ssh/id_rsa也没有合理理由去扫描用户的~/.aws/credentials。同样终端命令自动执行这件事传统IDE插件顶多帮你运行一下编译任务而Agent可以自己决定执行任何它认为“有用”的命令。决策主体从人变成了AI这带来的是审计逻辑的根本变化。再加上企业环境里的代码资产是核心竞争力的一部分NDA协议约束的是“人”而不是“Agent”。如果Agent自动把代码发到云端即使没有泄露也已经在合规层面产生了一个巨大盲区。很多企业安全团队现在听到“AI编程助手”四个字就头大原因就在这里。2. Agent为什么天然存在“数据行为审计”黑洞2.1 Agent架构下的数据流链路要理解审计为什么难先得理解Agent是怎么工作的。一个Agent系统通常由三部分构成大模型本身、上下文组装层、工具调用层。大模型提供理解与生成能力上下文组装层负责把当前工程文件、命令行输出、文件读取结果等内容“喂”给模型工具调用层则赋予模型“做事”的能力比如执行命令、修改文件、调用外部API。ZCode这类产品在解决真实问题时确实需要读取文件内容。比如你让它“修复这个报错”它需要查看报错文件、查看包的依赖关系、可能需要执行npm test来复现问题。这些行为从产品设计上是合理的也是用户主动触发的。问题在于一旦Agent具备了这个能力如何界定“合理读取”与“越权读取”之间的边界Agent在执行过程中可能因为上下文不完整去读取配置文件、环境变量、个人目录下的其他文件而这些访问行为用户是看不到的。这就是审计的第一个难点行为多、路径杂、用户无感知。2.2 传统审计手段为什么失效企业安全团队不是没有审计工具传统DLP数据防泄漏、EDR端点检测与响应、网络代理日志这一套组合拳在拦截恶意软件方面很有效。但它们面对Agent时集体失灵了原因有二。第一Agent的行为在系统层面是“合法进程的合法访问”。它走的是IDE进程或Node进程的标准文件读API网络请求走的是正常HTTPS流量EDR很难判断这是用户主动操作还是Agent自主行为。第二日志分散在不同层IDE自身日志记录一部分系统内核记录一部分网络代理记录一部分终端历史记录一部分但它们之间没有关联ID很难还原一条完整的行为链。我见过很多审计团队拿到一堆日志却拼不出“Agent在某个时间点读了哪个文件、然后把这个内容发到了哪个域名”的完整证据链。2.3 “可解释”不等于“可审计”还有一个更深层的问题Agent对你说的“解释”是模型生成的不是真实执行记录。你问ZCode“刚才为什么读取这个文件”它能给你一个合理的解释但那是生成出来的自然语言并不代表执行日志里真的发生了这样一个操作。这就像员工给你的解释很精彩但监控录像显示他实际做的是另一件事。审计要的是白盒证据链是每一个文件访问、每一条出网请求、每一个命令执行的真实记录而不是模型基于概率生成的解释。把这两者混为一谈是很多AI Agent安全讨论里的最大误区。Skill和Agent的区别在这里也值得单独提一句。Agent是调度主体Skill更像一个能力包或者技能说明书它告诉Agent在什么情况下执行什么操作。问题在于Skill往往由普通Markdown或YAML描述组成可能跟着一段脚本代码。如果Agent自动加载了一个恶意Skill并执行其中的脚本整个安全边界就被打破了。这也是为什么我个人建议凡是支持外部Skill加载的Agent使用前必须做行为白名单评估不能只看厂商宣传。3. 实操开发者如何自己给Agent做数据行为审计前面讲了那么多原理下面进入能直接抄作业的部分。接下来这套审计流程我在自己电脑上完整跑过也帮几个团队做过。它可以用来审计ZCode也可以用同样的思路审计其他AI编程助手。整个过程分四步抓网络出站请求、监控本地文件访问、追踪进程与命令执行链、汇总审计报告。3.1 第一步抓出站网络请求抓网络请求我优先推荐mitmproxy纯命令行、脚本友好、能看到HTTPS解密后的明文请求体。Wireshark也可以但面对HTTPS只能看到加密包信息量太少不适合判断“是否上传了代码”。操作步骤# 安装 mitmproxymacOS 示例 brew install mitmproxy # 启动标准代理监听 8080 端口 mitmproxy --mode regular --listen-port 8080启动后把系统代理设为127.0.0.1:8080。然后在终端里执行export https_proxyhttp://127.0.0.1:8080 export http_proxyhttp://127.0.0.1:8080接着打开IDE开始使用ZCode让它完成几个最典型的场景生成代码、解释项目、执行终端命令、修复报错。做完这些操作后回到mitmproxy界面按域名和路径过滤重点看两类内容一类是模型API接口的请求体比如是否携带了大段文件内容另一类是统计类、遥测类接口判断请求频率和数据范围。有一点需要提醒很多AI编程助手会做证书锁定SSL Pinning即使你装了系统代理证书它也不一定走系统代理。遇到这种情况你就要用透明代理模式通过iptables把指定进程或全部流量重定向到mitmproxy然后再观察。如果还是抓不到大概率是流量走了HTTP/3QUIC这时候直接改在路由器层抓包或者用TUN模式接管本机网卡。3.2 第二步监控本地文件访问行为网络请求只能告诉你“发出去的”但“读了哪些文件”需要靠文件系统监控来还原。这里分平台给方案。Linux下最顺手的是inotifywait配合auditd做落盘记录。# 监控关键目录记录所有访问事件 inotifywait -r -m ~/.ssh ~/.aws /path/to/your/project file_access.log 21macOS下可以用fs_usage实时性很强能看到是哪个进程发起的文件读取# 监控文件系统访问过滤出 IDE 相关进程 sudo fs_usage -w -f filesystem | grep -E (Code Helper|ZCode|node|python)Windows上用Sysmon或者Process Monitor都行Sysmon配合配置文件能记录进程对文件的访问事件适合长期审计。实操的时候我建议把监控范围分成两类。第一类是“项目内目录”审计目的是看Agent是否读入了项目代码作为上下文第二类是“敏感目录”比如~/.ssh、~/.aws、/etc/hosts、.env文件等只要Agent进程访问了这些路径先标记为高风险再做人工确认。我在实测ZCode时确实捕捉到过对非项目目录的访问社区里那些“扫盘”的截图和这个现象是能对上的。3.3 第三步追踪进程与命令行执行链文件访问监控能看到读文件的行为但要搞清楚Agent是否自动执行了命令还得看进程链。Agent执行终端命令时通常会以IDE子进程的方式启动一个Shell然后在这个Shell里执行命令。Linux下用auditd可以直接记录进程执行事件。先在/etc/audit/rules.d/audit.rules里加上-w /bin/bash -p x -k shell_exec -w /usr/bin/python3 -p x -k python_exec -w /bin/sh -p x -k sh_exec然后重启auditd服务之后用ausearch查询sudo ausearch -k shell_exec -ts recent | grep ZCodemacOS下相对复杂dtruss需要关闭SIP才能用日常我更推荐先用ps加lsof做事中观察再用log stream收集系统统一日志# 查看特定进程的所有打开文件 lsof -p $(pgrep -f ZCode|Code Helper) | grep -E (\.ssh|\.aws|\.env) # 流式查看系统日志 log stream --predicate process Code Helper OR eventMessage CONTAINS bash这里要建立一个判断标准Agent自己启动的bash -c、python -c、node -e命令属于动态执行必须重点对待。不是说这类命令一定有问题而是它们绕过了常规的手动操作路径不在用户预期范围内。如果Agent在每次会话开始都会自动执行几条命令收集环境信息那这几条命令的行为必须被纳入日常审计范围。3.4 第四步把结果汇成一份可读的审计报告抓到的明细数据如果只是堆在文件里审计价值很低。我习惯把三类数据网络请求、文件访问、进程执行汇总成一份带时间线的报告。为了方便我写过一个很简单的bash脚本把关键信息统一抽出来#!/bin/bash # agent_audit.sh —— 简易 Agent 行为审计信息采集 LOG_DIR./agent_audit_$(date %Y%m%d_%H%M%S) mkdir -p $LOG_DIR # 1. 收集当前进程信息 ps aux | grep -E (ZCode|Code Helper|node.*agent) $LOG_DIR/processes.txt # 2. 收集打开的文件句柄 for pid in $(pgrep -f ZCode|Code Helper); do lsof -p $pid $LOG_DIR/open_files.txt 2/dev/null done # 3. 收集网络连接 lsof -i -n -P | grep -E (ZCode|Code Helper|node) $LOG_DIR/network.txt echo 审计信息已保存到: $LOG_DIR这个脚本只是起点实际使用中可以把输出内容导入到Wazuh这类开源SIEM里做关联分析。报告格式我建议按“时间-进程-行为-目标”四列展开例如“10:32:15 - Code Helper - 读取 /Users/dev/.aws/credentials - 本地文件”这样安全团队拿到后可以快速判断行为是否越界。4. 企业层面给Agent装一个“监控摄像头”个人审计做好之后企业环境下要考虑的是规模化治理。一个开发者自己能盯着一个研发团队几十上百人总不能靠每个人自觉。企业引入AI编程助手之前我认为至少要完成三件事统一网络出口和审计、配置文件访问策略、以及把Agent装进隔离环境运行。4.1 统一代理出口让API请求变得可控最有效的第一道防线是让Agent的网络流量统一走企业可控的代理网关。所有AI编程助手包括ZCode在内的模型调用都通过企业架设的正向代理解析并在这一层做域名白名单和请求体审计。具体落地方案有两类。一类是透明代理模式在研发网内部署一台mitmproxy做流量镜像和阻断把目标域名限制在厂商API域名和必要的遥测域名其他域名一律放行前先告警。另一类是显式代理方式在开发环境变量里强制设置export https_proxyhttp://proxy.corp.local:8080 export http_proxyhttp://proxy.corp.local:8080配合代理层做CA证书下发实现HTTPS解密审计。需要注意强制装企业CA证书会在开发者机器上产生信任改动必须走完合规流程并明确告知“这是审计行为”。很多团队在这里踩坑没有提前通知就统一装证书结果开发者反弹比Agent偷传代码还大。4.2 文件系统访问规则与端点DLP策略网络层堵住了文件系统层的“越权读取”也要堵。在Windows上可以用Sysmon配置规则把Agent进程对敏感目录的访问事件实时上报到日志中心。Linux上则用auditd规则把重点目录全部纳入监控-w /home/dev/.ssh -p rwa -k agent_ssh_key_access -w /home/dev/.aws -p rwa -k agent_aws_access -w /etc/passwd -p wa -k agent_config_change -w /home/dev/.env -p wa -k agent_env_access这里有一个经验用关键词搜索agent_ssh_key_access很容易定位问题但真正有效的是在DLP规则里加“敏感内容匹配”比如当Agent访问含PRIVATE KEY或AKIA开头的文件时直接阻断。如果企业还没有这类DLP产品至少要先把规则配上哪怕只是记录不阻断也能大幅缩短事后排查的时间。4.3 用最小权限和容器隔离做兜底审计做得再好也不如让Agent的默认权限小到“即使越界也看不到敏感数据”。这是我反复给团队强调的一句话。Agent扫描你的目录核心问题不是说它有没有这个权限而是它“看得见”。如果你把它的视野限制起来它想扫也扫不到。具体操作上推荐给Agent创建一个独立低权限系统用户只授予项目目录的读写权限敏感目录全部拒绝访问。更彻底的做法是直接容器化# 以受限容器运行 Agent 相关进程 docker run -it --rm \ --network my_audit_proxy \ -v /path/to/project:/workspace:ro \ --read-only \ --cap-drop ALL \ --security-opt no-new-privileges \ agent_sandbox /bin/bash这个容器只挂载了项目目录且是只读的Agent在里面执行什么命令都改不了本机访问不了SSH密钥网络也必须走指定的审计代理。它能做的事情被明确限制在一个可控范围内这才是治本。我个人非常推荐企业在让开发者使用AI编程助手时默认走这个模式而不是出了问题再靠日志来追溯。5. 常见问题与排查技巧实录最后这部分我把自己在给团队做Agent审计时踩过的坑和排查思路整理成问题速查希望帮你少走弯路。5.1 如何判断“偷传代码”是不是误报很多开发者自己抓了包看到IDE在往某个域名发送内容第一反应就是“被偷了”。但实际上有大量正常行为会产生类似流量需要先做鉴别。常见误报来源包括IDE自带的远程开发扩展比如Live Share、Git自动推送、插件市场更新检查、以及语言服务协议LSP拉取的依赖信息。区分方法有三个维度。看目标域名有没有明确属于模型API或厂商遥测看请求体积有没有一次性携带几千行代码看触发时机是不是你每次打开编辑器就发生是否与具体的代码操作关联。单独一个维度可信度不高三个叠加起来看才能下判断。如果只是定时小流量上报统计信息那是目前行业通病需要靠隐私策略约束如果是跟着文件编辑操作同步上传整个文件明文就必须严肃对待。5.2 审计中发现异常流量第一件事应该做什么先说一个常见的错误操作很多人一看到异常流量就立刻拔网线、杀进程结果证据链断了后面想追溯都追溯不了。正确做法是先保存证据。mitmproxy里直接按w保存当前流程然后CtrlC暂停不是问题但先别急着清理。同时用lsof -i记录当时的网络连接快照用ps aux记录进程状态。这些原始数据是后续跟厂商交涉或做内部定级的依据。5.3 为什么你抓包抓不到某些Agent的流量我自己也遇到过这种场景代理明明配好了但mitmproxy里就是看不到Agent的请求。原因基本逃不过三种第一种是Agent进程没有继承系统代理环境变量尤其是从GUI启动的应用经常不读http_proxy第二种是证书锁定Agent在代码里直接固定了服务端证书你的CA证书吓不倒它第三种是流量走了HTTP/3协议绕过传统HTTPS代理。对应的解决办法是GUI应用用代理工具提供“系统代理”开关命令行启动则显式设置环境变量遇到证书锁定就改用TUN模式接管整个网络栈确诊HTTP/3后则回到路由器层抓包或者临时在DNS层面做重定向。如果以上都不可行还有一个笨但有效的办法用一台临时的Linux虚拟机作为浏览器和终端环境监控对象只在这台虚拟机里跑所有流量在宿主机层做镜像绝对干净。5.4 常见问题速查表现象可能原因处理建议抓包只看到加密流量无法解密Agent未信任代理CA或开启SSL Pinning改用TUN模式或在路由器层抓包分析文件监控发现读取用户目录可能是Agent在做机器识别、环境收集先判断是否在执行前告知用户无告知则记录为风险行为终端出现自动执行的bash命令上下文触发工具调用正常功能之一详细记录命令内容判断是否在用户预期内请求列表中出现未知第三方域名可能包含遥测或数据上报用DNS和Whois反查域名归属结合请求体判断Agent性能时好时坏、偶发卡顿可能有大量本地文件被读取并上传检查网络代理日志和出站流量体积提示即使在安全事件结束后也建议保存好审计日志至少留存90天。后续如果引发合规审查日志本身就是最重要的事实依据。我个人现在的习惯是任何AI编程助手第一次进入项目前先跑一遍上面这套行为画像并把结果同步给团队团队内部也从“禁止使用”转向了“准入审计”的模式也就是允许开发者使用但必须在可控网络环境、最小权限容器、统一日志审计三个前提下使用。这样做虽然前期要花半天时间做环境配置但长期看远比出了事故再排查便宜。最后分享一个小技巧把审计流程写成Makefile或npm script固定在每周一跑一次不要等出了问题才想起来看一眼。Agent产品更新迭代很快今天的行为边界和三个月后的很可能完全不同定期审计能让你及时发现行为变化。你不需要成为安全专家只要多花这几分钟就能在“AI高歌猛进”的时候守好自己这摊代码的基本盘。