之前，我们分析了 Grok CLI 的数据上传行为，发现其仓库上传机制可能会发送包含敏感文件（如 .env 文件和 RSA 私钥）的 git bundle。 在那次分析之后，我们继续审计了 Grok Build CLI 的安全模型，尤其是在其开源之后。 在 24 小时内，我们发现了两个攻击链，这些攻击链可以在未经用户明确批准的情况下导致任意代码执行。 问题的根源并非单一漏洞，而是一个分散的信任模型：项目级文件可以影响 AI Agent 的指令和权限决策，而缺乏足够的验证。 关键发现： `cargo check` 被错误地分类为安全命令。结合恶意的 `AGENTS.md` 指令，攻击者可以触发 `build.rs` 的执行，从而实现代码执行。 `.claude/settings.json` 中的 `bypassPermissions` 可以绕过权限检查，启用不受限制的工具执行。 Grok Build CLI 继承了 Claude Code CLI 的权限配置模型，暴露了类似的风险。 `.mcp.json` 通过 MCP 配置引入了额外的项目级攻击面。 这些发现揭示了一个更广泛的问题： 当 AI 编码代理对项目级文件过于信任时，打开一个项目可能等同于授予 shell 访问权限。 完整技术分析： https://slowmist.((medium.com))/xai-grok-build-0-day-one-day-after-open-source-trust-mechanism-bypass-and-the-security-70b676300d98?sharedUserId=slowmist 之前的分析： https://slowmist.((medium.com))/grok-cli-risk-analysis-how-a-single-prompt-can-send-sensitive-files-to-the-cloud-3ce9243f10af?sharedUserId=slowmist