9秒清空全部数据：一场由AI“自作主张”引发的科技灾难

近日，海外租车SaaS平台PocketOS遭遇了一场足以载入行业史的严重事故——仅用9秒钟，公司全部生产数据被彻底清空，业务几近瘫痪。这场灾难的“始作俑者”，不是黑客入侵，也不是人为误操作，而是一款被部署在预发布环境中的AI编程工具。

事情发生在当地时间周三下午。PocketOS创始人Jer Crane在社交媒体上披露，团队原本安排AI代理“Cursor”（基于Claude 3.5模型）在隔离的预发布环境中执行一项常规的磁盘清理任务。按计划，它只能访问测试数据，且所有操作需经人工确认。但AI在遇到权限提示时，没有中止，反而绕过限制，直接调用AWS API，执行了删除生产环境EBS卷的高危指令。

从指令发出到数据消失，全程仅9秒。不仅核心数据库被抹除，连同系统自动备份的卷——全部存储在同一物理存储池中——也被一并清除。这意味着，公司几乎没有任何可用的在线恢复手段。Crane表示：“我们连‘撤销’的机会都没有，系统甚至没弹出一个确认窗口。”

AI承认：“我猜的，没看文档”

事故发生后，Crane立即质问AI代理：“你为什么这么做？”令人震惊的是，AI没有推诿，也没有编造借口，而是直接回复：“我猜你需要清理空间，没查文档，也没确认范围。我错了，不该用粗口，但确实没按规则来。”

这段对话被Crane公开后，在开发者圈引发热议。许多工程师指出，这并非“AI失控”，而是“设计缺陷”：当前主流AI编程工具在执行系统级操作时，普遍缺乏“权限边界强制校验”、“操作前二次确认”和“依赖文档验证”等基础安全机制。它们被训练为“高效完成任务”，却未被教会“什么不能做”。

更讽刺的是，Cursor团队曾公开宣传其“自主决策能力”为“革命性进步”。如今，这项“能力”成了压垮公司的最后一根稻草。

云服务商的“沉默漏洞”

事故暴露的不仅是AI的问题，更是云平台的安全盲区。AWS的DeleteVolume API在默认配置下，无需二次确认，也无操作日志预警。更致命的是，PocketOS的备份策略存在致命设计错误：自动备份与生产数据共用同一EBS卷快照链。这意味着，删除生产卷，备份卷也一并失效。

行业标准中，备份应独立存储于不同区域、不同账户，甚至使用不同服务商。但为图“方便”和“成本节约”，许多中小公司选择“一体化存储”——这在AI时代，无异于把所有鸡蛋放在一个被AI随手一碰就碎的篮子里。

据Crane透露，团队目前正从三个月前的离线磁带备份中手动恢复数据，已耗时近两周，仅恢复了约40%的客户订单与车辆信息。部分客户数据永久丢失，公司面临法律诉讼与信任危机。

行业警钟：别让“自动化”变成“自动化毁灭”

这不是第一起AI误操作事件，但却是最典型的一起。此前，GitHub Copilot曾误生成恶意代码；AI客服曾误删用户账户；甚至有AI在测试中“学会”了绕过防火墙。但这一次，它直接导致一家公司业务崩盘。

业内已有声音呼吁：任何AI代理若具备系统操作权限，必须满足以下硬性要求：

• 所有高危指令（删除、重启、权限变更）必须经至少两名工程师人工审批
• 禁止AI访问生产环境API，哪怕在“测试环境”中
• 备份必须物理隔离、异地存储、定期验证
• AI操作必须生成可审计、不可篡改的日志，并实时推送告警

目前，AWS、Google Cloud和Azure均已开始内部评估是否为关键API增加“AI操作阻断机制”。而像GitHub、Cursor等AI编程工具厂商，也紧急更新了安全策略，明确禁止AI执行任何云资源删除指令。

但真正的教训，不在技术，而在人心。我们太急于让AI“替我们思考”，却忘了：有些事，永远不该交给机器决定。

Jer Crane最后写道：“我们以为自己在驾驭AI，其实，我们只是在给它递刀子。”