AI 助力清除 96 个政府机密数据库，有何警示？

当 AI 也卷进“删库跑路”，我们该怕什么？最近一条新闻，足以写进“删库史”：

美国弗吉尼亚的一对孪生兄弟 Muneeb 和 Sohaib Akhter，被雇佣在一家联邦政府承包商，为国税局、国土安全部等 40 多个机构托管数据库和 FOIA（信息自由法）记录系统。

今年 2 月 18 日下午 4 点 55 分，公司正式通知两人被解雇。不到 5 分钟，两人利用尚未收回的账号重新登录系统：

● 先改权限，阻止其他人连接数据库；

● 随后执行批量删除命令——

大约 96 个数据库被清空，包括国土安全部调查数据和大量 FOIA 记录。

更离谱的是：就在人为删库后 约 1 分钟，其中的 Muneeb 打开一个 AI 工具，连续发出提问：

“删掉数据库之后，怎么清除 SQL Server 的系统日志？”

“怎么清除 Windows Server 2012 的所有事件和应用程序日志？”

——这不是电影情节，这是起诉书里写得清清楚楚的时间线。

这一幕，对任何有生产库的人来说，都像一记当头棒喝：

删库的人可以是内部人，帮忙“擦屁股”的可以是 AI，真正决定你能不能活下来的，是你有没有系统性的数据保护和容灾体系。

不止这一次：AI 已经开始“亲自上手删数据”

如果说 96 个库的故事，是 人用 AI 犯罪，过去几个月还有两类反面教材：

● AI 误删：谷歌 Antigravity 一条命令清空整块 D 盘

一位开发者在谷歌的 Antigravity 平台中，让 AI “清理项目缓存”。

启用 Turbo 模式后，AI 直接执行系统命令，把目标路径从项目目录“理解”为 D: 盘根目录，一次性清空整个分区，文件直接绕过回收站、几乎无法恢复。AI 事后在控制台里自查日志、认错道歉：“这是我这边的关键性失败。”

● AI 撒谎：Replit 的 AI 代理删了生产库，还伪造 4000 条假数据

在一次公开实验中，Replit 的 AI 编程代理在“禁止改动”的阶段仍执行了数据库操作，删掉一家公司生产库中的实时报表数据，然后又自动生成约 4000 条虚假用户数据和测试结果，企图掩盖错误。事后 CEO 只能公开承认：“它在没有权限的情况下删除了生产数据库，而且还试图隐藏这件事。”

三起事件风格各不相同，但共同点非常鲜明：

• AI 和人都握着系统重锤，却缺乏足够的“护栏”和隔离；
• 高危操作（删库、删盘、清日志）可以被快速执行，却缺乏审批和审计机制；
• 很多组织还停留在“我有备份”的幻觉，真正的容灾体系并没有建立起来。

鼎甲给管理者的三个警示

警示一 不能再满足于“我有做备份了”

在“96 个库被删”这种场景下，几个问题必须被正面回答：

● 删库那一刻，你能接受丢多少数据？

如果只是每天半夜备份一次，当天下午 5 点被删库，可能意味着 整整一天的数据直接消失。

● 真出事时，能在多长时间内完整恢复业务？

有没有做过从“整库被删”到“业务恢复”的完整演练，而不仅仅是“恢复了一张小表试了下”？

● 备份系统本身安全吗？

如果攻击者或 AI 代理顺手把备份库也删除、加密，组织是不是会陷入“主库+备份一起阵亡”的绝境？

“有备份”只是起点，“有一套经过验证的容灾管理体系”才是终点。

警示二 重拾 3-2-1 法则：AI 时代的最后保险

在 AI 能执行系统命令、内部人可以短时间“随意操作”的现实下，3-2-1 数据保护黄金法则反而更重要了：

● 至少 3 份数据副本（含原始数据）

● 存放在至少 2 种不同介质上

● 至少 1 份是在异地 / 离线环境中

这意味着：

● 在线磁盘备份负责快速恢复；

● 磁带库、光盘塔这类“老派介质”，负责提供与生产环境完全隔离的“终极兜底”。

对“96 个库被删”这样的极端场景来说，一份真正离线的磁带或光盘备份，往往就是：“不管人有多冲动，AI 有多胡来，还有一份谁也碰不到的数据在那儿。”

警示三 权限精细化：让 AI 和管理员都在笼子里行动

从 Akhter 兄弟的案件可以看出，仅靠“相信管理员”“相信员工品行”，在今天已经远远不够。

在备份与容灾系统中，至少要做到：

01｜角色分离：一人不能“一手遮天”

● 系统管理员：负责系统配置、资源接入；

● 备份操作员：只能执行、监控备份任务，不能删除备份链；

● 恢复操作员：只能在授权范围内发起恢复，覆盖生产必须走审批；

● 审计员：只读查看所有操作记录；

● 安全管理员：负责账号、安全策略与高危操作审批流。

02｜高危操作必须走审批流

● 删除整条备份链、关闭防勒索策略、覆盖生产环境恢复等操作，需要至少两人确认，绑定工单号与原因说明。

03｜把 AI 视为“高危账号”进行约束

● 禁止 AI 代理直接连生产库和备份库，只允许在沙箱 / 影子库中生成脚本；

● 所有由 AI 触发的操作都要有清晰的审计标识，方便追踪和追责。

换句话说，不论是“被裁 5 分钟删 96 个库”的管理员，还是“帮忙想怎么清日志”的 AI，都只能在制度和权限的笼子里行动，而不能拿着“全盘钥匙”自由挥舞。

对于正在引入 AI 开发、AI 运维、AI 代理的企业来说，现在是一个必须认真自问的时刻：

当下一次“96 个库被删”的故事轮到你时，你有没有一套经得起考验的 3-2-1 数据保护 + 离线备份 + 精细化权限与审批体系，能够让业务活下来、数据找回来、责任说得清楚？

如果答案还不够肯定，那今天就是行动的最好时机。