AI Agent、ChatDBA、Text2SQL、AI Coding 和自动化运维流程正在进入企业研发与数据库管理体系。过去，数据库访问主体主要是开发、测试、DBA、运维和业务分析人员；现在，能够生成 SQL、调用 OpenAPI、触发任务流的 Agent 也开始成为新的数据访问主体。

这带来了一个直接问题：数据库权限边界该如何定义？

传统权限管理关注“谁能登录数据库”“谁能查询表”“谁能执行变更”。Agent 进入后，还需要回答更多问题：

• 这个 Agent 是否有独立身份？

• Agent 能访问哪些数据源、库、表、列？

• Agent 生成的 SQL 是否经过规则审核？

• 涉及生产环境时是否需要审批？

• 查询结果中包含敏感数据时如何脱敏？

• OpenAPI 调用能否追踪到具体凭证和调用方？

• 事后能否还原完整访问链路？

企业级智能体落地的关键挑战，已经从“能否生成 SQL”转向“能否在生产环境中被可信接入、精细约束、持续审计，并在安全边界内参与诊断与闭环处理”。

这也是数据库 Agent 从演示走向生产必须补齐的底座能力。

人和 Agent 并存后，数据库访问风险发生了变化

在传统模式下，企业通常通过数据库账号、堡垒机、VPN、客户端工具、工单系统来管理数据库访问。只要账号、权限和审批流程配置合理，大多数风险可以被控制在人的操作范围内。

Agent 加入后，访问链路变长了。

一个自然语言请求可能经过 ChatDBA、SQL 生成器、企业知识库、OpenAPI、SQL 审核、审批流程，再落到具体数据库。这个过程中，风险可能出现在多个环节：

• Agent 复用开发人员账号，导致身份边界混乱。

• Agent 使用高权限数据库账号，权限范围被过度放大。

• 自然语言意图模糊，生成 SQL 命中了错误的库、表或字段。

• 查询语句合法，但返回结果包含手机号、身份证号、银行卡号等敏感数据。

• DDL、DML 变更绕过审批，直接作用于生产环境。

• OpenAPI Token 或 AccessKey 被开发人员复制后私下调用。

• 多工具、多账号、多入口并存，事后无法完整审计。

因此，企业要管住人和 Agent 的数据库访问，不能只依赖单个数据库账号，也不能只依赖人工审核。更可行的方式是建立一套覆盖身份、入口、权限、SQL 准入、敏感数据、审计日志的数据库 DevOps 治理体系。

入口治理：从“一刀切统一”改为“分阶段纳管”

很多企业希望所有数据库访问都通过统一平台完成，但真实 IT 环境通常更复杂。

存量业务系统、遗留应用、第三方供应商系统、历史脚本、临时运维工具，往往已经直连数据库多年。一次性切断所有直连，容易影响业务连续性，也会遇到组织协同和技术改造成本问题。

更成熟的做法是分阶段纳管：

第一阶段，优先纳管高风险访问。

例如生产库变更、敏感数据查询、批量导出、DDL/DML 操作、AI Agent 调用、自动化任务调用等场景，都应该先从“个人工具直连、脚本直连、账号共享”的模式中剥离出来，进入统一的权限控制、SQL 审核、审批流程和审计体系。

在这一阶段，NineData 数据库 DevOps 可以作为高风险数据库访问的统一治理入口，承接 SQL 开发、SQL 审核、变更审批、敏感数据保护、操作审计和 Agent 访问控制等流程。企业不需要一开始改造所有存量链路，而是先把生产变更、敏感查询和 Agent 调用这类关键入口管起来。

第二阶段，保留必要的存量直连，但收紧边界。

对暂时无法改造的老系统，可以继续保留最小权限账号，并配合网络白名单、安全组、数据库审计、账号有效期和变更窗口进行控制。

第三阶段，通过网关和私网连接逐步收敛访问路径。

NineData 提供了网关能力，可用于远程访问私网数据库。企业可以通过部署网关，将第三方云或本地数据库接入 NineData，无需为数据库申请外网地址。对于局域网中无法访问公网的主机，NineData 还提供代理网关方式，通过可访问公网的主机完成代理连接。

第四阶段，将 Agent 和自动化流程纳入统一控制面。

智能体想要进入生产环境，第一步是先让它和人一样，进入统一、可控、可审计的数据库工程体系。

NineData 的数据库 DevOps 方案，本质上是把数据库相关工作从“分散工具行为”升级为“平台化工程流程”。

在这套体系里，数据库设计、查询、变更、审核、审批、版本管理、CI/CD 集成、操作审计和性能治理不再分散在多个系统中，而是统一收敛到一个可治理的平台控制面中。

新建的 ChatDBA、Text2SQL、AI 运维助手、自动化脚本和 OpenAPI 调用，应从一开始接入 NineData 权限、审批、SQL 审核和审计体系，避免新系统继续制造新的权限孤岛。

