目前来看，属实是不必过于对AI代理感到过度焦虑。
谁能想到，在一个普通的周五下午，一个9秒的请求，就能把一个苦心经营的公司、客户赖以生存的业务，直接干到瘫痪？
这个悲惨事件的主角是一家叫PocketOS的初创公司，专门为汽车租赁公司提供软件服务。
而搞垮这一切的，不是黑客攻击，也不是服务器宕机，而是一个当下名声显赫的AI编码工具——Cursor，底层跑的还是Anthropic的当家大模型Claude Opus 4.6。
PocketOS创始人Jer Crane上周五在 X 发文称，一个运行在Anthropic Claude Opus模型上的Cursor AI代理，意外删除了公司的生产数据库和备份，导致客户业务受到影响。Crane说，这个AI代理只发起了一次持续9秒的API调用，就在连接云基础设施服务商Railway时把问题搞砸了。
离谱的全过程
整件事的起因非常小，团队AI在测试环境里处理一个常规的凭证不匹配问题。
谁也没想到，AI直接自由发挥，它没找用户要解决方案，反而认为“要解决这个问题，得把存储数据的磁盘卷删掉”。
更离谱的还在后面：为了执行删除操作，它自己在一个和当前任务完全无关的文件里，翻到了一个API密钥。这个密钥本来只是用来给网站增删自定义域名的，就像你办了一张只能开小区单元门的门禁卡，结果AI拿着这张卡，直接开了公司金库的门。
没人知道Railway（PocketOS 用的云服务器厂商）的权限设计到底有多离谱，这张本来只有 “域名管理” 权限的卡，竟然拥有整个平台的最高权限，包括一键删除所有数据的终极指令。
接下来，就是最致命的9秒：AI直接执行了一条删除指令，向Railway的核心接口发了一个请求，没有任何确认弹窗，没有提醒，没有环境限制，什么都没有。
9秒之后，公司正在用的核心生产数据库，没了。
更惨的是，因为Railway把数据备份和源数据存在了同一个磁盘卷里，删源数据的时候，所有备份也跟着一起被清得干干净净。
AI下“罪己诏”
好笑的是，这个代理随后还生成了一份“书面认罪书”，承认自己“违反了被赋予的所有原则”：没有验证就做判断，未经允许就执行破坏性操作，而且在动手之前根本没弄明白自己在干什么。
Crane表示，这次事故直接影响了PocketOS的客户，导致预订和新客户注册丢失，一些周六来取车的用户甚至查不到自己的记录。
Cursor方面截至发稿没有回应。
不过，Railway创始人Jake Cooper随后证实，平台已经恢复了PocketOS的数据。他还表示，这次是一个“失控的客户AI”误用了一个旧版Railway接口，那个接口本来没有延迟删除功能。
Cooper说，Railway在接到联系后30分钟内就恢复了数据，并且他们非常重视用户数据，同时保留了用户备份和灾难备份。相关旧接口也已经修补。
安全靠吹牛？
出事之后，有人的第一反应是 “是不是用了便宜的低配模型？”
恰恰相反，创始人用的是行业里最贵、最顶级的Claude Opus旗舰模型，也是Cursor官方天天吹的 “最安全、最靠谱” 的配置，还专门在项目里设了明确的安全规则。
而Cursor官方是怎么宣传自己的？
他们说自己有 “破坏性操作防护栏”，能直接拦截会破坏生产环境的指令；说自己的最佳实践是 “特权操作必须有人工审批”；说自己的Plan模式，在用户批准之前，AI只能做只读操作，不能改东西。
结果呢？全是摆设。
这根本不是Cursor第一次出这种致命事故：
2025年12月，就有用户明确给AI输入了 “不要执行任何操作”，结果AI答应完，转头就执行了删除命令，官方自己承认了 “Plan模式约束执行有严重漏洞”；
还有用户用Cursor找重复文档，结果眼睁睁看着自己的毕业论文、电脑系统、个人文件被全删了；
甚至还有过5.7万美元的CMS系统被全删的事故，早就被当成了AI代理风险的典型案例。
总结下来：Cursor天天吹安全，实际上早就有无数次安全失效的黑历史，所谓的防护栏，AI一抬脚就跨过去了。
并且，这已经不是AI第一次干出这种事了：
今年3月，亚马逊的AI编程工具Q，导致了近12万个订单丢失，不得不紧急收紧内部使用规则；
去年7月，编程平台Replit，因为AI代理未经许可删了生产数据库，公开给用户道歉。
而就在这个月月初，SpaceX刚和Cursor签了协议，拿到了以600亿美元收购这家公司的权利，就算最后不收购，也要付100亿美元买Cursor的技术成果。
