最近一周，开发群里聊得最多的不是某个新框架发布，而是智谱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只能看到加密包，信息量太少，不适合判断“是否上传了代码”。
操作步骤：
# 安装 mitmproxy（macOS 示例） brew install mitmproxy # 启动标准代理，监听 8080 端口 mitmproxy --mode regular --listen-port 8080启动后把系统代理设为127.0.0.1:8080。然后在终端里执行：
export https_proxy=http://127.0.0.1:8080 export http_proxy=http://127.0.0.1:8080接着打开IDE，开始使用ZCode，让它完成几个最典型的场景：生成代码、解释项目、执行终端命令、修复报错。做完这些操作后，回到mitmproxy界面，按域名和路径过滤，重点看两类内容：一类是模型API接口的请求体，比如是否携带了大段文件内容；另一类是统计类、遥测类接口，判断请求频率和数据范围。
有一点需要提醒：很多AI编程助手会做证书锁定（SSL Pinning），即使你装了系统代理证书，它也不一定走系统代理。遇到这种情况，你就要用透明代理模式，通过iptables把指定进程或全部流量重定向到mitmproxy，然后再观察。如果还是抓不到，大概率是流量走了HTTP/3（QUIC），这时候直接改在路由器层抓包，或者用TUN模式接管本机网卡。
3.2 第二步：监控本地文件访问行为
网络请求只能告诉你“发出去的”，但“读了哪些文件”需要靠文件系统监控来还原。这里分平台给方案。
Linux下最顺手的是inotifywait，配合auditd做落盘记录。
# 监控关键目录，记录所有访问事件 inotifywait -r -m ~/.ssh ~/.aws /path/to/your/project > file_access.log 2>&1macOS下可以用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 "ZCode"macOS下相对复杂，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_proxy=http://proxy.corp.local:8080 export http_proxy=http://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保存当前流程，然后Ctrl+C暂停不是问题，但先别急着清理。同时用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高歌猛进”的时候守好自己这摊代码的基本盘。
