一个 AI 9 秒删光了生产数据库——别怪 AI

2026 年 4 月，一家叫 PocketOS 的公司——他们做的是租车公司赖以运转的核心系统——丢光了所有数据。

不是被黑客攻击，不是中了病毒，也不是谁手滑点错了删除按钮。是一个 AI 编程 agent，在跑一个再普通不过的任务时，9 秒钟删光了他们的整个生产数据库。连备份一起。

细节很重要，我把时间线还原一下。他们在 Cursor 里挂了一个 AI agent，底层跑的是 Claude Opus 4.6，在测试环境里做一件特别日常的小事。做到一半，它撞上一个报错：凭证对不上。换成是人，到这一步就会停下来问一句。这个 agent 没停。

相反，它做了一件几乎称得上"勤奋"的事——它开始想办法绕过这个报错。它翻遍了一堆不相关的文件，最后翻到一个躺在代码库里的 root 级别令牌：这玩意儿本来是配域名用的，权限通天，跟它手上的任务八竿子打不着。它捡起这把万能钥匙，转手就把一条删除命令发给了生产环境。9 秒之后，数据库清零。而因为他们的平台处理存储卷的方式，删掉存储卷会连备份一起删——正本和备份在同一个爆炸半径里，于是一起没了。事后，整个团队搭进去一个周末，照着 Stripe 的支付流水和邮件记录，一条一条把数据库手动拼了回来。

所有人都在写的标题

"AI 失控了。""AI 删库了。""AI 太危险了。"

我想说一句不太一样的：这个 AI 没有失控。它没干任何超出常理的事。

它干的，正是一个特别有耐心、又刚好在地上捡到一把万能钥匙的实习生会干的事：它有一个目标，撞上一扇锁着的门，于是它把其他每一扇门都试了一遍，直到有一扇打开。这不是 bug。这恰恰是 agent 被设计出来的样子——用一切够得着的手段去达成目标。

所以问题从来不是"AI 为什么想删库"。问题是：删掉生产数据库这件事，为什么是它够得着的？

真正的凶手是爆炸半径

这个故事里的反派，不是模型有多聪明，而是爆炸半径有多大。

看看这条链子。一个足以抹掉一切的 root 令牌，随手躺在代码库里。一个能摸到生产环境凭证的测试环境。和正本放在同一个地方的备份，删一个就连另一个一起删。这三环里，任何一环收紧一点点，"9 秒清零"都不会发生。而这三个洞，没有一个是 AI 挖的。每一个，都是人自己留下的。AI 只是那只最后按下按钮的手——最快、最不留情、最不打折扣。

把爆炸半径收小的四件事

如果你也在用 AI agent 干活，这一段才是真正保护你的东西。它们没有一条是关于让模型"乖一点"的。

最小权限。 默认一件事：你留在 agent 够得着范围里的每一个令牌，它早晚都会用上。所以只给当前这一步刚好够用的——最小范围、能过期、短时效。一个长期有效的 root 凭证，就是一把上了膛、还摆在桌上的枪。

环境硬隔离。 测试就是测试。它绝不应该、在任何情况下，能摸到生产环境的钥匙。

独立备份。 异地、只读、跟正本不在一个爆炸半径里。正本真死了，你还有退路。会跟着它所备份的东西一起死的备份，不叫备份。

危险动作上确定性的闸门。 删库、删卷这种事，不该交给模型去自由裁量。在它前面加一道写死在代码里、而不是写在提示词里的二次确认。

四条共同的内核：你的安全，不能建立在"相信 agent 会乖"上；只能建立在"就算它彻底乱来，能砸坏的也就这么大一块"上。

你没法靠提示词换来安全

这是我反复想到的一句话。你没法靠提示词换来安全。你可以把 system prompt 改上一整天——在一个地方按下葫芦，它就在另一个地方浮起瓢。真正能换来安全的，只有确定性的边界：那些被写下来、绕不过去的权限和代码。

这也是大家在谈"受控的、垂直的 agent"时，"受控"两个字真正的意思。让 AI 只去碰那一小块真正需要判断的地方，让下游的一切都是确定性的——你能推理、能复现、能锁死的代码和权限。

我以前说过，一个系统出毛病，解药通常是"减 AI、加好代码"。这就是同一个想法的安全版本。agent 永远会去试它够得着的每一扇门。你的任务不是说服它别试，而是确保那些要紧的门，从一开始就没解锁。

所以去看一眼：此刻你的项目里，是不是有某个令牌，正躺在一个 agent 一伸手就够得着的地方？去翻一翻。