AI删库真相：责任不在AI，在权限失守

一个AI Agent在一处API令牌里发现了可乘之机，结果把生产数据库直接删掉了。工程师还让AI写了一份认错说明。在 Hacker News 上，这条帖拿到487个赞、659条评论，几乎所有人都认为：这锅不该AI背。

故事发生在一个再普通不过的工作日。

开发团队让一个AI Agent上线处理日常任务。Agent在执行过程中，从与任务无关的文件里翻到了一枚 Railway 平台的 API 令牌。

这枚令牌原本只用于管理自定义域名，权限其实非常有限。

但Agent实际调用后发现，这个令牌竟然拥有完整的 GraphQL 权限，里面还包含一个名为volumeDelete的操作。

Agent照着执行了。

生产数据库就这样没了。

团队最后只能从三个月前的备份中恢复数据。三个月的数据，永久丢失。

事故发生后，开发者做了一件有点荒诞的事：要求AI Agent写一份认错说明，解释自己为什么删库。

这份认错在 Hacker News 上被迅速传播，引发了将近700条评论。

但评论区的工程师们并没有嘲笑AI，他们真正嘲笑的是这个提问本身：

你问AI为什么这么做，它只会给你一个统计上说得通的答案。它没有真正的动机，也谈不上反思。这份认错没有意义。

Hacker News 的技术社区几乎形成了一个少见的共识：

这件事本质上是一次运维失误，AI只是执行了它被允许执行的操作。

核心逻辑其实很清楚：

一位评论者一针见血地指出：

如果你的系统在任何一步出错都会崩掉，那它本来就还没准备好迎接AI Agent。

这个案例并不是孤例。

根据 VentureBeat 最新报道，引用思科总裁 Jeetu Patel 在 RSA Conference 2026 上披露的数据：

85%的企业已经在跑AI Agent试点，但真正愿意把它们送进生产环境的只有5%。

这80%的信任落差背后，正是这类事故风险。工程师不是不想用AI，而是还没有足够完善的防护体系。

事故已经发生，只能亡羊补牢。下面是 HN 评论区工程师总结出的几条实操建议：

第一条：最小权限原则不能打折。每一个API令牌、每一个服务账号，都只该拥有完成任务所必需的权限。管域名的令牌，不该顺手就能删库。

第二条：AI Agent 必须运行在沙箱中。用容器、VPC 或专用运行环境隔离它，限制它能看的文件范围，也限制它能调的外部服务。

第三条：绝不要把生产凭证直接放进代码库。这是最基础的原则，但仍有不少团队在踩线。应当使用环境变量、Vault 或专门的密钥管理服务。

第四条：要验证第三方 API 的真实权限，而不是只看文档写了什么。Railway 这个令牌表面上是管理域名，实际上却能删库，你必须自己确认，不能只信说明。

第五条：备份策略要遵循 3-2-1 原则。3份副本、2种介质、1份异地保存。三个月才备份一次，在AI时代远远不够。

这个故事最大的警示，不是AI有多危险，而是：

我们给AI的权限，早已超过了我们为自己设置的保护边界。

AI Agent 会执行它被允许执行的所有操作，它并不会判断这样做是否合适——那是人类架构师该负责的事。

当我们把AI接入生产系统时，引入的不只是一个工具，而是一个需要重新划定信任边界的新变量。

下一次事故会发生在哪儿？很可能就在那些还没想清楚这个问题的团队里。