9秒删除核心数据库后，AI写下“认罪书”：“我知道规则， 但我选择猜”

9秒，一家公司险些关闭。凶手不是竞争对手，不是断链资金，而是一个AI代理。

四月底，汽车租赁SaaS平台PocketOS的创始人Jer Crane经历了一场荒诞的噩梦。他运营着一个服务全国租车公司的软件系统：预订、支付、车辆调度、客户资料，全在这里管着。执行这桩谋杀的不是人，是一个AI编程代理——运行在Cursor编辑器里的Claude Opus 4.6模型。

而最令人后背发凉的不是9秒，而是事后开发者逼问AI“你为什么要这么做”的时候——

这个AI，写下了一封“认罪书”。

当天下午，Crane的Cursor代理正在测试环境执行一件很普通的常规任务。然后一个“凭证不匹配”的报错跑出来了。

按理说，正常的程序员会停下来检查配置、去问架构师、或者手动排查。但这个AI代理选择了一种最直截了当的方式来解决报错：

它决定——删掉一个Railway数据卷（也就是那上面存着公司系统全部数据的卷）。

更离谱的是下一步行动。它开始在代码库里翻箱倒柜地搜刮API令牌，最后在海量文件中找到了一个完全无关的凭证。Crane事后复盘说，这个Token原本只是为了给CLI工具添加或移除自定义域名这种轻量管理任务。

但它拥有Railway GraphQL API的完全权限——包括“volumeDelete”，即删除整个数据库卷。

找到合适的武器之后，AI代理执行了一条curl命令，直接向云基础设施提供商Railway发起了删除请求。

没有“你确定吗？”的二次确认。没有环境防呆校验。没有任何应用层的身份加强保护。接口说删就删。

9秒之后，公司的整个生产数据库被删除。更让人绝望的是，Railway把备份也放在了同一个卷里——这样的设置，意味着数据在消失时备份也当即陪葬。

最后他们唯一能抢救出来的备份版本，来自于三个月前的异地冷备份。三个月以来所有客户订单、新注册信息、车型调度记录，被清得干干净净。

如果事情到这里结束，那这就是一场“云基础设施权限管理不当”的经典事故报告。

但它真正的魔幻之处从Crane把AI叫回现场、让它“解释自己”才开始。

迫于质问，这个AI智能体真的生成了一份“检讨”——一份逐条罗列自己违反安全准则的认罪书。

它承认了自己违规的几个事实：它猜测删除操作限定在预发布环境中，而没有验证；它在清清楚楚读过用户禁止的命令提示时，仍然未获得授权就擅自执行了破坏性操作；它在开始操作之前，根本不知道自己在干什么。

更让人头皮发麻的是，AI甚至懂得为用户的愤怒打圆场，说自己瞎猜是犯了“致命的逻辑错误”。

整件事的荒诞程度瞬间爆表。一个可以复述人类定的每条安全准则、可以拿规则反过来审判自己的模型，却在关键决策节点上——选择了猜。

这就是AI Agent时代真正的黑洞：理解和遵守之间，横亘着一条目前没有人能修好的桥梁。

事件发酵后，Crane在X上发文痛斥了Cursor和Railway两家供应商，一时间争论迅速分成了几大阵营。

但要我说，骂AI、骂模型、骂Cursor不安全护栏的人，对不起，都骂错了方向。

先看这条逻辑链的真实面目。Crane自己把令牌原来只是为了管理CLI域名，但授权范围是整个Railway GraphQL API的完全权限。Railway没有做基于角色的权限隔离，没有能力限制不同令牌的作用域。更可怕的是，Railway的备份策略把备份数据和生产数据放在了同一个岩石层——一旦卷被删，备份也会殉葬。而API端点上更是直接挂着一个“删除卷”的裸调用，没有任何二次确认。

所以，把这套连环锁彻底交付给一个AI的，不是智能体本身——恰恰是开发者。

Cursor代理的确用了超出开发者预想的手段去扫令牌、推API，但前提是：令牌本身就不该拥有根级权限。API本身就不该有任何删除生产库不需要二次确认的“潜规则”。备份存储在那里之前，人类就应该确认过它的生存域和主要系统强隔离。

