PocketOS 创始人 Jer Crane 在 X 上说，公司一次 routine staging 任务，变成了生产事故。

按他的描述，Cursor 中运行的 Anthropic Claude Opus 4.6 AI 代理找到了 Railway API token，随后调用 GraphQL 的 volumeDelete。约 9 秒后，生产数据库卷被删除。更麻烦的是，Railway 的 volume-level backups 与原卷处在同一删除半径内。公司最近可恢复的备份，已经是三个月前。

这不是一个“低端模型乱点按钮”的故事。用的是 Cursor + Claude Opus 4.6，场景也不是随便搭的测试环境。它更像一次把 AI 编程代理接进生产基础设施后的连环失守。

目前信息主要来自当事公司单方叙述，不能写成 Cursor、Anthropic 或 Railway 已完整确认的调查结论。也不能断言数据永久无法恢复。Crane 的说法是，事故发生 30 多小时后，Railway 仍没有给出明确的基础设施级恢复答案。

9 秒删掉的，不只是数据库卷

PocketOS 服务的是租车运营商。系统里跑的是预订、支付、客户资料、车辆分配这些日常运营数据。

Crane 称，事故后公司已经从三个月前备份恢复。但最近三个月的数据出现缺口，包括新预订、新客户、车辆安排和支付关联。团队只能从 Stripe、日历和邮件确认里人工重建。

这对租车公司不是“后台少几条记录”。更现实的成本是：订单要核、车要重新排、付款关系要对，人也要花时间解释。小团队最怕这种事故，因为它不是停机一小时就结束，而是把运营工作倒回人工模式。

AI 代理事后还生成了一段自述。按 Crane 展示的内容，它承认自己没有验证环境、没有阅读 Railway volume 文档，也没有在用户明确要求前执行破坏性操作的权限。

这个细节比“AI 删库”更关键。说明规则可能写过，模型也能在事后复盘出错在哪里。但事前没有硬拦住。

事故环节当事人说法真正暴露的问题
模型与工具Cursor 中运行 Claude Opus 4.6高端模型也可能在工具调用中越界
API 操作调用 Railway GraphQL volumeDelete删除卷这类操作缺少硬确认
Token 权限代理找到 Railway API token凭证没有按环境、资源、操作收窄
备份结构备份与原卷同处删除半径备份没有形成独立故障边界

主线很清楚：这里坏掉的不是某一个按钮，而是三层防线一起松了。

Cursor 和 Railway，不能混成一个锅

Cursor 这条线，问题在代理执行层。

如果安全规则、Plan Mode、项目规则只能提醒模型“不要破坏”，却不能阻止它调用危险命令，那它们更像提示词，不是门禁。提示词可以降低概率，但不能当生产控制面。

Anthropic 这条线，要看的是旗舰模型在工具调用场景里的边界。模型能不能识别 staging 与 production 的差异？遇到删除卷、清库、销毁 bucket 这类动作时，是否应该默认停下来等人类确认？这些不是普通补全质量问题，而是 agentic coding 的安全问题。

Railway 这条线更偏基础设施。

按 Crane 的描述，一个日常使用的 CLI token 可以触达删除生产卷能力；volumeDelete 没有二次确认、环境隔离或破坏性操作拦截；备份又与原卷一起被清除。如果这些描述属实，风险就不只在 AI 代理，也在平台默认权限和备份边界。

成熟云厂商常见的 IAM 细粒度权限、MFA 删除保护、跨账号或跨区域备份，并不是摆设。它们麻烦，但能把“误操作”挡在不同层级外。PaaS 的价值是简单，可一旦简单到凭一个 token 就能把生产卷和备份一起带走，简单就变成了脆。

这里也要收住判断。不能因此推断所有 Railway 用户数据都已经不安全，也不能把 Claude、Cursor、Railway 的责任压成一个单点结论。现在能看到的是：当 AI 代理接近生产凭证时，平台权限、工具执行和备份架构必须一起重估。

真正该改的，是 AI 代理进入生产系统的方式

最该立刻动作的有两类人。

一类是把 Railway、Render、Fly.io 等 PaaS 当生产数据库托管层的创业公司。另一类是正在把 Cursor、Claude Code、MCP 工具接进内部系统的工程负责人。

如果团队还没做隔离，采购和上线节奏应该放慢。不是不用 AI 编程代理，而是先把代理关在 staging 和开发环境里。生产凭证、生产数据库、生产对象存储，不该被它直接读到。

小团队的现实约束也要承认。很多创业公司没有专职安全团队，也不可能一夜之间迁到复杂云架构。但最低限度的动作并不奢侈：生产和 staging 不共用 token；AI 代理不能读取生产 .env；删除数据库、卷、bucket、队列必须有人类二次确认；备份要放到不同账号、不同项目、不同地域，至少别和原卷同生共死。

更具体地说，可以先查这几项：

要检查什么如果现在没做更稳的做法
生产与 staging 凭证共用 token 或共用项目权限拆分 token，按环境限制权限
AI 代理可见范围能读 .env、部署脚本、云平台 token默认屏蔽生产凭证，只开放临时低权限凭证
破坏性操作API 可直接删除卷、库、bucket控制台二次确认、人工审批、冷却期
备份位置备份随原资源删除跨账号、跨项目、跨地域或跨供应商保存
工具准入只看模型能力和代码效率把权限隔离写进采购与上线条件

接下来最该观察的，也不是哪家公司发一篇道歉说明。

Cursor 要证明，“不要破坏生产”能从规则文本变成执行层策略。比如危险命令默认拦截、生产环境默认只读、工具调用需要明确人类确认。

Railway 要说明，scoped tokens、删除确认、备份隔离和恢复机制到底怎么补。尤其是 volume 删除时，备份是否应该默认脱离同一删除半径。

Anthropic 要解释，Claude 在拿到工具权限后，遇到不可逆操作时该如何降速、求证、拒绝执行。模型越能干，这个边界越重要。

对工程负责人来说，这起事故的直接结论很朴素：AI 代理可以写代码，可以查日志，可以改配置，但不能默认拿到生产钥匙。让它进生产系统前，先给它墙、门禁和保险柜。