当 AI Agent 开始执行 SQL，企业该如何守住数据库安全底线
【摘要】 AI Agent 开始执行 SQL 后，企业如何防止越权读取、误删数据和高风险 SQL 直接落库？本文从 AccessKey、细粒度权限、读写分离、SQL 规则预审、人工审批和审计溯源六个方面，结合 NineData Skill/OpenAPI 场景给出数据库安全底线与上线检查表。
AI Agent 从“回答问题”走向“执行 SQL”，数据库安全的风险边界随之改变。过去，企业主要管理人的账号、数据库权限和 SQL 变更流程；现在，Agent 可以根据自然语言自动生成查询、调用工具、申请权限，甚至提交数据变更任务。真正需要回答的问题不再是“要不要让 Agent 连接数据库”，而是：
Agent 能访问哪些数据？能执行哪些 SQL？高风险操作谁来批准？出现问题后能否追溯？
对企业而言，安全底线可以归纳为一句话：让 Agent 获得完成任务所需的自动化能力，但不要让它获得绕过身份、权限、规则和审批的能力。
底线：Agent 可以发起，平台决定边界
一个可落地的 Agent 数据库安全模型，需要回答四个问题：
-
身份是谁？ 每个 Agent 或集成场景是否有独立、可吊销的调用凭证？
-
能看什么？ 权限是否细化到数据源、库、表、操作类型和有效期？
-
能做什么？ 查询、DML、DDL 和 SQL 任务提交是否分级控制？
-
如何放行？ 高风险 SQL 是否会预审，关键变更是否仍需人工审批，操作是否留下完整记录？
如果这些问题只能依靠 Agent 自己的提示词或模型判断来回答，企业的安全边界就变得脆弱。更稳妥的方式是把决策放在 Agent 之外，由统一的平台策略强制执行。
NineData 的产品方式正是沿着这条思路展开：Agent 通过 Skill 或 OpenAPI 发起请求，NineData 根据调用身份、已授权资源、操作类型和 SQL 规则进行校验；需要变更时，再进入权限申请、规则预审和审批流程。
第一条底线：不要把数据库真实密码交给 Agent
Agent 如果直接持有数据库连接串和高权限账号，提示注入、配置泄露、运行环境被入侵或模型误操作，都可能直接影响数据库。企业首先要做的是把“调用 Agent”和“连接数据库”拆开。
在 NineData 中，Agent 使用 AccessKey 调用 NineData OpenAPI 或 NineData Skill。AccessKey 与 NineData 控制台登录密码以及底层数据库账号密码相互独立，平台代为连接数据库。这样，Agent 不需要在任务上下文、代码仓库或对话中保存真实数据库密码。
AccessKey 解决的是“哪个身份在调用”，并不等同于数据库权限。企业还可以针对不同 Agent、环境和集成场景创建不同凭证，分别管理状态和访问来源。SecretKey 只在创建结果页显示一次，应放入受限的密钥管理系统或安全配置中，不能写入日志、代码、截图、文档或对话。
当然AccessKey 泄露者仍可能在该身份已有的授权范围内调用接口。因此，凭证隔离必须与最小权限、来源限制、轮换、及时禁用和审计结合使用。
第二条底线：没有权限，就没有数据
企业应先从最小权限开始，而不是先给 Agent 一个可以查询整个数据库的账号。
NineData 支持围绕数据源、库、表、操作类型和有效时间进行授权。权限可以区分为只读、DML、DDL 和 SQL 任务提交，并可设置 7 天、30 天、60 天、半年、1 年、3 年或自定义有效期。
这类授权模型适合 Agent 的渐进式上线：一个只负责知识问答的 Agent 可以只开放指定表的读取权限；一个负责数据修复的 Agent，则需要经过额外审批后获得限定范围的 DML 和任务提交能力。
在已核验的实际操作链路中，测试用户没有目标数据源、库和表权限，却通过 WorkBuddy 调用 NineData Skill 查询目标表。请求能够进入 Skill，但 NineData 检查到缺少查询权限后没有返回数据，而是提示申请相应权限。
这说明三件事：Skill 是调用入口，不是数据通行证；AccessKey 是身份凭证，不是全库授权；自然语言指令不能把无权限身份变成有权限身份。
第三条底线：查询权限不能自动升级为写权限
Agent 最容易被低估的风险，是“看起来只是查询”，实际却拥有修改数据的能力。企业应把读取和写入明确分开，并把 SQL 任务提交作为单独能力管理。
在另一轮操作中，测试用户已经获得目标表查询权限，但没有 DML 和 SQL 任务提交权限。WorkBuddy 尝试向表中新增一条数据，NineData 没有因为已有查询权限而直接执行，而是提示申请更高权限。
权限申请通过后，Agent 可以提交新增数据任务，但任务依然不会立即执行。SQL 任务要先经过规则审查，再进入审批，审批通过并启动后才完成写入。
企业因此可以建立清晰的权限阶梯：
|
能力
|
典型授权
|
风险控制重点
|
|
读取
|
指定数据源、库、表的只读权限
|
限制数据范围、敏感字段和有效期
|
|
新增、修改、删除
|
DML 权限
|
限制目标表、影响范围和执行窗口
|
|
结构变更
|
DDL 权限
|
更严格的审批、备份和回滚要求
|
|
提交 SQL 任务
|
SQL 任务提交权限
|
规则预审、人工审批和任务审计
|
Agent 可以帮助发起申请，但“发起”不等于“批准”。这一区分对于防止权限自我升级非常关键。
第四条底线：高风险 SQL 不能只靠 Agent 自我判断
模型可能生成语法正确但业务危险的 SQL，例如无条件 UPDATE、大范围 DELETE、DROP、TRUNCATE 或操作敏感表。企业不能只在提示词中写“请谨慎操作”，应在 SQL 执行前设置平台规则。
NineData 的 SQL 任务会先经过规则预审。已核验的测试中，DELETE 被配置为禁止操作。Agent 提交删除任务后，任务出现在 SQL 任务页面，但规则预审未通过；在「规范与流程—SQL 开发规范」中可以看到对应的禁止规则，因此任务不能继续执行。
规则可以根据业务风险配置为强制阻断或风险提醒。测试中，管理员将 DELETE 从强制阻断调整为风险提醒，任务得以继续推进，但仍必须经过审批，审批通过并启动后才最终执行。规则放宽不等于取消治理，而是把“直接拦截”调整为“风险提示 + 后续审批”。
企业应注意，这一机制的有效性取决于规则覆盖率和配置质量。正式上线前，可以使用企业自己的风险 SQL 样本测试注释、大小写、嵌套语句、动态 SQL、存储过程、多语句执行和编码差异，并在数据库侧保留备份、事务、影响行数限制和高危账号隔离。
第五条底线：关键变更必须有人批准
自动化的价值在于减少重复操作，不在于取消责任边界。涉及生产数据的新增、修改和删除，应让 Agent 负责准备和提交，让平台负责校验，让授权人员负责关键放行。
NineData 的任务流程把 SQL 规则审查和权限审批分开。即使 Agent 已具备提交任务的权限，任务也可能因规则不符合而被阻断；即使规则层面放行，涉及数据变更的任务仍可进入人工审批。关键的批准和拒绝动作由明确的用户完成，Agent 不能审批自己的任务。
这比“Agent 直接拿一个写权限账号”多了一层重要控制：模型可以提高执行效率，但不能同时成为申请人、审核人和执行人。
第六条底线：每一次调用都要能解释
数据库安全不仅是阻止危险操作，还包括事后回答：谁在什么时间，通过哪个 Agent，对哪个数据源执行了什么 SQL，影响了哪些数据？
通过 NineData Skill 或 OpenAPI 发起的操作，会在平台留下与身份、时间、目标数据源、SQL 语句和任务状态相关的记录。这样，企业可以把 Agent 行为纳入现有的审计、复核和责任追踪体系。
审计不能替代权限和审批，但它能让企业知道控制是否真正生效，也能帮助发现异常调用，例如短时间大量读取、跨数据源访问、连续权限失败或非工作时段提交任务。
企业需正视的四个旁路风险
Agent 还能使用其他数据库工具吗？
NineData 只能管控经过 NineData 的访问。如果 Agent 同时能从环境变量、代码仓库或其他工具中获得连接串，并具备直连网络条件，它可能绕过 NineData。因此，企业需要收口工具入口、隔离运行环境、限制网络路径，并清理共享高权限账号。
提示注入能否改变数据库权限？
提示注入可能改变 Agent 的意图或参数，但不能直接修改 NineData 中已经批准的权限。只要请求仍经过 NineData，访问未授权数据源和表时仍会进行权限检查。但如果 Agent 能调用其他不受控工具，风险会转移到旁路，因此权限控制不能替代工具隔离和输入安全测试。
SQL 规则能否识别所有变形？
企业应将 SQL 规则当作纵深防御的一层，结合最小权限、审批、数据库原生权限、备份和回滚，而不是把所有安全责任押在关键词拦截上。
AccessKey 泄露后怎么办？
立即禁用或轮换凭证，检查其授权范围和调用记录，确认是否存在异常来源、异常时间或异常数据访问，再根据需要收缩权限。AccessKey 隔离可以减少影响范围，但不能替代密钥生命周期管理。
NineData 的增量价值？
企业也可以直接给 Agent 一个只读数据库账号，或者依赖数据库原生权限和审计。NineData 的增量价值主要体现在 Agent 与数据库之间增加了统一治理层：
|
方案
|
能解决什么
|
仍需补充什么
|
|
Agent 直接使用只读账号
|
架构简单，适合固定范围的低风险查询
|
凭证进入 Agent 环境；临时授权、审批和跨数据源统一治理需要另建机制
|
|
数据库原生权限与审计
|
提供离数据最近的底层权限和记录
|
不同数据库之间的统一权限、SQL 规范、工单和 Agent 身份治理成本较高
|
|
NineData Skill/OpenAPI
|
独立身份、细粒度限时权限、SQL 规则、审批和任务审计集中管理
|
增加平台配置和调用链路；审批、规则维护和可用性需要企业持续运营
|
NineData 不是数据库原生安全的替代品，也不消除 Agent 环境中的所有旁路。它适合多 Agent、多数据源、需要写操作或需要将自动化纳入审计和审批体系的企业。
一套可执行的上线检查表
上线前，企业可以按以下顺序检查：
-
Agent 是否只能通过受控 Skill/OpenAPI 访问数据库？
-
是否为每个 Agent、环境和用途创建独立 AccessKey？
-
是否从指定数据源、库、表和短期只读权限开始？
-
查询、DML、DDL 和任务提交是否分级授权？
-
DELETE、无条件 UPDATE、DROP、TRUNCATE 和敏感表操作是否有规则？
-
生产变更是否需要明确的人工审批？
-
是否能够按 Agent 身份、时间、SQL 和影响范围查询操作记录？
-
是否测试过提示注入、SQL 变形、凭证泄露和直连旁路？
-
数据库侧是否保留原生权限、网络隔离、备份、事务和回滚能力？
-
是否有 AccessKey 轮换、禁用和异常调用响应流程？
结论：把自动化能力放进制度，而不是把制度交给模型
当 AI Agent 开始执行 SQL，企业不能只问“模型是否足够聪明”，还要问“即使模型犯错，平台能否把影响限制住”。
基于已核验的 NineData 操作链路，可以得到一个范围明确的结论：经 NineData Skill/OpenAPI 访问时，没有数据权限就无法读取；查询权限不能自动升级为写权限；数据变更可以经过 SQL 规则预审、权限审批和任务审计。
这套机制的核心是让 Agent 的自动化请求进入企业已有的身份、权限、规范、审批和审计体系。与此同时，企业仍需治理直连数据库、提示注入、规则绕过和 AccessKey 泄露等旁路风险，并保留数据库原生安全能力。
可持续的底线是：Agent 可以提高 SQL 操作的效率，但不能成为权限的来源、规则的例外和审批的替代者。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）