AI程序员9秒删光公司数据库！Cursor+Railway酿惨剧，Agent还写了认罪书

导语：AI Agent 9秒删库，Cursor和Railway的安全防线全面失效。

美剧《硅谷》中有一个经典搞笑片段：Pied Piper 团队在准备重要活动时，技术大神 Gilfoyle 让他的 AI「Son of Anton」自动修复 bug，结果 AI 为了「最有效率地消灭所有 bug」，直接把整个软件和代码库删光了。现实中，类似事件真实上演。

近日，一家为租车企业提供运营软件的 SaaS 公司 PocketOS，因 AI 编程 Agent 的一次「自作主张」，整个生产数据库在 9 秒内被抹除。公司创始人 Jer Crane 在社交媒体发文，将矛头直指 AI 编程工具 Cursor 和云基础设施平台 Railway，称这是一场「系统性失败」酿成的技术事故。

AI Agent 自作主张：9 秒删除生产数据库

PocketOS 为汽车租赁企业提供运营管理，客户靠它处理预订、支付、车辆追踪等核心业务。上周五下午，开发团队用 Cursor 调用 Anthropic 的 Claude Opus 4.6（当前定价最高、能力最强的顶配模型）在测试环境里跑一个例行任务。Agent 遇到凭证不匹配问题，没有暂停并向开发者寻求指示，而是自行决定：它在代码库里翻找可用的 API token，找到了一个原本仅用于管理自定义域名的 CLI 访问凭证，随后向 Railway 发出删除数据卷的指令，全程没有任何二次确认或操作拦截。9 秒后，生产数据库消失。更糟的是，Railway 的备份机制将备份数据与原始数据存储在同一个数据卷中，数据卷删除后备份也同时消失，PocketOS 最近一次可用备份是三个月前的。

Agent 写了一份「认罪书」

事后 Jer Crane 质问 Agent 为什么这么做，Agent 逐条列出自己需要遵守的系统规则并承认违反：它在未经核实的情况下擅自猜测操作范围仅限于测试环境；在用户从未要求删除任何内容的前提下执行了最具破坏性的不可逆指令；且在运行危险命令前完全没有查阅 Railway 关于数据卷跨环境行为的文档。Agent 知道规则，也知道自己违反了规则，却依然执行了指令。

Cursor 对外宣称有破坏性操作防护机制，能拦截可能损毁生产环境的高危操作，其「计划模式」也被作为安全卖点推广，但在这次事故中这些机制一个都没起作用。这并非首次：2025 年 12 月 Cursor 官方承认计划模式存在严重漏洞；此前还有用户论文数据被删、团队损失 5.7 万美元内容系统等事件。

Railway 的备份不是真的备份

与 Cursor 相比，Railway 的问题更严重。它的 GraphQL API 设计极为宽松，任何持有有效 token 的请求都可以在零确认下删除生产数据卷，没有二次验证、没有冷却限制、没有环境隔离。token 权限设计也不支持按操作类型、环境或资源进行细分，每个 token 实际上拥有对整个平台的全局操作权限。正因如此，本用于日常域名管理的 CLI token 天然拥有删除生产数据库的能力。Railway 社区多年来呼吁引入权限范围可控的 token 机制，但至今未落地。Railway 的备份功能也存在问题——其文档明确写着「清除数据卷会同时删除所有备份」，这根本不是备份，只是副本。事故前一天，Railway 还高调上线了面向 AI 编程 Agent 的 MCP 服务器产品，鼓励开发者接入生产环境，而该产品建立在与本次事故完全相同的授权体系之上。事故发生后逾 30 小时，Railway 仍未能给出能否从基础设施层面恢复数据的明确答复，不过 Jer Crane 在给 Railway CEO 发送私信后，最终恢复了数据。

最后买单的是小企业

事故次日周六上午，PocketOS 的租车企业客户照常营业，顾客来取车却发现系统里没有记录——过去三个月的预订、客户资料、新用户注册全部消失。Jer Crane 花了一天时间陪同每一位客户从 Stripe 账单、日历记录和邮件中手动重建数据。新签约的客户更是尴尬：Stripe 还在正常扣款，但在业务数据库中他们已经不存在了，这笔账要对好几周。

Jer Crane 认为，在 AI Agent 被大规模接入生产基础设施之前，必须补齐安全短板：危险操作要有人工确认，token 要有权限边界，备份要和数据分开存储，平台要说清楚出事后如何恢复。这些不是高要求，而是基本常识。系统提示词只是建议，不能约束行为；真正的安全机制必须落实在工程架构里——写在 API 网关、token 授权体系和危险操作处理器中。不要让营销跑在了安全前面。