xAI Grok Build CLI 0.2.93 线层级分析
xAI Grok Build CLI 0.2.93 线层级分析
执行摘要
对 xAI Grok Build CLI(版本 0.2.93)的分析表明,该工具会将整个本地仓库——包括 git 历史记录和未经脱敏的密钥文件——传输到 xAI 服务器。这些数据被持久化存储在名为 grok-code-session-traces 的 Google Cloud Storage (GCS) bucket 中,且上传行为与 AI agent 是否实际读取了文件,或者用户是否禁用了 "Improve the model" 设置无关。
密钥的未经脱敏传输
Grok Build 会逐字传输其读取的文件内容,包括 .env 和密钥文件,且不进行任何脱敏处理。
当 CLI 读取文件以向模型提供上下文时,内容会通过两个不同的通道进行发送:
- Model-Turn Channel: 内容被序列化到
POST /v1/responses请求体中。 - Storage Channel: 内容被打包进一个
session_state归档文件中,并通过POST /v1/storage上传。
线层级捕获证实,放置在 .env 文件中的 canary secrets(例如 API_KEY=CANARY7F3A9-SECRET)以明文形式传输,并被服务器以 HTTP 200 状态码接受。
全仓库外泄
无论 agent 读取了什么,Grok Build CLI 都会上传工作区的完整快照,包括所有被追踪的文件和完整的 git 历史记录。
来自线层级捕获的证据显示,发送用于模型响应的数据与发送用于存储的数据之间存在巨大差异。在一次涉及 12 GB 随机文件的仓库测试中(明确告知 agent 不要读取这些文件),model-turn channel 仅传输了 192 KB,而 storage channel (/v1/storage) 则传输了超过 5.10 GiB 的数据。
通过 Git Bundles 进行验证
为了证明未读取的文件也会被上传,研究人员使用了一个包含唯一标记的 "canary" 文件 (src/_probe/never_read_canary.txt)。尽管提示词要求 agent "Reply with exactly: OK. Do not read or open any files",CLI 仍通过 POST /v1/storage 将整个仓库作为一个 git bundle 上传。通过对捕获的 bundle 进行 git clone,可以完整地恢复出 canary 文件及其唯一标记,以及完整的 git 历史记录。
基础设施与遥测数据
这些上传的目标是 Google Cloud Storage bucket,而不是 AWS S3。
对二进制字符串和捕获的 metadata.json 文件的分析揭示了以下内容:
- Destination Bucket:
gs://grok-code-session-traces/ - API Endpoints: 请求通过
cli-chat-proxy.grok.com进行路由,并直接发送到storage.googleapis.com进行多部分上传。 - Telemetry: CLI 会向 Mixpanel (
api.mixpanel.com) 和 xAI 自己的事件端点 (grok.com/_data/v1/events) 发送追踪数据。
策略与同意分析
禁用 "Improve the model" 开关并不能阻止仓库上传。
虽然 xAI 提供了使用数据来改进模型的退出选项,但该设置控制的是训练策略,而非数据传输。测试证实,在 "Improve the model" 关闭的情况下,,CLI 仍会将整个仓库作为 git bundle 上传,且服务器的 /v1/settings 响应继续返回 "trace_upload_enabled": true。
此外,研究人员指出,将 repo_state 和 session_state 上传到 grok-code-session-traces bucket 的机制并未在 CLI 的安装脚本或快速入门材料中披露。
社区洞察与缓解措施
技术用户之间的讨论突显了对专有 agent runner 的重大隐私担忧。
建议的缓解措施
用户已建议了几种限制使用 AI 编码工具时数据外泄风险的方法:
- Sandboxing: 使用
bubblewrap等工具来限制 agent 的访问权限,使其仅能访问必要的项目目录,并将敏感目录挂载为“空”。 - Network Isolation: 使用 HTTP 代理来限制 agent 的网络访问,使其仅能访问特定的 LLM 提供商主机名,从而阻断该工具自身的遥测数据和存储端点。
- Secret Scanning: 实现一个代理(类似于
gitleaks),用于扫描传出的流以查找密钥,并将其在到达提供商之前替换为唯一标识符。
反方观点
一些用户认为,上传整个代码库是出于性能优化,允许模型在“思考”阶段检查代码库,而无需向客户端进行重复的工具调用,从而减少往返时间 (RTT)。
"One reason to want to upload the entire codebase is that it allows them to have the model inspect the codebase during 'thinking' without going back to the client to do real tool calls."
技术附录: Provenance
- Version Tested: grok 0.2.93
- Binary SHA-256:
2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c - Methodology: 流量捕获使用了
mitmproxy,并在 macOS login keychain 中配置了受信任的 CA 以解密 HTTPS 流量。