这种路径更符合大型企业现状：先管高风险，再管新增入口，最后逐步治理历史链路。

身份治理：人、Agent、系统账号必须拆开

Agent 访问数据库时，比较危险的做法是复用自然人账号或生产高权限账号。

一旦 Agent 和开发人员共用账号，审计日志只能看到“某个用户做了操作”，无法判断到底是本人手工执行、Agent 自动生成，还是脚本调用。一旦 Agent 直接持有生产库高权限账号，任何 Prompt 注入、流程绕过、Token 泄露都可能扩大成生产事故。

NineData 数据库 DevOps 支持通过角色进行权限分组管理，也支持为单个用户配置自定义权限。企业可以按组织、团队、环境、数据源、库、表、列和操作类型配置权限。

人的身份账号与 Agent 的身份账号必须严格分离，权限应按照环境、数据源、库、表、列、动作类型和有效期进行精细授权，并在使用结束后自动回收。

其目标是让数据库访问主体始终可识别、可约束、可追责，避免高权限扩散成为系统性风险。

OpenAPI 鉴权：机器身份不能只靠一个静态 Token

安全团队关心的问题通常不是 Agent 能不能调用接口，而是调用凭证如何管理。

在程序化访问场景中，NineData OpenAPI 采用 AccessKey、SecretKey、timestamp 和 signature 进行接口鉴权。根据 NineData 请求头需要包含 access-key-id、timestamp 和 signature；签名由接口地址、SecretKey 和当前时间戳拼接后计算 SHA256 摘要生成。服务端会校验时间戳，超过 10 分钟的请求会被拒绝。

对企业接入 Agent 的场景，可以在此基础上进一步加强凭证治理：为 Agent 分配独立 AccessKey，避免复用自然人凭证；将 SecretKey 托管在企业密钥管理系统中；按 Agent 类型拆分权限范围；结合 IP 白名单、凭证轮换和审计日志降低凭证滥用风险。如果企业已有 API Gateway 或统一身份代理，也可以在企业侧先完成机器身份认证，再由受控服务调用 NineData OpenAPI。

这样可以把 Agent 的机器身份、接口凭证、调用来源和执行权限绑定起来，避免开发人员复制 Agent 凭证后绕过平台私自查数。

SQL 准入：Agent 生成的 SQL 必须先过规则

Agent 可以快速生成 SQL，但“生成成功”不等于“允许执行”。

在生产数据库中，SQL 准入至少要覆盖四类检查：

• 语法是否正确。

• 是否符合企业 SQL 开发规范。

• 是否涉及高危操作。

• 是否需要审批或回滚预案。

NineData 数据库 DevOps 提供 SQL 审批流、SQL 规范预检、审批流程、SQL 代码审核、结构设计与发布、数据追踪与回滚等能力。NineData SQL 开发规范提供 200 多条规则，可用于提升 SQL 质量、防止慢 SQL、减少潜在错误和性能问题。

对于 Agent 生成 SQL 的场景，可以将规则配置得更严格：

• 生产环境禁止无 WHERE 条件的 UPDATE 和 DELETE。

• DROP、TRUNCATE、ALTER 大表等高危操作必须进入审批。

• 解析失败的 SQL 不允许提交执行。

• 涉及敏感字段的查询触发脱敏或审批。

• 批量变更需要执行前备份和可回滚方案。

• DDL、DML、导入导出任务进入不同审批流程。

• Agent 创建工单后，不允许由同一 Agent 自动审批。

这样可以把风险控制前移到执行之前。Agent 仍然可以提升 SQL 生成和诊断效率，但最终执行要经过平台规则、审批流程和权限系统。

敏感数据保护：权限边界要延伸到列和结果集

数据库权限管理常见盲区是只控制“能不能查”，没有控制“查出来什么”。

一个 Agent 可能只执行了 SELECT，也没有访问未授权表，但结果集中包含手机号、证件号、银行卡号、地址、客户信息、交易记录等敏感数据。对企业来说，结果集本身也是权限边界的一部分。

NineData 敏感数据功能支持将数据源中的一个或多个列设置为敏感列，未授权用户无法查看对应列内容。NineData 支持 S0 到 S5 六个敏感等级，S1 到 S5 可对应不同审批流程；系统默认提供 27 条敏感数据类型和 33 条脱敏算法，支持自动识别、分类分级、脱敏和敏感数据大盘。

在 Agent 场景中，敏感数据保护可以形成三层控制：

• 字段识别：自动扫描数据源，识别敏感列。

• 分级授权：不同敏感等级绑定不同审批策略。

• 动态脱敏：未授权访问返回脱敏结果。

这意味着 Agent 即使具备查询能力，也只能在授权范围内看到数据。对敏感列的访问，可以通过审批、脱敏和审计进行约束。

审计追踪：每一次访问都要能还原上下文

企业允许 Agent 参与数据库工作流，前提是每一次访问都可以追踪。

