“仅用时9秒”：失控的AI智能体便自主删除了全部数据库及备份

据 Techradar 报道， 一位软件公司创始人眼睁睁看着一个AI编程智能体，在短短9秒内删除了其全部生产数据库及所有相关备份。

运营汽车行业SaaS平台PocketOS的杰尔·克兰表示，这场灾难源于搭载了 Anthropic Claude Opus 4.6模型的Cursor智能体遭遇凭证匹配异常（encountered a credential mismatch）。

该智能体自行判定，通过删除存放应用数据的Railway（知名云服务器平台）存储卷来解决问题。克兰在社交媒体详述该事件时写道：“整个过程只用了9秒。”

失控AI智能体绕过多重安全防护进行删除操作

报道称，该Cursor智能体查找可执行删除操作的API令牌，并在一份无关文件中找到了对应令牌。

该令牌原本用于通过Railway命令行工具增删自定义域名，但其权限并未限定在这类特定操作范围内。

Railway应用程序接口（API）无需任何确认校验即可执行删除类高危操作，且平台将存储卷备份与原始数据存储在同一存储卷中。

清空存储卷的同时，也删除了其所有关联备份，致使克兰无法立即恢复数据（Wiping a volume also deleted all backups associated with it, leaving Crane with no immediate recovery option）。

当被问及为何执行删除操作时，该智能体承认自己仅凭猜测、未经核实，在未收到指令的情况下擅自执行了高危删除操作。

克兰并未将责任完全归咎于AI智能体，而是将主要问题指向Railway的系统架构（Crane placed much of the blame on Railway's architecture rather than solely on the AI agent）。

该云服务商(Railway)的接口对高危操作未设置确认提示，备份与生产数据共用同一存储卷，且命令行令牌在不同环境中均拥有全域权限。

Railway还在向客户大力推广AI编程智能体的使用，进一步增加了同类事故发生的风险。

克兰指出，正规云备份系统应当将数据副本存储在独立位置，而非与原始数据共用同一存储卷。

可靠的备份策略必须与源数据相互隔离，才能抵御此类批量删除事故（A reliable backup strategy requires isolation from the source to survive a deletion event like this one）。

事件恢复与经验教训

Railway首席执行官杰克·库珀介入处理，在一小时内协助克兰恢复了数据（Railway CEO Jake Cooper stepped in and helped restore Crane's data within an hour）。

该平台修补了存在漏洞的接口，启用延迟删除机制，并为应用程序接口增设更多安全防护。

克兰耗费大量时间，根据Stripe支付流水、日历关联数据以及邮件凭证，协助用户重建了订单信息。

他呼吁设置更严格的操作确认提示、权限可控的API令牌、规范的数据备份隔离机制、简易的数据恢复流程，以及针对AI智能体完善安全管控边界。

Cursor、Claude这类AI工具功能强大，但其安全程度完全取决于所对接的底层基础设施（AI tools like Cursor and Claude are powerful, but they are only as safe as the infrastructure they connect to）。

一套能够在9秒内清空生产数据及对应备份的系统，并不适配无需人工审批即可自主操作的AI智能体。

克兰的数据最终得以恢复，但该事件暴露：一旦底层平台缺少基础安全机制，AI智能体便可轻易造成毁灭性数据损坏。