从生成到执行SQL：Agent时代的数据库安全模型重构

让Agent生成一条SQL，与允许它直接连接生产库并执行SQL，是两个完全不同的安全问题。前者还有人工审核作为缓冲，后者则可能把一次语义理解偏差迅速放大为数据事故。要让自动巡检、变更和修复真正落地，权限边界、执行前检查、回滚能力与审计链路都需要重新设计。

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

2026年，AI Agent正在从“帮我写SQL”进化到“帮我执行SQL”。

以前Agent的角色是辅助——生成SQL语句，DBA审核后手动执行。现在越来越多的场景在讨论让Agent自主操作数据库：自动巡检、自动优化、自动变更、自动修复。

效率提升是显而易见的。但有一个问题绕不开：Agent误删了数据怎么办？

一个人类DBA执行DELETE之前会反复确认——先SELECT看看影响多少行，再开事务试一下，确认无误才提交。Agent不会。它可能因为一个理解偏差，直接执行一条没有WHERE条件的DELETE，然后数据库就空了。

这不是危言耸听。2025年已经出现过Agent误操作导致生产数据丢失的真实案例。

当Agent从“只读”走向“读写”，数据库的安全模型需要重新设计。

一、Agent操作数据库的三大风险

风险1：误操作——Agent的“手滑”比人类更严重

人类DBA手滑，最多删错几行。Agent手滑，可能是全表。原因在于：

• 缺乏“危险感知” ：人类看到DELETE FROM orders没有WHERE会警觉，Agent不会

• 缺少上下文理解：Agent不知道orders表在业务中的重要性

• 执行速度快：人类操作有天然的“犹豫时间”，Agent是毫秒级执行

风险2：越权——Agent的权限边界不清

很多团队为了让Agent“能干活”，直接给了高权限账号。但Agent应该能访问哪些表？能执行哪些操作？这些边界如果没有明确定义，Agent的权限可能远超实际需要。

风险3：失控——Agent行为的不可预测性

Agent的决策路径是动态的。同一个任务，Agent可能这次用UPDATE，下次用DELETE。如果没有行为约束和审计机制，出了事故根本查不到原因。

二、三层安全机制：从隔离到兜底

第一层：只读沙箱——让Agent在安全环境中探索

核心思路：Agent可以在沙箱中自由查询，但改不了生产数据。

实现方式有两种：

• 物理隔离：为Agent分配一个独立的只读从库，Agent的查询全部路由到从库执行。即使Agent写了DELETE，影响的也只是从库，不影响主库。

• 权限隔离：通过数据库的细粒度权限控制，为Agent分配只读账号。Agent只能执行SELECT，任何写操作直接报错。

金仓KES支持基于RBAC（角色访问控制）的细粒度权限分配，可以为Agent单独创建一个账号，只授予特定表的SELECT权限，不授予任何INSERT、UPDATE、DELETE权限。从数据库层面强制隔离Agent的写操作。

第二层：操作预演——让Agent“先模拟再执行”

核心思路：Agent执行变更前，先模拟执行，告诉它会影响多少行。

具体做法：

• Agent生成变更SQL后，不直接执行，而是先以SELECT形式运行一遍，统计影响行数

• 如果影响行数超过阈值（比如1000行），触发人工审核流程

• 只有影响行数在安全范围内，才允许执行

这个机制的价值在于：Agent自己可以看到“如果我执行了，会发生什么” 。如果它发现自己要删100万行，应该有机制让它停下来。

第三层：自动回滚——万一错了，能一键恢复

核心思路：任何变更都有退路。

实现方式：

• 事务包裹：Agent的变更操作放在事务中执行，如果执行过程中发现异常，立即ROLLBACK

• 快照备份：执行高风险操作前，对相关表做快照

• 操作日志：所有Agent操作全部记录，包括SQL语句、执行时间、影响行数、执行结果

金仓KES的审计机制通过加载数据库内核审计插件，实现对数据库内部动作的原生捕获，可以精确记录Agent执行的每一条SQL、登录行为及权限变更操作。一旦出现异常操作，审计日志可以提供完整的追溯证据链。

三、金仓KES的三权分立：从权限层面管住Agent

除了上述三层机制，数据库层面的权限设计也很关键。

金仓KES引入了三权分立机制，将传统超级管理员的权限拆解为三个独立角色：

• 系统管理员（DBA） ：负责数据库启动、停止、备份恢复、参数调优、账号创建。不能查看业务数据，不能修改数据结构。

• 数据管理员（DA） ：负责数据库对象创建、权限分配、数据增删改。不能管理底层运行状态，不能查看审计日志。

• 安全审计员（AA） ：负责查看所有操作日志、审计记录。不能修改数据，不能执行管理命令。 审计日志具有防篡改特性，系统管理员和安全保密员无法删除或修改。

对于Agent场景，这套机制的价值在于：即使Agent的账号被盗用或出现异常行为，它能造成的破坏被严格限制在数据管理权限范围内——不能修改数据库配置、不能删除审计日志、不能绕过监控。

四、Agent安全操作的落地框架

综合以上能力，一个可落地的Agent安全操作框架应该包含：

层级	机制	解决的问题
接入层	只读沙箱/权限隔离	Agent默认只能读，写操作需要显式授权
执行层	操作预演+阈值告警	变更前预判影响范围，超阈值触发人工审核
事务层	事务包裹+快照备份	变更可回滚，数据有退路
审计层	全量操作日志+防篡改审计	所有Agent行为可追溯、可定责
权限层	三权分立+RBAC细粒度控制	即使账号被盗，破坏范围可控

五、小结

Agent操作数据库的安全问题，不是“要不要用Agent”的问题，而是“怎么安全地用Agent”的问题。只读沙箱让Agent有探索的空间但不越界，操作预演让Agent在执行前“看到后果”，自动回滚为失误兜底，三权分立从权限层面限制破坏范围。这些机制组合在一起，才能让Agent真正成为DBA的助手，而不是隐患。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~