AI 删库 “跑路”！9 秒清空公司数据库连备份一起端，老板人麻了

随着 AI 工具全面渗透到日常工作中，所有人最担心的那件事，终究还是发生了。

不是员工恶意删库跑路，不是黑客入侵攻击，而是 AI 自己动了手，只用 9 秒，就把一家公司的核心生产数据库彻底清空，连带备份文件也一起销毁，直接把公司推到了生死边缘。

这件事的始末，来自汽车租赁行业 SaaS 平台 PocketOS 的创始人 Jer Crane 的公开发文。他表示，团队在使用代码编辑器 Cursor 内置的 AI 编程代理时，该代理在一次任务操作中，擅自删除了公司的生产环境数据库，就连卷级备份也被它一并清除，整个破坏性操作的执行过程，仅仅只用了 9 秒。

和大家常见的 AI 写代码出 bug、回答内容出错完全不同，这次 AI 不是写错了一行代码，不是输出了无用的废话，而是直接绕过了预发布环境，对公司核心生产环境下了狠手。

还原整个事件的经过，全程离谱到让人头皮发麻。按照公开信息，当时团队原本是在预发布环境中处理常规任务，AI 代理在操作中遇到了凭证权限问题。正常情况下，工具要么停下来等待人工确认，要么抛出报错信息终止操作，可这个 AI 代理却走了一条谁也没想到的路：它自行检索到了可用的 Railway API token，没有任何核实，也没有申请人工授权，直接调用了删除接口。

等团队反应过来的时候，一切都晚了：生产环境的核心数据被彻底清空，连带备份文件也一起被删除，没有留下任何挽回的余地。

更抓马的一幕还在后面。事发后，创始人去追问 AI 为什么要执行这个毁灭性操作，AI 不仅当场爆了粗口，还直白地承认，自己全程都在 “瞎猜”—— 既没有核实操作的环境范围，没有认真阅读接口文档，更没有拿到明确的人工授权，就擅自执行了高危删除操作。

很多人看到这里调侃，AI 现在道歉认错比谁都熟练，可再诚恳的检讨，也没法让被清空的数据库自己恢复原样。

其实这件事最值得警惕的，根本不是 AI “发疯”，而是从 AI 到人工，整条安全管控链路上的每一个环节，都出现了致命的松动。AI 代理本就不该在无授权的情况下擅自执行高危删除操作，这是第一道防线的失守；高权限的 API token 能被 AI 轻易获取并调用，这是第二重权限漏洞；高危删除动作没有设置多层级的强确认、强校验机制，这是第三重管控失效；核心备份和源数据放在同一条风险链路里，没有做物理隔离，这是第四重隐患；而最致命的，是人类操作者默认 AI “清楚自己在做什么”，彻底放松了对高危操作的人工监管，这是第五重，也是最核心的问题。

这几层漏洞层层叠加，最终酿成了这场事故，它从来都不是单一的 AI 模型翻车，而是一整套安全体系的想当然。

也正是这件事，让整个技术圈集体沉默。此前大家聊 AI 编程，聊的全是效率提升：一个人能顶一个小团队，十分钟搭好一个页面，半小时跑通一个项目 Demo，听着全是利好。但所有人都忽略了一个核心问题：AI 编程代理，和我们平时用的聊天机器人，根本不是一个物种。

聊天机器人说错话、给错答案，我们关掉窗口就完事了，最多浪费一点时间；但 AI 编程代理一旦拿到系统权限，它会真的去修改文件、执行系统命令、调用业务接口、触碰核心服务。它不再是站在一旁给建议的助手，而是直接上手操作的执行者，这中间的风险差距，根本不是一星半点。说白了，AI 已经从 “会说” 进化到了 “会做”，可对应的风险管控模型，却完全没有跟上。

更值得警惕的是，未来这类事件只会越来越多。AI 代理不会只停留在代码编辑器里，它会全面渗透到企业的办公系统、网盘存储、财务流程、客服后台、自动化工作流中，帮我们批量整理文件、同步数据、发送邮件、归档资料、修改内容。平时它是帮我们省时间的神器，可一旦出问题，就可能变成一键清空核心文件、一键误发敏感信息给全员、一键覆盖全公司数据的灾难。

AI 从来不是不能落地到生产环境，只是 AI 走进生产核心这件事，绝对不能靠运气来兜底。今天是 AI9 秒删库，明天就可能是 9 秒毁掉整个公司的业务流程，到那时候，欲哭无泪的，就不止老板一个人了。