没有权限，AI Agent 也读不到数据：NineData 数据库安全管控实测
【摘要】 AI Agent 没有权限还能读取数据库吗？本文通过查询、新增和 DELETE 三条实际操作链路，验证 NineData 如何使用 AccessKey、细粒度权限、SQL 规则、人工审批和审计控制 Agent 的数据库访问，并分析直连旁路、提示注入、规则绕过与凭证泄露等安全边界。
当 AI Agent 可以自行调用工具、查询数据和提交 SQL 时，企业需要验证一个基础问题：原本约束人的数据库权限和审批制度，是否同样约束 Agent？
我们使用一个没有数据源、库和表权限的普通用户，通过 WorkBuddy 调用 NineData Skill，依次测试了三条操作链路：读取无权访问的表、向表中新增数据、提交 DELETE。结果显示，在经 NineData Skill/OpenAPI 访问数据库的路径上，AccessKey 只解决调用身份问题，并不会附带数据库权限；读取、写入和任务提交分别受权限控制；数据变更还要经过 SQL 规则预审和审批。
本文验证的是 NineData 管控链路能否对正常工具调用和越权请求做生效，并在后文单独说明直连数据库、提示注入、规则绕过和 AccessKey 泄露等尚未覆盖的边界。并非对所有 Agent 安全风险的完整渗透测试。
测试范围与环境
本次验证使用的组件和初始条件如下：
|
项目
|
测试设置
|
|
Agent 客户端
|
WorkBuddy
|
|
数据库访问入口
|
NineData Skill
|
|
调用凭证
|
NineData AccessKey
|
|
测试用户
|
普通用户
|
|
初始数据权限
|
无数据源权限、无库权限、无表权限
|
|
验证操作
|
查询、新增数据、DELETE
|
|
观察位置
|
Agent 返回结果、权限申请与审批、SQL 任务、规则预审、任务执行结果
|
测试步骤保持一致：先在 NineData 控制台确认用户权限，再向 Agent 提供 Skill 地址和 AccessKey，由 Agent 发起操作，最后回到 NineData 查看权限提示、审批状态、规则预审和执行结果。
需要强调，以下结果只适用于请求经过 NineData Skill/OpenAPI 并由 NineData 连接数据库的情况。如果 Agent 同时持有数据库连接串，并能使用其他工具绕过 NineData 直连数据库，本文验证的控制链路不会自动覆盖。
准备：AccessKey 负责识别调用身份，不等于数据库权限
测试用户登录 NineData 控制台后，可以在「账户管理—我的权限」中查看模块权限、数据源权限和库表权限。初始状态下，该用户没有数据源、库和表权限，AccessKey 功能也尚未开启。
【截图1：普通用户在「我的权限」中无数据源、库和表权限】
管理员需要先在用户管理中为该用户开启 AccessKey 功能。开启后，用户可以在「账户管理—AccessKey」中新建凭证。AccessKey 用于调用 NineData OpenAPI 和 NineData Skill，与控制台登录密码和底层数据库账号密码相互独立；还可以为不同 Agent 或集成场景创建不同的 AccessKey，分别管理其状态和访问来源。
【截图 2：用户未开通 AccessKey 的提示】
用户联系管理员，管理员在 用户管理 找到该组织下的用户 ，选择 开启 AccessKey
开启之后 用户可以在 账户管理- AccessKey 里面 新建 AccessKey
【截图 3：创建 AccessKey 的页面】
创建结果页只显示一次 SecretKey。它应保存在受限的密钥管理系统或 Agent 的安全配置中，不能进入代码仓库、日志、文档、截图或对话；遗失后应创建新密钥。
【截图 4：SecretKey 仅显示一次的安全提示。发布前应确认截图未暴露真实密钥】
这里容易产生一个误解：拿到 AccessKey 并不代表拿到了数据库的读取或写入权限。AccessKey 用来确认“谁在调用”，该身份能访问哪些数据仍取决于 NineData 中已批准的权限。
测试一：查询无权访问的表
初始条件
测试用户已能使用 AccessKey，但没有目标数据源、数据库和表的查询权限。
操作步骤
-
在 NineData 工作台下载 Skill。
-
向 WorkBuddy 提供 Skill 地址和测试用户的 AccessKey。
-
要求 Agent 查询一张当前用户无权访问的表。
-
观察 Agent 返回结果，并在 NineData 控制台检查权限状态。
【截图 5：NineData 工作台中的 Skill 下载入口】
实际结果
Agent 成功进入 Skill 调用，但 NineData 检查到当前身份缺少目标数据源或表的查询权限，没有返回目标数据，并提示申请相应权限。
【截图 6：Agent 发起查询后，NineData 返回权限不足并提示申请】
随后，用户进入「账户管理—权限申请与审批」申请目标权限。申请页面可以按数据源、库和表选择授权范围，权限类型包括只读、DML、DDL 和任务提交；有效期可选择 7 天、30 天、60 天、半年、1 年、3 年或自定义时间。建议结合 AccessKey 在 Agent 侧的保存与使用方式，遵循最小权限和短有效期原则，设定安全的权限有效期。
【截图 7：权限申请页面中的资源范围、权限类型和有效期】
提交后，用户可以在「权限申请与审批」中看到工单状态。审批通过后，使用同一 Agent 再次查询，操作成功并返回结果。
【截图 8：权限申请状态，以及审批通过后的查询结果】
这一轮验证了什么
在 NineData 管控路径内，AccessKey、Skill 调用能力和数据读取权限是分开的。Agent 能发起查询，但没有被授予相应数据权限时，平台不会返回目标数据。权限由审批流程授予，并可限制到具体资源、操作类型和有效时间。
这一轮没有验证提示注入能否影响 Agent 的工具选择，但它验证了一个关键下限：即使自然语言指令要求 Agent 查询目标表，只要调用仍经过 NineData，指令本身不能把无权限身份变成有权限身份。
测试二：只有查询权限时尝试新增数据
初始条件
测试用户已经通过上一轮审批获得查询权限，可以读取目标表，但尚未获得完成数据写入所需的 DML 和 SQL 任务提交权限。
操作步骤
-
要求 WorkBuddy 向目标表新增一条测试数据。
-
观察权限检查结果。
-
申请 DML 与 SQL 任务提交权限。
-
审批通过后重新提交新增操作。
-
在 NineData 的「SQL 任务」页面检查规则审查、审批和执行状态。
实际结果
第一次新增操作没有因为用户已经能查询该表而被直接执行。NineData 提示申请更高权限，说明查询权限不会自动覆盖新增、修改和删除。
【截图 9：Agent 尝试新增数据后收到权限申请提示】
获得 DML 与 SQL 任务提交权限后，Agent 可以提交新增任务，但任务仍没有立即执行。在 NineData 中可以看到新建的 SQL 任务：任务先经过规则审查，通过后进入审批，审批通过并启动任务后才完成写入。
【截图 10：新增数据任务在 SQL 任务页面依次经过规则审查、审批和执行】
通过审批之后最终完成 执行：
这一轮验证了什么
NineData 把“能读表”“能修改表”和“能提交任务”作为不同能力管理。Agent 可以协助发起权限申请或 SQL 任务，但申请动作不等于批准，提交任务也不等于执行。对于希望先从只读 Agent 起步的企业，这种分级可以避免一次查询授权演变成长期写权限。
测试三：提交 DELETE，观察规则预审与审批
初始条件
测试用户已经具备提交相关 SQL 任务的权限，NineData 的 SQL 开发规范将 DELETE 配置为禁止操作。
操作步骤
-
向 WorkBuddy 提交删除数据的需求。
-
在 NineData 的 SQL 任务中查看规则预审结果。
-
在「规范与流程—SQL 开发规范」中核对命中的规则。
-
由管理员根据业务需要调整规则强度。
-
重新提交任务，完成审批后启动执行。
实际结果
Agent 创建的 DELETE 任务出现在 SQL 任务页面，但规则预审未通过。在 SQL 开发规范中可以看到，当时的平台规则明确禁止 DELETE，因此任务不能继续进入执行阶段。
【截图 11：DELETE 任务、规则预审未通过及禁止 DELETE 的规则配置】
管理员重新评估需求后，将相关规则从强制阻断调整为风险提醒。调整后任务可以继续推进，但并未直接执行，仍需提交审批。审批通过并启动任务后，删除操作完成，WorkBuddy 返回执行结果，NineData 工作台也保留了任务完成记录。
【截图 12：规则调整、任务审批、执行完成和 WorkBuddy 返回结果】
这一轮验证了什么
权限检查回答“该身份是否可以发起这类操作”，SQL 规则回答“这条语句是否符合企业规范”，审批回答“本次风险是否允许放行”。三者不是同一个开关。管理员可以按业务需要改变规则强度，但规则放宽后，审批环节仍可继续约束执行。
本轮只验证了测试中这条 DELETE 语句能够被现有规则识别，没有对注释拆分、编码、动态 SQL、存储过程或其他 SQL 变形进行系统模糊测试。对安全要求较高的企业，应使用自己的高风险 SQL 样本库进行专项验证，并持续更新规则。
四层控制各自解决什么问题
经过三轮操作，NineData 在这条访问路径中的作用可以拆成四层。
|
控制层
|
本次观察到的机制
|
解决的问题
|
不能单独解决的问题
|
|
身份与凭证
|
Agent 使用独立 AccessKey 调用 Skill/OpenAPI
|
区分调用身份，避免向 Agent 暴露数据库真实密码
|
无法约束绕过 NineData 的数据库直连；AccessKey 仍需妥善保管
|
|
资源与操作权限
|
按数据源、库、表、只读、DML、DDL、任务提交和有效期授权
|
防止越权读取，分开读写能力，减少长期过度授权
|
已授权范围内的错误操作仍需其他控制
|
|
SQL 规范与审批
|
SQL 任务先规则预审，再按流程审批和执行
|
在执行前拦截或提示高风险 SQL，由人员对关键变更兜底
|
规则覆盖度取决于配置，审批质量取决于流程和人员
|
|
任务记录与审计
|
平台保留调用身份、时间、目标数据源、SQL 与任务状态等记录
|
支持复核、追责和合规审查
|
审计主要是发现和追溯手段，不能替代事前权限控制
|
这套设计的核心增量，是把 Agent 的工具调用纳入企业已有的数据库治理链路。Agent 提高了发起查询、申请和任务的速度，平台负责验证身份、权限和 SQL，审批人保留关键决策权。
企业更关心的边界问题
1. Agent 如果通过其他工具直接获得数据库连接串怎么办？
NineData 只能管控经过 NineData 的访问。如果 Agent 同时能从环境变量、代码仓库、聊天记录或其他工具中获得数据库连接串，并具备直连网络条件，它可能绕过 NineData。
企业需要同步治理旁路：不要向 Agent 提供数据库真实密码；隔离 Agent 运行环境；限制到数据库的网络路径；统一使用受控 Skill/OpenAPI；扫描代码仓库和日志中的密钥；对数据库侧保留最小权限和连接审计。NineData 是受控入口，不会自动消除环境中已有的其他入口。
2. 提示注入能否诱导 Agent 访问未授权数据源？
提示注入可能改变 Agent 的意图、参数或工具选择，但不能直接修改 NineData 中该身份已经获批的权限。只要请求仍经过 NineData，访问未授权数据源或表时应受到同样的权限检查。
风险在于 Agent 是否还能调用其他不受控工具，或者被诱导在已有权限范围内批量读取不必要的数据。因此，权限设计不能只问“是否允许访问”，还要限制数据范围、操作类型、有效期和每个 Agent 的用途，并对异常调用进行监控。本次测试没有执行专门的提示注入攻击，企业上线前仍应加入这类测试。
3. AccessKey 泄露后，会发生什么？
AccessKey 不会直接暴露底层数据库密码，但泄露者可能冒用该身份调用 NineData，并在该身份已有的权限范围内发起查询或任务。风险大小取决于权限范围、有效期、访问来源限制以及后续审批要求。
因此，AccessKey 应按 Agent 和场景独立创建，授予完成任务所需的最小权限，限制来源并定期轮换；不再使用或发生泄露时应立即禁用。平台审计可以帮助调查，但不能抵消凭证泄露期间已经发生的合法接口调用。
与两种常见方案相比，NineData 增加了什么？
企业通常还会考虑直接给 Agent 一个数据库只读账号，或主要依赖数据库原生权限和审计。三类方案的侧重点不同。
|
方案
|
优点
|
局限或代价
|
更适合的场景
|
|
Agent 直接使用只读数据库账号
|
架构简单、链路短、查询延迟低
|
凭证进入 Agent 环境；常以库或实例为单位授权；临时授权、申请审批和跨数据源治理需要另建系统；难以安全扩展到写操作
|
数据范围固定、纯只读、风险较低的内部场景
|
|
数据库原生权限与审计
|
离数据最近，权限和日志具有基础保障；无需额外代理所有流量
|
不同数据库的能力和配置方式不一；跨数据库统一授权、工单审批、SQL 规范和 Agent 身份治理成本较高
|
作为任何架构都应保留的底层防线
|
|
NineData Skill/OpenAPI + 平台管控
|
不向 Agent 交付数据库真实密码；统一管理多数据源；支持细粒度限时权限、SQL 规范、审批和任务审计
|
增加一个平台与调用链路；审批会带来必要等待；需要部署配置、规则维护和可用性保障
|
多 Agent、多数据源、需要写操作或有审计合规要求的企业
|
NineData 的主要价值是在 Agent 与数据库之间补上统一的身份、申请、规则和流程层。相应代价也应被纳入选型：企业需要维护平台、权限模型和 SQL 规则；任务预审与人工审批会增加延迟；调用链路增加后，还应评估可用性、吞吐量和故障处理方式。
本次不提供性能压测、部署耗时或与其他产品的量化数据，因此本文不对性能开销和总体成本给出数字结论。正式选型时，企业可以根据自己的数据源数量、并发量、审批时效和高风险 SQL 样本做概念验证。
企业落地 Agent 数据库访问的建议
-
先收口入口。 确认 Agent 只能通过受控的 Skill/OpenAPI 访问数据库，清理连接串和共享高权限账号。
-
为每个 Agent 建立独立身份。 不同 Agent、环境和用途使用不同 AccessKey，避免多人多 Agent 共用凭证。
-
从短期只读权限开始。 权限限制到必要的数据源、库、表和时间段，验证业务价值后再增加 DML 或任务提交能力。
-
把高风险 SQL 样本变成规则。 除 DELETE 外，还应覆盖无条件 UPDATE、DROP、TRUNCATE、大范围影响和敏感表操作，并测试常见变形方式。
-
保留人工审批与数据库底层防线。 Agent 可以发起申请和任务，生产变更的批准、备份、事务控制及数据库原生审计仍应由企业掌握。
-
持续审查权限和调用记录。 关注异常时间、异常来源、突增查询量、跨数据源访问和连续失败，及时吊销不再使用的 AccessKey。
常见问题
AI Agent 接入 NineData Skill 后，可以直接查询所有数据库吗？
不可以。Skill 提供调用入口，实际访问仍取决于 AccessKey 对应身份拥有的数据源、库、表和操作权限。实测中，没有查询权限时，NineData 没有返回目标数据，而是提示申请权限。
AccessKey 等同于数据库账号和密码吗？
不等同。AccessKey 是 NineData OpenAPI 和 Skill 的调用凭证，Agent 不需要因此持有数据库真实密码。但 AccessKey 仍是敏感凭证，泄露者可能在对应身份的授权范围内冒用接口。
Agent 有查询权限后，可以修改或删除数据吗？
不能仅凭查询权限执行写操作。实测中，新增数据需要进一步获得 DML 和 SQL 任务提交权限，任务还要经过规则审查和审批。
Agent 可以自己申请并批准权限吗？
Agent 可以在具备相应能力时协助发起申请或任务，但本次流程中的审批与授权仍由 NineData 配置的流程和人员完成。发起动作不会自动获得批准。
使用 NineData 后，还需要数据库原生权限和审计吗？
需要。NineData 提供 Agent 与数据库之间的统一治理层，数据库原生账号权限、网络隔离、备份恢复和审计仍是底层防线。两者结合会更稳妥。
结论
三轮测试支持一个范围明确的结论：当 Agent 通过 NineData Skill/OpenAPI 访问数据库时，没有相应数据权限就无法读取目标数据；只读权限不能用于新增、修改或删除；获得写入和任务提交权限后，SQL 仍可受到规则预审和人工审批约束。
这套机制对企业的意义，在于不必把数据库真实密码和不受限的执行权直接交给 Agent。企业可以让 Agent 发起查询、权限申请和 SQL 任务，同时用独立身份、细粒度限时权限、SQL 规则、审批和审计控制最终结果。
【版权声明】本文为华为云社区用户转载文章，如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）