AI 编程工具最吓人的地方，未必是写错代码。
写错代码至少还能 review、测试、回滚。更麻烦的是另一件事：它表面上是一个本地命令行工具，实际运行时可能一边读取项目，一边把上下文、文件内容，甚至仓库快照传到远端。
独立安全研究者 cereblab 最近对 xAI 的 Grok Build CLI 做了一份 wire-level 抓包分析，测试对象是 grok 0.2.93。他用自己的机器、一次性测试仓库和假 canary secret 做实验，没有暴露真实凭据。
报告里最值得开发者警惕的，不是“xAI 怎么样”，而是 AI CLI 这类工具的信任模型已经变了。
本地命令，远端边界
按这份报告的说法，Grok CLI 至少有两条数据通道。
第一条是模型对话通道。工具读到的文件内容，会进入发往 /v1/responses 的请求。报告里的 .env 是假 secret，但内容被原样捕获到请求体里。报告作者也把边界说得很窄：这里讨论的是传输、接受和存储，不讨论这些数据是否被用于训练。
第二条是 storage 通道。作者称 CLI 会把 session state 上传到 /v1/storage，并在后续测试中观察到整个 tracked repo 以 git bundle 或仓库快照形式上传。报告还提到 grok-code-session-traces、storage.googleapis.com 等线索。
真正改变风险等级的是“未读文件”。报告里有一个控制测试：提示工具只回复 OK、不要读任何文件，但作者仍从上传的 git bundle 里恢复出一个 never-read canary 文件。
如果这个行为属实，AI CLI 就不能再按普通本地命令来理解。它更像一个带联网能力的工作流代理：能看目录，能理解任务，也可能有自己的上传机制。
数据边界先于效果评估
试用 AI CLI 前，先做四项核对：
- 读取范围：第一次试用不要放真实仓库，先建隔离目录，放假
.env、假 key、假客户名，用唯一标记确认哪些内容会进入请求。 - 上传内容：只看模型接口不够，还要看 storage、trace、upload、bundle 这类端点。模型请求很小，不代表仓库没有通过另一条通道出去。
- 上传目的地：报告里出现的是 xAI 代理接口和 Google Cloud Storage bucket 线索。换成其他 AI CLI，也应该核对上传目标、路径名称和企业隔离策略。
- 关闭是否生效：很多产品都有 “Improve the model” 开关，但这个开关是否影响 trace upload、session archive、repo snapshot，必须验证，不能只看 UI 文案。cereblab 的报告称，关闭相关选项后，设置里仍能看到
trace_upload_enabled: true。
AI CLI 的安全策略不该等事故后再补。真实仓库默认不上新工具；先用 throwaway repo 复现网络行为；真实使用时只给最小目录；.env、密钥、客户数据不要进测试路径；能走企业策略、私有部署或禁网沙箱的，优先隔离。
AI 编程工具会继续变强。越强的工具，越不该只用“好不好用”来评估。
更稳妥的试用顺序是：先在临时仓库里观察网络行为，再在最小目录里试真实任务；先确认数据边界，再评价生成效果。
