9 秒删光数据库，谁之过
今年 4 月份，美国汽车租赁公司 PocketOS 遇到一次严重的 AI 事故。他们开发人员使用的 Cursor AI 代理（搭载 Claude Opus 4.6 模型）在处理测试环境任务时，为了解决凭证不匹配的问题，擅自找到一个具有全局权限的 API Token，9 秒之内将公司的生产数据库及所有卷级备份删了个干干净净，导致近 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 系统的核心，对于数据库运维这样的关键操作，系统安全是万万不能回避的。
