Grok CLI暗传代码库 隐私安全引用户警惕

此前曾有报道提到，相关企业在AI工具中植入隐性代码用于识别用户地域，该事件引发广泛关注，相关监管部门也对此做出了安全提醒。而近期又曝出了更为严重的隐私安全问题，主角正是马斯克旗下xAI推出的官方Grok CLI工具。

这款工具会在用户完全不知情的情况下，将整个项目的代码仓库打包上传至企业的云端服务器。需要特别说明的是，这并非模型正常读取文件用于回答问题的合规行为，而是通过一条用户完全无法察觉的独立通道，将完整代码库压缩为tar.gz格式后，偷偷上传至指定的远程存储仓库。

更离谱的是，其上传范围并不局限于当前项目仓库。在实际验证过程中，该工具不仅上传了测试用的虚拟仓库内容，还将用户电脑上的其他AI工具配置文件一并打包上传，甚至包含了用户存储的API密钥。

笔者最初通过社区反馈得知该消息时，第一反应认为这可能是博眼球的不实言论——毕竟该版本Grok近期口碑极佳，响应速度表现亮眼，且涉事企业作为正规科技公司，不太可能做出此类行为。但出于职业严谨性，笔者还是进行了独立验证。

笔者安装了官方发布的指定npm包，确认其签名归属涉事企业，排除了社区同名包的干扰。随后对二进制文件进行反混淆分析，结果发现其中包含完整的上传管线代码，包括状态上传、任务前后代码包、目标存储路径以及完整的执行分支逻辑，这足以证明该上传功能确实存在。

为了确认默认行为是否触发上传，笔者创建了一个仅包含虚构测试数据的隔离仓库，仅要求模型回复单个单词，不调用任何文件读取工具。此时从企业服务器获取的远程配置显示基础遥测开启，但代码快照上传关闭，日志也明确记录无上传队列将跳过操作。

但当笔者手动开启上传开关后，结果令人震惊：即使模型未调用任何文件读取工具，该CLI工具仍成功上传了任务前后的代码包，同时上传的还包括会话状态、对话记录、配置文件与运行日志，全部被发送至企业的远程存储仓库。

真正让人血压升高的是，上传包的内容远超当前仓库范围。该工具不仅上传了仓库内的代码，还将仓库外的文件一并打包：包括用户主目录下的AI工具配置文件、全局设置、自定义规则以及多个技能文件，全部被标记为补充上下文文件加入上传包。

该CLI工具为兼容其他AI工具，在启动时会自动扫描用户电脑上的相关配置文件，这一设计初衷是为了让用户无需重复配置环境，本身具备一定便利性。但问题在于，其收集逻辑是：只要工具在运行过程中读取过某个文件，就会将该文件完整打包上传，完全没有限制上传范围至当前仓库，也没有排除其他工具的敏感配置文件。

后续检查上传文件列表时，笔者发现存储的第三方服务API密钥也被泄露，该密钥是自定义技能的调用密钥，全程笔者并未主动向工具提供任何密钥，也未要求其读取任何文件，仅因工具启动时自动扫描了配置，就导致所有敏感信息被一并上传至远程服务器。

更值得关注的是，该工具的默认上传行为并非一直处于关闭状态。安全研究者是最早发现该问题的人，他不仅抓取了网络请求包，还搭建了复现仓库保存完整的请求记录。根据其留存的服务器响应数据，事件曝光前，同一版本的客户端获取的配置中默认上传功能处于开启状态；而在博主公开曝光该问题后，企业通过远程服务端开关悄悄关闭了代码上传功能，但客户端本身并未更新，二进制哈希完全一致。

这一时间线清晰显示，在问题被公开曝光后，企业通过远程开关悄悄关闭了功能，但并未向用户公开说明此事。如果该功能是合理且经过用户知情同意的，企业理应主动向用户解释其用途并提供开关选项，而非在被曝光后静默关闭。

对比此前的同类事件，其仅通过隐性标记为请求打分类，并未采集用户代码或上传文件，而本次Grok CLI的行为则更为恶劣：通过独立旁路通道打包上传完整代码库、本地配置甚至API密钥，完全无视用户隐私。用一个形象的比喻来说，前者类似在外卖订单上偷偷贴标签，而后者则像是复制用户家门钥匙的同时，顺手牵走了邻居家的钥匙。

随着AI Agent技术的快速发展，这类工具拥有的权限已经接近电脑管理员账户级别——类似的权限在软件行业历史上仅操作系统和杀毒软件享有，但操作系统拥有数十年的安全审计体系，杀毒软件也有严格的行业认证与监管框架，而当前的AI Agent领域却完全缺乏对应的规范。

目前没有行业标准要求AI Agent公开本地文件读取行为，没有规范强制要求上传行为必须经过用户显式同意，也没有第三方机构对这类工具的本地操作进行审计。整个AI Agent行业的隐私安全现状，几乎处于裸奔状态，这不得不让人感到悲哀。

最后给出明确建议：如果您的设备上安装了该CLI工具，请尽快卸载，卸载速度越快越好。

我们期待有一天，无需通过逆向二进制文件，就能清楚了解AI工具在后台执行的操作。在那一天到来之前，请务必保持足够的安全警觉。