一次完整审计至少要回答六个问题：

• 谁发起了访问？

• 是自然人、系统账号，还是 Agent？

• 访问发生在什么时间和什么来源 IP？

• 访问了哪个数据源、库、表或列？

• 执行了什么 SQL 或调用了哪个 OpenAPI？

• 是否经过权限校验、规则审核和审批流程？

NineData 审计日志主要记录“谁在何时对哪个对象进行了什么操作”，对象包括数据源、库、表、列、用户、任务等。审计日志页面还可以查看操作日志、SQL 执行日志和 OpenAPI 调用日志。数据库 DevOps 企业版支持查看 3 年内审计日志记录。

这对 Agent 治理非常关键，对智能体而言，这种可证明、可回放、可核查的审计能力，是其进入生产环境的信任基础。

这也是为什么 NineData 在数据库治理中始终将 SQL 操作审计、平台操作审计、审批流转和敏感数据访问轨迹 统一纳入平台审计体系。

ChatDBA：让数据库智能体运行在受控流程内

ChatDBA 是 NineData 提供的智能问答助手，支持数据库知识问答、企业知识检索、SQL 排障、性能诊断和日常数据管理咨询等场景。ChatDBA 可以结合 NineData 中已录入的数据源上下文回答问题，支持 Text2SQL 对话能力，也支持 SQL 执行 Skill，并可结合 SQL 执行 OpenAPI 完成自动化调用场景。

在权限边界视角下，ChatDBA 的价值在于把智能能力放进数据库 DevOps 体系中运行。

一个典型流程可以是：

• 开发人员用自然语言描述查询需求。

• ChatDBA 结合数据源上下文生成 SQL。

• SQL 进入权限校验和规范预检。

• 涉及生产库或敏感数据时触发审批或脱敏。

• SQL 执行结果进入审计日志。

• 如果发生报错，ChatDBA 结合错误信息、SQL、数据库类型和上下文给出诊断建议。

• 如果涉及慢 SQL、锁等待、长事务，ChatDBA 辅助分析性能风险和优化方向。

这种模式下，Agent 提升的是研发和运维效率，权限、审批、脱敏和审计仍由平台统一控制。

数据可信底座：避免 Agent 基于错误数据做判断

权限边界解决的是“谁能访问、访问什么、如何执行”。在多云、跨地域、国产化迁移、异地多活和实时同步场景中，还需要保证 Agent 访问的数据本身可信。

如果底层同步链路不稳定，或者源端和目标端数据不一致，Agent 的查询、诊断和自动化建议都可能偏离真实状态。

NineData 数据复制和数据对比能力可以作为延伸的数据可信底座。数据复制用于迁移、同步、容灾、多活和实时集成；数据对比用于校验结构和数据一致性。对于 Agent 场景，这些能力的意义在于减少“基于错误数据做正确推理”的风险。

它们与权限治理共同构成企业级数据库 Agent 的生产基础。

总结：企业落地用六层模型管住人和 Agent 的数据库访问

面向人和 Agent 并存的数据库访问场景，企业可以采用六层治理模型。

第一层：入口纳管

将生产库变更、敏感数据访问、Agent 调用、自动化任务优先接入 NineData。对存量直连系统，采用分阶段迁移、网关接入、网络白名单和最小权限账号治理。

第二层：身份隔离

区分自然人、Agent、系统账号和 OpenAPI 调用方。每类主体独立授权、独立凭证、独立审计。

第三层：凭证安全

程序化访问使用独立 AccessKey、SecretKey、timestamp 和 signature 鉴权。配合密钥托管、定期轮换、IP 白名单和 OpenAPI 调用日志，降低凭证滥用风险。

第四层：SQL 准入

通过 SQL 规范预检、SQL 代码审核、审批流程、高危规则拦截和回滚能力，让 Agent 生成的 SQL 进入工程化质量门禁。

第五层：敏感数据保护

通过敏感列识别、S0 到 S5 分级、脱敏算法和审批流程，把权限边界延伸到列级和结果集。

第六层：全链路审计

统一记录操作日志、SQL 执行日志和 OpenAPI 调用日志，让每一次数据库访问都能追踪到身份、对象、动作、时间、来源和结果。

当人和 Agent 同时访问数据库，企业需要重新定义数据库权限边界。

NineData 通过数据库 DevOps、ChatDBA、SQL 规范预检、审批流程、敏感数据保护、审计日志、OpenAPI、网关和代理网关等能力，为企业提供了一套面向 AI Agent 时代的数据访问治理方案。

对于正在建设 AI Agent、数据库 DevOps、多云数据库管理、数据安全治理和国产化迁移体系的企业来说，关键目标不是让 Agent 更快地访问数据库，而是让每一次访问都可识别、可约束、可审批、可审计、可回溯。

只有把人和 Agent 放进同一套受控数据库工程体系中，企业才能在提升研发与运维效率的同时，守住生产数据的安全边界。