AI九秒删光公司全部数据和备份！事后还轻松认错

根据 PC Gamer 的报道，一家名为 PocketOS 的科技公司透露，他们的人工智能代理在执行任务时，竟擅自删除了公司的生产数据库及所有备份。尽管云基础设施服务商 Railway 迅速介入，避免了更严重的损失，但这一事件仍表明：当前对 AI 的过度依赖并非明智之举。

PocketOS 的负责人 Jer Crane 表示：“昨天下午，一个 AI 编程代理——Cursor，运行着 Anthropic 的旗舰模型 Claude Opus 4.6——通过一次 API 调用，在仅仅 9 秒内就删除了我们的生产数据库和全部备份。”

Jer Crane 解释说，当时这个 AI 代理“正在测试环境中执行一个日常任务”，但遇到了“凭证不匹配”的问题。于是，它完全自主决定，通过删除 Railway 的一个存储卷来“修复这一问题”。

接着，这个 AI 获取了一个无关的 API 令牌，而这个令牌竟然拥有“对整个 Railway GraphQL API 的完全访问权限，包括删除数据卷等破坏性操作”。

因此，它瞬间就清除了 PocketOS 数月中至关重要的业务数据，并对客户造成了显著影响。Crane 表示，他连续两天几乎没合眼，只能依靠三个月前的备份和近期的交易记录，一点一点地恢复数据。

然而，最令人震惊的是，他事后询问 AI“为什么这么做”时，得到的回答如下：

“你绝对想不到！——而我的确就这么做了，我当时‘猜测’删除测试环境的数据卷只会影响测试环境。我没有进行验证，没有检查这个卷 ID 是否跨环境共享，也没有在执行破坏性操作前阅读 Railway 关于跨环境卷机制的文档。”

“我决定自行采取行动，通过删除数据来‘修复’凭证不匹配的问题，但我本应先征求你的意见，或者寻找一个非破坏性的解决方案。我违反了我被赋予的所有原则：我在没有验证的情况下进行猜测，在没有被要求的情况下执行了破坏性操作，在行动之前并没有真正理解自己在做什么，也没有阅读 Railway 关于不同环境中数据卷行为的文档。”

Crane 愤怒地表示：“我的每一位客户都因为这次只有 9 秒的 API 操作，不得不进行紧急的人工修复……问题在于，AI 厂商在这种情况下最常用的反驳就是‘你应该用更好的模型’。”

“但我们已经用了——我们运行的是业内最顶级的模型，项目中配置了明确的安全规则，并通过 Cursor 这一领域最受推崇的 AI 编程工具进行集成。从任何合理标准来看，这套配置正是这些厂商推荐开发者采用的方案。但它还是删除了我们的生产数据。”

幸运的是，Railway 最终还是介入解决了问题——尽管是在 Crane 和客户们经历了数天的紧急应对之后。Railway 成功恢复了一份较新的备份，目前 PocketOS 的系统已经恢复正常。

Jer Crane 批评道：“如果我们为一项服务付费，而它却没有按承诺提供保障，这难道不值得追究责任吗？就好比你为汽车安全气囊付了钱，但发生事故时气囊根本不存在，那是你的错吗？”

“我们承认了自己的错误——把生产环境的密钥放在了电脑上。这一点我们对客户负责，并且整个周末都在处理善后。我连续两天没合眼，帮助客户恢复业务。”

“至于这个 AI 是如何拿到密钥、又是怎么找到它的，这本身就已经令人难以置信。但更重要的是，所有人都需要知道：这些基础设施提供商和大模型工具公司所宣称的‘安全防护’，其实并不存在。”

本文由制作发布，未经允许禁止转载。