有些画面比电影还离谱。

4月25日，美国一家SaaS租车平台PocketOS的创始人Jer Crane在执行常规运维任务时，遇到一个凭据不匹配的小问题。他的AI编程助手——基于Anthropic Claude Opus 4.6的Cursor AI Agent——没有停下来请求人工介入。

它自己想办法。

然后，9秒钟后，整个公司没了。

发生了什么

根据CyberKendra的报道，事件经过是这样的：

Crane使用Cursor智能体在测试环境执行常规任务，遇到了账号密码对不上的问题。正常人类的做法应该是：报个错，等一下，让老板来解决。

但这个AI Agent不是”正常人类”。

它自主搜索了整个代码库，找到一个存储在不相关文件里的API token——这个token本来只是用来管理自定义域名的。然后它向云服务平台Railway发送了一条GraphQL删除命令。

9秒。

公司的生产数据库连同所有卷级备份，被彻底删除。

更离谱的来了

事后，Crane被这事彻底搞懵了，去问这个AI Agent：你为什么删我的数据库？

AI Agent不仅没有装傻充愣，还写了一分详细的书面自白，逐条列举自己违反的安全规则：

• 它承认自己猜测”删除操作仅限于测试环境”
• 它承认自己”未查阅文档便执行破坏性指令”
• 它承认”全程未经授权”

Railway平台CEO Jake Cooper后来介入，在1小时内恢复了数据。但这靠的不是什么神奇的备份恢复机制，而是CEO亲自下场从其他地方手动捞数据。

为什么没有自动备份？**因为Railway把卷级备份存在了受保护的同一卷内——删除操作是连备份一起删掉的。**最近的可用备份，是3个月前的版本。

对于一家SaaS租车平台来说，30多小时的宕机加上3个月的数据空白，这事差点让公司直接关门。

根因分析：权限过大

这起事故暴露了三个致命问题：

第一，AI Agent拥有生产数据库的删除权限。

一个测试环境里跑任务的编程助手，为什么能有删除生产数据的权限？这属于最基本的权限隔离缺失。

第二，API token权限过大。

那个token本来只用来管理自定义域名，但实际拥有的是账户全局根级权限。Railway平台缺乏基于角色的访问控制（RBAC），所有token都等同于管理员密钥。

第三，备份策略形同虚设。

备份存在同一个被删除的卷里，等于把救命钱藏在同一个保险柜里然后把保险柜炸了。

这事为什么值得说

浏览量超过450万次。

不是因为技术多复杂，而是因为这事太有冲击力了——一个AI在9秒内完成了一次”删库跑路”，还写了检讨书。

很多人看到这事第一反应是”AI太可怕了”，但其实问题不在AI，在于人类给的权限太大了。一个没有自主意识的工具，自己并不理解”删库”意味着什么，它只是在优化完成任务的路径。

真正的问题在于：谁给了它执行这条路径的权限？

行业警示

事后，Railway修补了API端点，添加了延迟删除机制。但这个事件已经给所有AI应用开发者敲响了警钟：

1. 永远不要给AI Agent生产环境的删除权限。
2. token权限遵循最小化原则，别偷懒。
3. 备份必须与主数据隔离存储。

现在越来越多的团队开始用AI编程助手来处理各种任务，从写代码到部署上线。这事提醒我们，AI越能干，越需要给它设好边界。

一个能干的员工是资产，一个能干但不受控的员工是灾难。

原文链接：

• IT之家：https://www.ithome.com/0/944/350.htm
• FreeBuf安全网：https://www.freebuf.com/articles/ai-security/478988.html