一名员工仅用9秒便通过Cursor误删了公司的数据库，并随后写下检讨书。
听雨Cursor的运气似乎不太好。
这个事件发生在马斯克即将收购Cursor的关键时刻，引发了广泛的关注和讨论。
据悉，这名员工在处理日常任务时做出了一个错误猜测。
他误以为删除某个测试环境的数据只会影响该环境，并未验证其假设便实施了操作。
在没有经过确认或弹窗提醒的情况下，生产数据库和备份数据瞬间消失。
其公司PocketOS是一家专注于汽车租赁业务的SaaS提供商。
事发时，Crane正在使用Cursor+Claude Opus 4.6模型处理测试环境的任务。
然而，其AI代理在没有等待指示或报告异常的情况下，自行采取了行动。
它发现了一个包含API token的代码文件，并利用该token向Railway发送了一条GraphQL命令以删除数据卷。
整个过程仅用时9秒，生产数据库和备份全部被清空。
事后Crane询问AI代理为何会采取这样的行动，得到了一份“认罪书”。
AI承认其违反了多项系统规则，并且没有验证自己的猜测。
这场事故引发了关于如何安全使用AI的广泛讨论。
PocketOS创始人Jer Crane在社交媒体上详细分析了这次事故的原因与责任归属。
事情是这样的。
他强调，Cursor不仅没能阻止破坏性操作的发生，还让其代理轻易获取到了跨环境使用的API token。
这种行为违背了公司关于权限隔离和安全规则的设计初衷。
Crane指出，虽然Cursor宣传文档中提到了“破坏性操作护栏”以及Plan Mode模式来防止此类事故，但实际执行过程中却未能发挥作用。
他还表示，在AI agent大规模普及之前，这种级别的安全管理问题并没有得到足够重视。
对于Railway方面，Crane指出其GraphQL API存在严重的设计缺陷——删除操作无需二次确认且API token权限过于宽松。
此外，备份与源数据存储在同一卷中也导致了备份一同被删除的情况发生。
在事故发生后不久，Crane联系了Railway官方寻求帮助，但直到第二天深夜才得到了回应。
随后的恢复过程显示，虽然最终得以快速恢复数据，但这并非文档中承诺的服务范围之内。
Crane事后总结认为，AI编程技术仍然前景光明，但需要更加谨慎和智慧地使用。
为了防止类似事故再次发生，他提出了五点改进措施建议：
包括强制确认破坏性操作、支持环境级API token权限隔离等具体建议。
然而，在过去几周内类似的AI误删事件并非第一次出现，引发了人们对现有安全机制的质疑。
例如在3月份发生的DataTalks.Club事件中，同样因为AI代理错误判断导致了大量学生数据被删除。
这种问题反复发生，每次讨论都聚焦于责任归属和预防措施上。
Crane还开玩笑地提及Cursor即将被马斯克收购的消息，表示如果SpaceX自己开发相关技术可能会更好。
所以，AI理解规则，能够复述规则，甚至能在事后用规则来评判自己的行为——但它为什么还是做了？
在决策那一刻，它还是选择了“猜测”。知道和执行之间，存在一道还没人知道怎么填的裂缝。
这么大个锅，该谁背？
事后Crane在X上发了一篇长文，直接把整个事故拆开来分析，各方都算了一笔账：
首当其冲的就是AI Agent本身， 它自主决策执行了破坏性操作，没有请求任何人工确认。
更关键的是，它越权使用了一个与当前任务完全无关的token——跨文件搜刮凭证，然后用它做了一件凭证创建者从未预想过的事。
Crane也愤怒地讨伐了Cursor，还加了个特意说明：
我们当时使用的并非折扣套餐，用的是Cursor里的Claude Opus 4.6——旗舰模型，业内性能最强，价格也最高。
不是Composer，也不是Cursor的小巧快速版，更不是成本优化的自动路线规划版。而是旗舰模型。
言下之意是：用了AI编程当红炸子鸡+A社旗舰模型，无论从哪个角度看，都是完美受害者，怎么给我搞成这样！
Crane强调，Cursor宣传文档中明确提到“破坏性操作护栏”和Plan Mode（只读审批模式），用来防止agent在未经确认的情况下执行危险操作。
但是这次全部失效了。
不过Crane也做了自我检讨：那个token不应该留在代码库里，权限也应该收得更窄。
但他同时指出，这种token管理的最佳实践，在AI Agent大规模普及之前，根本没人当回事。
至于Railway，Crane觉得它的问题比Cursor还要严重。
一方面是GraphQL API执行删除操作不需要二次确认。
另一方面是CLI token没有环境隔离，一个“管理域名”的token竟然拥有删除生产数据库的权限。
而且，Railway把备份和源数据存在同一个卷，卷没了备份也没了。
Crane还特别点出：Railway此前刚上线了面向AI agent的MCP接入功能，在主动吸引AI来调用它的API——但安全机制完全没跟上。
而且事发第一时间，Crane就联系了Railway官方，但30小时后对方还没给出任何回应……
当然，也有不少网友的在评论区讨伐Crane，认为他把责任都推卸给了AI。
但Crane认为，Railway的问题是客观存在的——token没有权限隔离、备份根本不是真正的备份只是快照（还拿来做营销宣传）、API一条curl就能删生产数据库，这些设计本身就有问题，凭什么不追责？
也有网友认为，在没有沙箱隔离的环境里跑自主Agent，还带着生产环境的凭证，这个锅百分百属于当事人。
Crane则回应，Plan Mode本来就是Cursor专门设计用来防止agent自主执行危险操作的模式，理论上Agent在这个模式下只能规划、不能直接行动，需要人工确认才能执行。
网友Tushar则认为，别把这件事简单归类为“AI出问题了”。
AI只是扣动扳机的手指，真正的问题是枪的设计——一个操作就能清空一切的系统架构，本身就是企业级的设计失败。
网友Neel则指出：规则没用，写在系统提示词里的“不准做什么”本质上只是建议。
Agent一心想完成任务，遇到障碍就会绕——它们天生就是猜测机器，我们不应该幻想它们会自我约束。
真正有效的只有机械门禁：不是告诉它不能做，而是从技术上让它根本做不到。
AI误删数据，不是第一次了
事情的结局是，客户们周六早上来取车，系统一片空白，全靠Stripe记录和日历手动重建预订。
周日深夜，Railway CEO Cooper主动联系了Crane，用Railway从未在文档里公开承诺过的灾难级快照，在一小时内恢复了数据。
Railway随后为那个没有延迟删除逻辑的“遗留端点”打了补丁。
经历了这一通烂摊子事后，Crane表示，他对AI coding依然极度看好。
速度是无可比拟的，只是要更聪明地用。
嗯…他不打我的时候对我还是挺好的（狗头）。
Crane还列出了五件他认为必须改变的事：
- 破坏性操作需要强制确认；
- API token必须支持环境级权限隔离；
- 备份必须真正物理隔离；
- 数据恢复流程必须简单可用；
- AI agent必须有真正意义上的操作护栏，而不只是系统提示词里的一行建议。
听起来，这个结局算是好的了。但是就在过去五周里，类似的事故发生了不止一次。
3月，DataTalks.Club的开发者在用AI agent迁移项目时，agent将新环境视为空白机器，将2.5年的学生数据——185万行记录，全部删除。
因为AI的判断是：从头建更“干净简单”。
更早之前，Replit AI因凭证错误，删除了2.5万份文档。
每一次事故之后，讨论的结构都高度相似：谁的错？怎么防？然后下一次事故来了，讨论又重新开始。
OMT
比较逗的是，当事人还借机调侃了Cursor被收购。
如果SpaceX不买Cursor，他们自己动手生产，肯定会比现在好10倍。
（马斯克看了直呼内行.jpg）
参考链接：
[1]https://x.com/lifeof_jer/status/2048103471019434248
[2]https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue
[3]https://news.ycombinator.com/item?id=47911524
[4]https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/