一份针对 Grok Build CLI v0.2.93 的流量分析报告引发了严重的供应链安全争议。研究者 @cereblab 声称，即使用户没有明确授权读取文件，该 CLI 仍会打包并上传整个 Git 仓库，范围可能包括提交历史、已跟踪文件以及 .env 中的密钥。来源标题还称，xAI 随后通过远程机制关闭了相关能力。
这些结论目前应被视为研究报告中的指控，而不是本文独立复现的事实。但它暴露的问题并不局限于某个产品：当 AI 编码工具同时拥有文件系统、Git 历史和网络访问权限时，传统的“是否允许读取当前文件”提示框已经不足以描述真实的数据边界。
真正的风险不只是上传当前代码
一个 CLI 在仓库根目录运行时，能够接触的数据通常比编辑器里打开的文件多得多：
.git目录保存完整提交历史、远程地址、分支引用和历史对象。- 已删除的密钥可能仍存在于历史提交中。
.env、云平台凭据和本地配置不一定受.gitignore保护。- 未跟踪文件、构建产物、调试日志也可能包含用户数据。
- 子模块配置和 Git remote 可能暴露内部基础设施地址。
因此，“工具没有读取我正在编辑的文件”不等于“工具没有扫描或打包仓库”。安全评估需要分别检查文件访问、Git 命令调用、归档行为、网络请求和服务端存储策略。
远程关闸也不能替代客户端修复。远程开关可以快速停止某项服务端能力，但旧版本是否仍能构造上传请求、已经上传的数据如何删除、对象存储保留多久，仍需要明确说明和验证。
用隔离副本控制工具能看到什么
在厂商给出可验证的数据边界之前，可以这样实践：不要让联网的 AI CLI 直接进入原始仓库，而是生成一个不含 .git、环境文件和常见密钥的临时工作副本。
下面的脚本需要 Bash、Git 和 rsync。把 AI_COMMAND 改成实际命令；脚本默认只创建隔离目录，确认内容后才执行工具。
#!/usr/bin/env bash
set -euo pipefail
REPO="${1:-.}"
STAGE="$(mktemp -d)"
trap 'rm -rf "$STAGE"' EXIT
repo_root="$(git -C "$REPO" rev-parse --show-toplevel)"
rsync -a --delete \
--exclude='.git/' \
--exclude='.env' \
--exclude='.env.*' \
--exclude='*.pem' \
--exclude='*.key' \
--exclude='credentials.json' \
--exclude='.aws/' \
--exclude='.ssh/' \
"$repo_root/" "$STAGE/"
printf 'Isolated workspace: %s\n' "$STAGE"
printf 'Files visible to the CLI:\n'
find "$STAGE" -type f -print | sort
read -r -p 'Run the AI CLI in this directory? [y/N] ' answer
if [[ "$answer" == "y" || "$answer" == "Y" ]]; then
cd "$STAGE"
AI_COMMAND="${AI_COMMAND:-grok-build}"
exec "$AI_COMMAND"
fi
运行方式如下：
chmod +x run-ai-isolated.sh
AI_COMMAND='grok-build' ./run-ai-isolated.sh /path/to/repository
这不是完整沙箱：进程仍可能读取用户主目录或访问网络。更严格的方案应把临时目录挂载进容器，只注入短期凭据，并通过代理或防火墙限制出口。若工具必须访问云端 API，可以只开放已审查的域名，而不是给予任意外网访问权。
抓包只能回答一部分问题
研究者使用 mitmproxy 观察网络流量是一种常见审计方法。可以这样搭建本地测试环境：
python3 -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip mitmproxy
mitmweb --listen-host 127.0.0.1 --listen-port 8080
然后在单独的测试仓库中，通过代理启动待审计 CLI：
export HTTPS_PROXY=http://127.0.0.1:8080
export HTTP_PROXY=http://127.0.0.1:8080
mkdir -p /tmp/cli-audit && cd /tmp/cli-audit
git init
git config user.email audit@example.invalid
git config user.name audit
printf 'AUDIT_MARKER=unique-test-value\n' > .env
printf 'hello\n' > README.md
git add README.md
git commit -m 'audit fixture'
grok-build
只应使用虚构标记，不要为了验证泄露而放入真实密钥。还要注意，证书固定、私有 CA 校验或忽略代理环境变量都会让 mitmproxy 看不到明文；“没有抓到请求”不能直接证明没有联网。可进一步结合进程级文件审计、DNS 日志和出口防火墙记录交叉验证。
团队采用前应要求什么
评估此类工具时，团队至少应确认以下事项：
- 默认收集范围是否只包含用户明确选择的文件。
- 是否读取
.git、未跟踪文件、忽略文件和环境变量。 - 上传前是否显示可检查的文件清单与总字节数。
- 是否提供完全关闭遥测、仓库索引和后台上传的选项。
- 服务端保存位置、保留周期、删除流程和模型训练策略是否明确。
- 客户端是否支持固定版本、校验签名和可审计的更新记录。
- 远程开关能改变哪些客户端行为，变更是否留下日志。
对包含生产密钥、客户代码或受监管数据的仓库，默认策略应是拒绝直接运行未经审计的联网 CLI。隔离副本、最小权限、短期凭据和出口审计会增加一些操作成本，但它们把“相信工具不会上传”转化为可以观察和约束的工程边界。