你刚写完一段敏感代码AI 助手帮你补全了下一行。光标还在闪烁屏幕上那个建议看起来天衣无缝。但你有没有想过在你按下 Enter 的那一刻——你的代码正在去哪里这不是危言耸听。2026 年 7 月安全研究员 cereblab 用 mitmproxy 对 Grok Build CLI 抓包发现了一个让整个开发者社区后背发凉的事实Grok Build CLI 会在用户毫不知情的情况下把完整仓库代码Git 历史上传到 xAI 的 Google Cloud Storage。更离谱的是连.env里的明文密钥、甚至扫描到的 Claude Code 配置文件中的 API Key一块送走了。整件事最让人不安的不是某一个工具出问题而是——如果没有人去抓这把包我们可能永远都不知道。懒人版30 秒看完结论你的工具风险等级最快要做什么Grok Build CLI 高检查网络流量立即停止在敏感仓库中使用Claude Code 中检查配置文件是否被其他工具读取关注隐私政策更新Cursor / Copilot / 其他 AI 工具 待查用本文方法自查确认上传了什么企业自研 AI 工具 高部署网络代理统一审计确认数据流向不管你现在用的是哪家的工具这篇文章给你一套可复现的自查流程。10 分钟你就能知道你的 AI 编辑器在背后干了什么。一、Grok 事件给我们敲了什么警钟不只是 xAI 的问题cereblab 公布的数据触目惊心。Grok Build CLI v0.2.93 在用户执行grok build时会将当前仓库完整打包上传。一个 12 GB 的仓库上传了5.10 GiB的数据而实际用于模型推理的通道只有192 KB。差距 27,800 倍。这 5.10 GiB 里包括了什么代码、Git 历史、环境变量文件、甚至你本机上 Claude Code 的 API Key——Grok 会主动扫描 Claude Code 的配置目录把密钥一并带走。更微妙的是xAI 提供了改进模型开关即使用户关闭了这个选项上传行为仍在进行。这个开关只是个摆设。没有日志、没有弹窗、没有任何提示你的代码就这么静默地离开了你的机器。所有 AI 编程工具都需要检查Grok 不是唯一一家。任何一个 AI 编程工具只要它联网理论上都存在未经你明确同意就上传数据的风险IDE 插件Copilot、Codeium、Tabnine 等终端工具CLI 类的 AI 助手各类 Agent 框架区别只是上传了什么和有没有告诉你。有些工具只在出 bug 时上传诊断信息有些把整个工作区做向量化索引上传到云端——而这些细节往往藏在几十页隐私政策的第 17 条里。默认开启才是最可怕的Grok 事件里最值得警惕的是默认开启、悄悄上传、用户完全无感。大多数开发者安装 AI 工具后第一件事是体验功能而不是去翻设置页。而厂商们很清楚这一点——默认开启意味着绝大多数用户永远不会关掉它。这不是 Grok 独有的问题。不少 AI 编程工具的首次启动体验都类似欢迎界面 - 快速示例 - 开始使用。至于你的数据去了哪里、存了多久、谁可以访问——这些信息被折叠进了一屏又一屏的 EULA 里。二、4 种自查方法从易到难方法难度效果耗时系统防火墙监控Little Snitch⭐能发现异常连接但看不到内容5 分钟mitmproxy 抓包分析⭐⭐⭐能看到传输的内容最彻底15 分钟沙箱隔离运行⭐⭐安全但需要配置环境10 分钟安装前源码审计⭐⭐⭐⭐从根上确认行为但门槛高30 分钟1. 系统防火墙监控最简单macOS 用户可以用 Little Snitch这是最快感知工具在打电话的方式。安装并启动 Little Snitch 后运行你的 AI 工具观察弹窗连接指向了工具官网的 API 域名这是正常的。连接指向了一个你不认识的云存储域名如storage.googleapis.com、s3.amazonaws.com需要警惕。连接在你没有主动触发 AI 功能时仍在发送数据高度可疑。为什么这招有用AI 工具的核心功能只需要一个 API 推理端点。如果它额外连接云存储服务大概率是在上传文件。防火墙让你看到最表层的异常行为不需要理解 HTTPS 协议也能用。但对于看清楚上传了什么防火墙无能为力。这就是下一步要做的事。2. 抓包分析最彻底这是 cereblab 用的方法也是你能做的最彻底的自查。核心工具mitmproxy。# 第一步安装 mitmproxy# macOSbrewinstallmitmproxy# Linux (Ubuntu/Debian)sudoaptinstallmitmproxy# Windows (通过 scoop)scoopinstallmitmproxy# 第二步信任 mitmproxy 的 CA 证书macOS# 这样 mitmproxy 才能解密 HTTPS 流量security add-trusted-cert-rtrustRoot-k~/Library/Keychains/login.keychain-db\~/.mitmproxy/mitmproxy-ca-cert.pem# 第三步在代理下运行目标工具# 将 HTTPS 流量转发到 mitmproxyHTTPS_PROXYhttp://127.0.0.1:8080SSL_CERT_FILE~/.mitmproxy/mitmproxy-ca-cert.pem\your-ai-tool--prompt写一个 hello world操作流程启动 mitmproxy命令行运行mitmproxy打开另一个终端通过代理环境变量启动你的 AI 工具在 mitmproxy 界面中按i过滤流量输入~u (ai|grok|anthropic|claude|upload|storage)触发 AI 功能比如请求一次代码补全观察是否有大体积请求几百 KB 到 MB 级别发往非推理端点的域名为什么这招有用防火墙只能看到在连接mitmproxy 让你看到连接里装了什么。一个正常的 AI 提示请求只有几百字节到几 KB你的提示词 上下文摘要。如果看到几十 MB 的上传流量那就铁证如山了。注意如果工具使用了证书固定Certificate Pinningmitmproxy 可能无法解密流量。这种情况下可以退而使用防火墙方法。3. 沙箱运行最安全如果不想让自己的工作环境暴露风险可以把 AI 工具关进沙箱里跑。# 使用 Docker 创建隔离环境dockerrun-it--rm\-v$(pwd)/test-project:/workspace\ubuntu:22.04bash# 在容器中安装并运行 AI 工具# 容器内用 tcpdump 监控网络aptupdateaptinstall-ytcpdumpcurltcpdump-ieth0-w/tmp/ai-traffic.pcap沙箱的好处是AI 工具无法访问你主机上的敏感文件.env、~/.ssh/、AWS 凭据等即使它恶意上传也拿不到真金白银的数据你可以用快照对比安装前后文件系统的变化为什么这招有用沙箱从根本上限制了工具的行为半径。它不知道主机上有什么就不能上传什么。在测试新工具、新版本时先用沙箱跑一圈是个好习惯。4. 安装前审计最根本在把工具安装到你的开发机之前先看看它要干什么。这一步门槛最高但最有价值。# 检查 npm 包的安装脚本npmpack your-ai-tooltar-xzfyour-ai-tool-*.tgzcatpackage.json|greppostinstall\|preinstall# 检查 pip 包的安装逻辑pip download your-ai-tooltar-xzfyour-ai-tool-*.tar.gzlssetup.py install.sh安装脚本是很多恶意行为藏身的地方。如果发现postinstall里有网络请求、文件收集、或者调用外部可疑域名那基本可以一票否决。为什么这招有用前面三种方法都是事后发现只有在工具运行时才能抓到证据。安装前审计则是事先预防。等你跑起来再发现数据泄露代码已经到了别人的服务器上。三、参考cereblab 的复现方案如果你想像 cereblab 那样完整复现 Grok 事件的全过程这里是他用过的技术方案完全可复现。金丝雀文件法在仓库中放一些金丝雀文件——包含独有标识符的内容。如果这些内容出现在外网就能确认泄露来源。# 创建金丝雀文件echoCANARY-TOKEN-$(uuidgen).envechoCANARY-TOKEN-$(uuidgen).env.localechoCANARY-TOKEN-$(uuidgen)secrets.txt之后在 GitHub、GitLab 等平台上搜索这些标识符或者在 mitmproxy 中过滤这些字符串。用 mitmproxy 捕获流量这是 cereblab 的核心方法。使用 HTTP 回放模式你可以详细检查每个请求的正文内容。# 启动 mitmproxy 并记录流量到文件mitmproxy --save-stream-file grok-traffic.flow# 在另一个终端运行 grokHTTPS_PROXYhttp://127.0.0.1:8080 grok build之后可以用mitmproxy -r grok-traffic.flow回放查看每个请求的细节。重点关注Content-Length异常大的 POST 请求请求路径中包含upload、store、save等关键词的请求请求体中出现你仓库文件名的请求git bundle 验证Grok 会上传整个 Git 历史你可以通过检查网络流量中是否出现.git的目录结构来确认。# 在你的仓库中创建一个包含大量二进制文件的提交# 然后在 mitmproxy 中观察是否有等量的数据上传ddif/dev/urandomoflarge-test-file.binbs1Mcount100gitaddlarge-test-file.bingitcommit-mtest: large binary for audit如果你看到 mitmproxy 中有 ~100 MB 的上传流量那基本可以确认工具在上传完整仓库。四、保护代码的日常习惯经过上面的一通操作你大概已经知道了自己的工具在做什么。接下来是如何在日常开发中降低风险。环境变量 .env 文件.env文件是 AI 工具最喜欢偷的东西——纯文本、结构清晰、直接暴露密钥。尽量改用操作系统的环境变量管理机制macOS: 在~/.zshrc或~/.bash_profile中 export使用 1Password CLI、pass 等秘密管理工具注入环境变量如果非要使用.env在.gitignore之外再用专门的加密方案敏感代码隔离策略不要把敏感代码和普通代码混在一个目录下工作。策略很简单敏感项目不用 AI 编程工具。用沙箱环境或离线开发。普通项目可以在审计后使用 AI 工具但要定期用本文方法复查。创建一个专门的测试仓库只在这里运行新安装或新版本的 AI 工具确认行为正常后再放行到工作环境。企业级防护方案如果你是团队负责人或 DevOps以下方案可以帮助团队统一管控部署透明代理在团队网络出口统一配置所有 AI 工具的流量经过代理审计DLP数据泄露防护系统对上传数据进行内容检测拦截包含密钥或敏感信息的请求白名单机制只允许特定的、经过审计的 AI 工具和版本在公司网络内使用定期审计每个季度抽查团队成员的开发环境复现 cereblab 式的抓包测试SDLC 集成在开发流程的定义阶段就明确哪些数据可以交给 AI 工具处理总结Grok Build CLI 事件不是孤立个案它撕开了一个行业性的信任缺口。当一个 AI 编程工具可以在用户完全不知情的情况下把 12 GB 的仓库、Git 历史、明文密钥、甚至其他工具的 API Key 一并打包上传——这不是 bug这是一个需要整个行业正视的安全问题。作为开发者我们的底线不是等厂商改进而是自己掌握检查的能力。10 分钟的抓包测试换来的不只是安心更是对你代码数据的掌控权。数据来源cereblab 于 2026 年 7 月公布的 Grok Build CLI 安全分析报告mitmproxy 官方文档与安全社区复现方案如果你用本文的方法发现了异常欢迎在评论区分享你的发现。安全意识这件事一个人的火把可以照亮一群人。