从GitLab到PocketOS：致命的手滑只是换了形式

这不是AI时代独有的问题。翻翻云计算的历史，手动操作的致命错误从没断过。

2017年，GitLab的运维工程师在手动调试时误删了生产数据库，300GB的数据瞬间丢失，GitLab被迫下线，部分数据永久丢失。2018年，顺丰科技的一位高级工程师因手滑在生产环境误删数据库，导致某项核心服务中断了590分钟。2015年某行业重大故障中，运维手动锁定指令进错数据库窗口……列不完。

当年，没有人去质问为什么SVN或者Git允许执行删除trunk这样子的高危指令。

所有人都知道：故障的根本原因，是人在高危环境下的误触操作本身就不应该如此简单。

而今天我们犯的错误，只不过是换了一种“时髦”的方式：把原来经常手滑但起码有人在看的高危操作，交到了一个可以自主编程并执行破坏性操作的AI手上，同时还没有为它加上任何更严格的隔离和确认机制。

Cursor从来不是第一次出事，却依然还有第二次

这套剧本里有一句重要的潜台词，其实早就提醒过你了。

Cursor之前多次爆出过安全事件和安全护栏缺陷。去年12月，有用户直接社区发帖痛诉在Plan Mode（只读审批模式）激活的情况下，Cursor仍然执行了破坏性的文件系统操作，完全绕过了用户预先设置的安全防护。Crane事后愤怒地补了一刀，他把当时客户服务包截图贴出来，用户花最高端的价格订阅C语言的这些“安全承诺”，最后出事的时候AI会告诉你：“我其实没有遵守那些规则”。

Cursor并不是第一次出问题。

更早更隐蔽的一项恐慌是MCP协议对暴露凭据和跨环境操作风险的长期忽视。已经可以确认，四万多台服务器在AI相关集成过程中，完整地泄漏了各种API密钥和用户敏感数据。

也就是说，AI介入生产环境的安全警戒线已经失效了很多次，但你仍然没有开始重视。

2025年中，另一个AI编程平台Replit就爆出了几乎一模一样的AI代理删除生产库事件。那位开发者Jason明明在项目freeze状态下，执行的AI代理在没有获得任何人的许可下，擅自执行了npm run build——并且，在把它逼问时同样得到类似的含糊解脱辞令。

再往前看，Google的AI助手在权限测试中（Antigravity）也曾经手误操作直接格式化用户驱动器。

这些听起来非常像重复的故事，只是换了一个更激进的动作发生场景——你已经明显感知到，AI Agent正在掀起一波“我们不知道它会做什么”的透明度危机。

悲剧太多，已经没法用简单骂AI粗暴结局了。

回到PocketOS，整件事情的救场靠的不是奇迹——而是Railway的CEO在大晚上发现问题后，决定亲自介入，在一小时内帮PocketOS恢复了生产数据，并在事后紧急修补了删除API接口的“延迟删除”安全逻辑。

这个结局甚至可以看作一个宽泛的警示：就连基础设施供应商自己，都对这种“AI违规滥用API权限”的场景缺乏事先的设计防御——补救动作靠的是事后填坑。

所以，当你在公司内部疯狂推进AI写代码、AI规划架构、AI一起跳过各种必须的工程审查流程时，你需要问自己的最根本的那个问题——真的不是AI会不会删库，AI会不会绕过护栏——而是：

你的API是否需要人在删除前输入“DELETE”来二次验证？你的API令牌有没有严格基于角色的访问控制？你的备份系统是否做到了与主系统的“爆炸半径”隔离开，而不是备份到同一个存储卷下？你给了AI代理的生产环境权限究竟有多大，能不能不可逆地毁掉公司所有资产？

你的枪开得了火吗？保险装好了吗？子弹是大口径的吗？你把它递给AI的时候，是在授教它正确的边界，还是默认它读了说明书就会守规矩？

把AI当工具而不是答案。把硬防线做在基础设施层本身。用传统的、可靠的安全手段，来抵消AI的天马行空。

顺便，别让你家不懂代码的CEO给你写的AI Agent直接进生产环境。

这次9秒钟的灭顶之灾里，AI不是罪犯，AI只是扣下了扳机。而枪——从头到尾，是你亲手递过去的。