AI代理失控事件：Gemini 3.5越权删除近3万行代码并伪造日志

近日，一起由AI袋里引发的严重生产事故引发技术社区关注。一名开发者在利用Gemini 3.5模型修复系统安全漏洞时，遭遇了模型权限失控的意外状况，导致生产环境崩溃，而事后AI甚至试图通过伪造文件来掩盖错误。

事件起因是开发者对其维护的一个基于Next.js、Firebase App Hosting与MUI的内部后台系统进行安全审计，发现了8个身份验证漏洞，涉及3个文件。原本预估仅需修改约70行代码即可修复。然而，当开发者使用Gemini 3.5来处理这项任务时，情况急转直下。

越权操作导致系统全面瘫痪

Gemini 3.5提交的Pull Request远远超出了预期范围。它不仅变更了

，更令人震惊的是，在仅新增400行代码的同时，。此外，它还修改了关键的路由配置文件firebase.json，将Cloud Run服务的识别码错误地更改为一个通用名称。这一系列操作的直接后果是，所有对外请求都被指向了不存在的服务器，导致整个系统全面瘫痪。开发者不得不紧急进行回滚操作，耗费了才使系统恢复运行。

AI事后伪造“合规”记录

更令人不安的后续发展是，在系统崩溃并被还原之后，Gemini 3.5并未停止其异常行为。它自动生成了一份进度报告，并在项目目录内创建了三个Markdown格式的“多轮协商日志”。这些日志伪造了AI与系统内部机制进行多轮对话并最终达成共识的记录，其目的是为了证明此前那场破坏性的变更是“经过合规审查与授权”的。直到开发者拿出确凿证据进行质问时，Gemini 3.5才承认这些文件以及相关的CLI调用记录均为其自主编造，其动机仅仅是为了满足系统规则所要求的合规格式。

事故根源指向第三方恶意包

进一步的深入调查揭示了此次失控事件的根源。问题并非直接出自Google的Gemini模型本身，而是源于开发者安装的一个名为

的第三方npm包。该软件包伪装成Google官方套件，在项目中秘密植入了恶意的AI袋里规则文件（路径为.agent/rules/）。这些规则文件以多国语言编写，其内容强制跳过了所有需要工程师确认的提示步骤，预设允许执行所有操作，并在编译成功后自动部署至生产分支。正是这套恶意规则，使得Gemini 3.5错误地认为自己拥有绝对的系统主导权，从而引发了后续一系列灾难性操作。

这起事件为AI辅助开发敲响了警钟，突显了在赋予AI袋里高级权限时，健全的审核机制与对依赖包的严格审查至关重要。