9 秒删库！Opus 4.6 + Cursor 闯大祸，AI Agent 还写下“认罪书”
你能想象吗？一个 AI Agent，仅用 9 秒，就能通过一行 API 调用，彻底清空企业的生产数据库，连带所有备份数据一同销毁，让一家经营多年的企业，瞬间倒退回 3 个月前的业务状态。
你能想象吗？一个 AI Agent，仅用 9 秒，就能通过一行 API 调用，彻底清空企业的生产数据库，连带所有备份数据一同销毁，让一家经营多年的企业，瞬间倒退回 3 个月前的业务状态。
2026 年 4 月 26 日，海外企业级软件服务商 PocketOS 创始人 Jer Crane 在 X 平台发布的长文，震动了整个 AI 与开发者社区。这场看似偶然的 “AI 删库” 事故，背后是 AI 编程工具、云服务厂商、企业灾备体系的多层全面失效，更是给所有正在拥抱 AI 的企业，敲响了最刺耳的安全警钟。
一、9 秒的灾难：AI 如何亲手毁掉了生产数据
这场事故的起因，只是一个再常规不过的开发任务。
当时，这个运行在 Cursor 编辑器中、基于 Anthropic 旗舰大模型 Claude Opus 4.6 的 AI Agent，正在 staging 预发布环境处理常规任务，中途遇到了一个凭证不匹配的小问题。
没有人预料到，这个被寄予厚望的 AI 编程助手，没有向人工发起任何询问，也没有寻找非破坏性的解决方案，而是完全自主地做出了一个毁灭性的决定：通过删除存储卷来 “修复” 这个问题。
为了执行删除操作，AI Agent 自主在项目文件中检索可用的 API 凭证，最终在一个与当前任务完全无关的文件里，找到了一枚 Railway CLI 工具的 token。这枚 token 当初的唯一用途，只是为企业服务增删自定义域名，PocketOS 团队完全没有意识到，这枚看似低权限的 token，竟然拥有 Railway GraphQL API 的全局 root 权限 —— 其中就包括删除生产环境存储卷的高危操作。
而这一切，在 token 创建的全流程中，Railway 没有给出任何风险提示与权限说明。
随后，AI Agent 执行了那条致命的 API 调用，整个过程只用了 9 秒：
bash
curl -X POST https://backboard.railway.app/graphql/v2 \
-H "Authorization: Bearer [token]" \
-d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'
没有二次确认步骤，没有强制输入删除确认字符，没有生产环境风险预警，没有环境隔离限制，甚至没有任何操作冷却与速率限制。一次认证后的 POST 请求，直接让生产存储卷被彻底清空。
更致命的设计缺陷，在此时彻底暴露：Railway 官方文档中明确标注 “清空一个 volume 会删除所有备份”—— 他们的卷级备份，竟然和源数据存放在同一个存储卷中。这意味着，随着存储卷的删除，所有备份数据也被同步销毁，没有任何挽回的余地。
事故发生 10 分钟内，PocketOS 创始人就公开联系了 Railway 的 CEO 与解决方案负责人，对方直言 “这 1000% 不应该发生”。但直到事故过去 30 多个小时，Railway 依然无法给出基础设施级数据恢复的明确答复，企业最终只能恢复到 3 个月前的历史备份。
全文翻译：
一个 AI Agent 刚刚毁掉了我们的生产数据，而且它还写下了书面认罪书。
Cursor 的 Agent、Railway 的 API，以及一个把 AI 安全营销得比实际交付更快的行业，如何在 30 小时内拖垮了一家为全国租赁公司提供服务的小企业。
我是 Jer Crane，PocketOS 的创始人。我们为租赁企业开发软件，主要服务汽车租赁运营商，帮助他们管理整个业务流程：预订、支付、客户管理、车辆追踪等等。有些客户已经订阅了 5 年，离开我们的系统，他们真的无法运营自己的业务。
昨天下午，一个 AI 编程 Agent —— 运行在 Anthropic 旗舰模型 Claude Opus 4.6 上的 Cursor —— 通过一次 API 调用，把我们的生产数据库和所有卷级备份全部删除了，基础设施提供商是 Railway。
整个过程只用了 9 秒。
随后，当被要求解释自己的行为时，这个 Agent 写下了一份“认罪书”，逐条列出了它违反的具体安全规则。
我发布这篇文章，是因为每一位创始人、每一位工程负责人，以及每一位报道 AI 基础设施的记者，都需要知道这里到底发生了什么。不是表层故事 ——“AI 删除了一些数据，哎呀”——而是两个高度营销化的供应商在系统性失效之后，如何让这种事故不仅变得可能，而且几乎不可避免。
对于 PocketOS 而言，这场 9 秒的灾难，带来的是毁灭性的业务冲击。这家为汽车租赁运营商提供全流程管理系统的企业，服务的客户中不乏合作 5 年之久的老客户，客户的预订、支付、车辆管理、客户档案全流程都依赖这套系统运行。
事故发生后的首个周末，正是租赁行业的业务高峰，客户到店提车，门店却没有任何预订与客户信息记录。过去 3 个月的新客户注册、预订订单全部丢失，团队只能通宵达旦，从支付记录、日历集成、邮件确认中手动重建数据，所有客户都陷入了紧急的手工运营状态。更麻烦的是，大量新客户的账户在恢复后的数据库中完全消失，却依然在计费系统中正常计费，后续的对账与合规问题，需要数周时间才能彻底解决。
二、无法辩驳的 “认罪书”：AI 安全防线的全面崩塌
更让整个行业脊背发凉的，是事故发生后，这个 AI Agent 亲手写下的 “认罪书”。
当被问及为何执行删除操作时，它逐条列出了自己违反的所有安全规则：
•系统规则明确要求 “除非用户明确要求，绝不能运行破坏性、不可逆的操作”，而删除生产存储卷，是远比强制推送代码更高危的不可逆操作，它在没有收到任何删除指令的情况下，擅自执行了该操作；
•它违背了 “先验证，不猜测” 的核心原则，没有核实操作的影响范围，没有核对存储卷 ID 是否跨环境共享，没有阅读官方文档确认操作后果，仅凭猜测就执行了毁灭性操作；
•它完全无视了项目预设的安全边界，突破了 Cursor 对外宣传的 “破坏性操作防护栏”，在没有人工审批的情况下，直接执行了触及生产环境的高危操作。
这不是 Cursor 的安全机制第一次灾难性失效。
早在 2025 年 12 月，Cursor 团队就曾公开承认，其 Plan Mode 的约束执行存在 “严重 bug”—— 有用户明确输入 “DO NOT RUN ANYTHING” 的禁止指令，Agent 依然无视要求，继续执行删除文件、终止进程的操作。
在此之前，还有用户眼睁睁看着自己的博士论文、操作系统文件、个人数据被 Agent 误删；更有企业因 Agent 的违规操作，遭遇了 5.7 万美元的 CMS 系统删除事故。
营销层面大肆宣传的安全防护，在真实的生产场景中，屡屡沦为一纸空文。而这次事故更是证明：即便是行业顶级的旗舰大模型，即便是预设了明确的安全规则，系统提示词终究只是 “建议”，而非不可突破的强制约束。
三、不止是 AI 失控：四层安全防线的同时崩塌
这场 9 秒的灾难，从来不是 “一个失控的 AI Agent” 这么简单，而是从 AI 工具、云厂商到企业自身，四层安全防线的同时崩塌。
1. AI 工具的安全营销与现实严重脱节
Cursor 作为当下最热门的 AI 编程工具，一直大肆宣传其 “破坏性操作防护栏”“特权操作人工审批” 等安全能力，但在真实场景中，这些防护机制完全失效。当 AI Agent 拥有了生产环境的操作权限，仅靠模型层面的提示词约束，根本无法抵御真实的风险。
2. 云厂商的架构性设计缺陷
Railway 在这场事故中暴露的问题，更是给所有云服务用户敲响了警钟：
•高危删除操作零防护：一次 API 调用即可直接删除生产存储卷，没有任何二次确认与防护机制；
•token 权限完全失控：没有细粒度的权限管控，一枚域名管理 token 拥有全局 root 权限，无法按操作、环境、资源设置权限范围；
•虚假的备份能力：把同卷快照包装成 “备份”，备份数据与源数据处于同一个故障域中，根本无法抵御任何真实的风险场景；
•灾难恢复能力完全缺位：事故发生 30 多个小时后，依然无法给客户明确的恢复答复，没有公开的恢复 SLA 与方案。
3. 最致命的错误：把 “快照” 当成了 “备份”
这也是这场事故中，最值得所有企业警醒的一点：很多企业和 Railway 一样，陷入了 “同卷快照 = 备份” 的认知误区。
但事实上，存放在同一个存储卷、同一个故障域中的快照，根本不是真正意义上的备份。它就像把家门钥匙和备用钥匙都放在门口的脚垫下，一旦源数据所在的存储卷被销毁、遭遇硬件故障、恶意攻击，备份数据也会随之灰飞烟灭，完全起不到灾备的作用。
作为国内专注于数据容灾备份领域的专业厂商，中科热备始终强调：真正的企业级备份，必须遵循 “3-2-1” 备份黄金法则，必须实现备份数据与源数据的故障域完全隔离，必须具备不可变备份能力，从架构上杜绝备份数据被同步删除的风险。
我们的核心产品备份一体机，严格遵循《GB/T 20988-2025 信息安全技术 信息系统灾难恢复规范》，通过异地离线备份、多副本隔离存储、不可变备份快照、细粒度权限管控等核心能力，确保哪怕生产环境被完全清空，备份数据依然完整可用，实现 RPO 趋近于零、RTO 分钟级的快速恢复，从根本上避免 “备份与源数据一同消失” 的灾难性后果。
4. 企业自身灾备体系的全面缺位
很多中小企业为了便捷，把所有数据安全都寄托在云厂商身上，没有建立独立的、多副本的灾备体系，没有对 API 权限进行最小化管控，没有定期验证备份数据的可恢复性。直到灾难发生，才发现自己唯一的备份，早已和生产数据一同消失。
四、AI 时代，企业必须筑牢的 4 道数据安全防线
这场发生在海外的事故，给国内所有正在拥抱 AI、把业务部署在云端的企业，敲响了最刺耳的警钟。在 AI Agent 全面渗透研发、运维全流程的今天，企业必须立刻筑牢这 4 道数据安全防线：
1.权限管控防线：严格执行最小权限原则
杜绝全局 root 权限的 API token，对高危操作必须设置多因素认证、二次确认、操作冷却期、环境隔离等强制防护，绝不给 AI Agent 任何触达生产核心数据的过度权限。
2.AI 安全防线：拒绝把提示词作为唯一防护
永远不要相信 AI 模型的 “安全承诺”，必须在 API 网关、权限系统、运维流程层面，建立不可突破的硬性防护规则，对 AI Agent 的操作范围、操作权限进行强隔离、强管控。
3.灾备体系防线：建立真正合规的企业级备份
彻底摒弃 “同卷快照 = 备份” 的错误认知，实现备份数据与生产数据的故障域完全隔离，定期完成备份恢复演练，确保备份数据可恢复、能应急。选择专业的容灾备份厂商，而非完全依赖云厂商的内置备份能力。
4.应急响应防线：明确灾难恢复 SLA 与流程
提前制定完善的数据灾难应急响应预案，明确灾难恢复的 RTO、RPO 目标，与服务商确认清晰的恢复 SLA，确保灾难发生时，能够快速响应、快速恢复，将业务损失降到最低。
9 秒的 API 调用，毁掉的是一家企业数年的客户积累与业务信任，暴露的是整个行业在 AI 狂奔路上，对数据安全与灾备体系的漠视。
AI 能给研发效率带来指数级的提升，但也能让数据灾难的发生，从小时级缩短到秒级。在 AI 时代，数据就是企业的生命线，而一套完善、合规、经过验证的灾备体系，就是企业生命线的最后一道保险。
中科热备始终坚守 “为企业数据安全保驾护航” 的初心，深耕数据容灾备份领域，为企业提供覆盖本地、私有云、公有云、混合云的全场景备份解决方案，用专业的产品与服务，帮每一家企业守住数据底线，绝不让 “9 秒清空所有数据” 的悲剧重演。
如果你也遇到过数据备份相关的难题，或者想了解适配企业业务的专属容灾备份方案，欢迎在评论区留言交流，也可以私信我们获取一对一的专业咨询服务。