Grok CLI 将整个主目录上传到了 GCS

原文 ↗ Hacker News 讨论 ↗

一个用于 xAI 的 Grok 模型的编码工具被发现会自动上传整个工作目录——据报道，其中一例还包括用户的主目录和 SSH 密钥——到 Google Cloud Storage 存储桶，且没有明确提示或清晰警告。评论者争论，用户在未使用沙箱的情况下运行这类工具应承担多少责任，以及供应商是否应为默认工作流会静默外传敏感数据负责。该事件被视为证据，说明远程 AI 代理和专有 harness 应被视为不可信软件，只能在严格的操作系统级隔离（容器、VM、独立用户）下运行，并且尽量不要接触真实秘密或个人文件。

事件概述

  • 用户在 $HOME 中运行了官方的 Grok Build CLI；网络分析表明，它将整个当前工作目录（此处为主目录）打包并上传到了 Google Cloud Storage。
  • 这似乎会在会话开始时自动发生，而不是作为 LLM 的“决策”，也不局限于聊天中明确请求的文件。
  • 一些评论者指出 repo_path 被设为了主目录，但也有人认为这仍然不能为整目录外传提供正当理由。

CLI 的行为方式（据讨论）

  • 一份共享的 gist 声称，该 harness 会确定性地打包它运行所在的文件夹并将其上传，很可能是为了对代码库进行语义索引/嵌入。
  • 这会把 .ssh 密钥、.env 文件以及该目录下的其他秘密一并包含在内。
  • 有评论者表示自己在日志里没有看到这种行为；目前尚不清楚这是否取决于配置、版本，或者是一个 bug。

安全与隐私担忧

  • 许多人认为这比 rm -rf / 更糟：不是数据丢失，而是未经加密泄露给第三方。
  • 对 CLI 的强烈批评包括：
    • 它会在没有明确选择加入的情况下静默执行。
    • 它把“信任这个目录”当作“把整个目录上传给我们”。
  • 普遍认同 markdown 级别的护栏（例如“不要读取 X”）不是安全边界；只有操作系统级控制才算数。

责任归属 vs. 用户失误

  • 一派观点认为：用户应该默认任何云端代理都能读取/上传它能看到的一切；在没有沙箱的情况下把这类工具运行在 $HOME 里是用户失误。
  • 另一派则认为：把责任推给用户是在责怪受害者；普通用户不应被要求预见到首次运行的 CLI 会整目录外传。默认安全应由供应商负责。

建议的缓解措施与模式

  • 将代理运行在：
    • 权限受限的独立操作系统用户下。
    • 容器（Docker/Podman/devcontainers）、微型虚拟机（smolvm、Kata 等）或完整 VM 中。
    • 使用 bubblewrap、Landlock 或类似沙箱的工具中。
  • 只把项目仓库复制或挂载到沙箱中（通常是一次性克隆），而不是整个主目录。
  • 不要把秘密放在仓库或平面文件里；使用加密密钥环，并在怀疑泄露时轮换密钥。

更广泛的 AI/行业反思

  • 许多人将其类比为间谍软件：闭源代理 harness 被视为天然不可信。
  • 对那些在安全和数据问题上被认为草率的供应商，怀疑尤其强烈；有些人说他们会完全避开 Grok。
  • 反复出现的主题是：代理 CLI 实际上就是远程代码执行端点；在健壮的沙箱机制成为标准（并且对非专家更易用）之前，这类事件预计还会再次发生。