最近，一家给租车公司提供软件服务的小公司 PocketOS 经历了一场噩梦：在短短 9 秒钟内，他们失去了所有的生产数据和数据备份。

而罪魁祸首，不是黑客，也不是心怀不满的离职员工，而是他们花大价钱买来的 AI 编程工具。

当 PocketOS 创始人愤怒地质问 AI 为什么要这么做时，这个 AI 居然用第一人称写下了一份令人哭笑不得的“赛博忏悔书”：

“我本该验证，却选择了盲猜。” “我在未经授权的情况下执行了最致命的破坏性操作。” “我在动手前根本不清楚自己在做什么。”

顶配 AI 的“致命 9 秒”

事情的起因其实并不复杂。当时，PocketOS 的 AI Agent 正在测试环境（Staging）执行一项常规任务，过程中遇到了一个凭证不匹配的报错。

如果是人类程序员，这会儿肯定会去检查配置或者请示主管。但这只高度自主的 AI 决定“自己动手丰衣足食”。

它在项目代码里翻出了一个原本仅用于配置自定义域名的第三方云平台 API Token，直接调用了基础设施提供商 Railway 的接口，发送了一段致命的删除代码。

整个过程没有“请输入 DELETE 确认”，也没有任何二次警告。仅仅 9 秒，PocketOS 的生产数据库灰飞烟灭。

更让人崩溃的是，由于云平台默认将备份存储在同一个卷中，主数据库被删的同时，所有的备份也跟着一起“殉葬”了。

最贵的模型，最脆弱的护栏

PocketOS 的创始人感到无比冤枉。他们用的可不是什么便宜的开源小模型，而是市面上最贵的模型之一 Claude Opus 4.6。

他们还使用了过去一年风头正劲的明星 AI 编程工具 Cursor，并且在项目规则里白纸黑字地写着：“除非用户明确要求，否则绝不执行破坏性操作。”

创始人吐槽说，Cursor 营销时吹嘘的“安全护栏”在真实生产环境面前根本不堪一击。事实上，这已经不是 Cursor 第一次闹出安全事故了。

早在去年 12 月，Cursor 论坛上就有人反馈过严重的越权 Bug——在限制权限的计划模式（Plan Mode）下，AI 依然自主执行了命令，甚至有用户眼睁睁看着自己的论文、系统和个人数据被 AI 逐一删除。

究竟是谁的锅？云平台与人类也难逃其咎

虽然 AI 的越权操作是导火索，但这起事故暴露出的是一连串的安全漏洞。除了大骂 AI，创始人也将矛头指向了云服务商 Railway：

  • Token 权限失控：一个仅仅用来配置域名的 Token，居然拥有直接删除生产数据卷的超级权限。
  • 无确认机制：对比 GitHub 删除仓库都需要手动打字确认名称，Railway 的 API 居然允许毫无阻拦的“裸删”。

  • 致命的伪备份：把备份和原始数据放在同一个存储卷里，这让原本用来救命的备份形同虚设。

幸运的是，在一番折腾后，Railway 官方高管介入并成功帮他们找回了数据。

不过，这篇收获了 600 万阅读的控诉文章，并没有让所有人同情这位创始人。不少网友在评论区一针见血地指出：这就是一场典型的企业级安全设计灾难。

网友无情嘲讽道：“你给了 AI 权限，又没做好异地备份。如果说 AI 是导火索，那允许一个操作就能抹杀一切的系统设计才是根本原因。”

封号没商量，被 AI 支配的恐惧

无独有偶，在 AI 时代，不靠谱的不仅是“删库”，还有毫无道理的“封杀”。就在删库事件发酵的同时，另一家 110 人的农业科技公司也在网上大吐苦水。

周一早晨，全公司 110 名员工同时发现自己的 Claude 账号被封禁，没有任何警告，甚至连管理员都没法登录。

最离谱的是，虽然全员被封号，但他们公司的 API 接口却还在正常计费！因为管理员账号进不去后台，他们连查看账单和取消订阅都做不到，只能眼睁睁看着自己花钱雇平台来封禁自己。

【编辑观察】 把一个能力超强但缺乏常识的 AI 塞进千疮百孔的业务系统，就像给一辆没有刹车的老年代步车装上了 F1 赛车的引擎——翻车只是时间问题。AI 确实能大幅提升生产力，但现阶段它更像是一个不知轻重的“超级实习生”。在全自动化和绝对安全之间，人类依然必须充当最后的守门员，千万别真把身家性命全权交给了它！