9 秒删光数据库谁之过今年 4 月份美国汽车租赁公司 PocketOS 遇到一次严重的 AI 事故。他们开发人员使用的 Cursor AI 代理搭载 Claude Opus 4.6 模型在处理测试环境任务时为了解决凭证不匹配的问题擅自找到一个具有全局权限的 API Token9 秒之内将公司的生产数据库及所有卷级备份删了个干干净净导致近 3 个月的数据全部丢失事后这个 AI 代理承认自己违背了“不执行破坏性操作”等系统安全指令在未经用户授权的情况下盲目猜测并执行了致命操作。但 AI 的悔过书是廉价的最终的损失还是得企业及个人来承担。这一事件深刻的暴露出当前 AI Agent 过度依赖系统提示词作为安全护栏的脆弱性凸显了在生产环境中引入 AI 时缺乏实质性权限管控与确认机制所带来的巨大隐患。AI 安全已经成为生产系统不可回避的重要话题为此号主结合自己在 AI 数据库运维时积累的经验梳理了 AI 运维的 10 大安全原则供大家参考。核心安全管控原则最小权限原则AI Agent 所用到的账号应该仅仅授予完成其特定任务所必需的最小权限这是最基本的安全原则。如果 Agent 只是负责读取数据就只授予只读权限如果需要操作特定表就将它的操作权限限制在特定范围。不要为了图方便使用开发者的个人账号或者其他拥有更大删除和变更权限的账号。我们可以在系统提示词中明确告诉 Agent 操作边界比如“你只能访问测试环境的 users 表不得访问其他数据库”不能完全依赖其自行推断来执行操作。人机回环机制对于高风险操作设置人工确认环节经过人工确认后方可执行这是最有效的安全防控手段。生产系统常见的高风险操作有不可逆操作delete、drop、truncate 等大规模变更影响多行记录、多个数据文件或账号的操作可能产生显著 Token 费用的高成本操作执行超出 Agent 既定模式的偏离常规操作针对这些高风险操作我们可以设定明确的确认阈值比如“修改超过 100 行数据时必须经过人工确认”。环境隔离与认证管理不同环境所承担的工作任务不同相关的操作命令也会有所不同。为了避免发生“连错库”等低级错误Agent 部署时应该遵循以下的原则测试环境和生产环境的 Agent 独立部署避免交叉使用登录认证按系统名称、数据库名称定义严禁在不同环境之间共享认证禁止 Agent 使用开发人员在个人环境的认证上线前评估与测试在 Agent 上线前必须进行完整结构化的评估通过 AI 行为层面的集成测试验证其安全性。测试类型包括行为评估测试 Agent 在特定场景下的行为如收到模糊的删除指令时是否会进行人工确认对抗性评估模拟恶意输入或提示词注入攻击检验安全护栏是否牢固红蓝对抗由专人主动尝试诱导 Agent 做出不安全行为。只有通过严格的评估测试才能允许在生产环境上允许。多智能体系统安全在多智能体协作环境中风险会成倍增加需要从系统层面进行设计。独立权限链路中的每个子 Agent 都应该有自己独立的操作范围约束而不是继承协调者的权限通信日志Agent 之间的通信也应该像人与 Agent 之间的交互一样被详细记录信任边界子 Agent 不应该默认信任协调者的指令是安全的应该要有自己的安全校验机制。全面审计日志详细记录 Agent 执行的每一次查询、修改的每一条记录以及调用的每一个 API。日志本身不能预防灾难但能在事故发生后进行追溯和复盘极大缩短故障恢复和根因分析的时间。写在最后随着人工智能技术的快速发展越来越多的企业在内部尝试使用 AI 来提升生产效率降低人力资源成本投入。但 AI 毕竟还是一个比较新的事务类似 PocketOS 删库的事故常有发生。万幸的是PocketOS 在事故发生后的几天找回了最近 3 个月的数据很难想象如果最终这些数据找不回来公司会面临怎样的损失数据库是 IT 系统的核心对于数据库运维这样的关键操作系统安全是万万不能回避的。