当 AI Agent 被允许读取业务数据库，安全问题不再只是“数据有没有离开数据库”。Agent 会动态生成 SQL，会在一次推理中发起多条查询，也可能把复杂查询包装在正常业务语义里。单纯依赖数据库账号密码，已经很难区分正常访问和越权读取。金仓在发布会中将“库内生安全管控”列为 KES AI 数据库的三大核心能力之一，与库内语义构建、库内计算推理并列。其思路不是只强调数据留在库内，而是通过 MCP 隔离层、行级语义审计和输出校验，给 AI 访问数据库设置一套可执行的边界。
AI 查询数据库的新问题：凭据、权限和意图都变得不稳定
传统数据库访问通常由人或固定程序发起，SQL 相对可预期，权限边界也较清晰。AI Agent 则不同：查询语句由模型动态生成，可能嵌套复杂，也可能为了获取上下文而批量读取数据。一条全表扫描可能服务于数据分析，也可能成为敏感数据外泄前的探测动作。问题在于，仅看 SQL 本身，很难直接判断这是正常推理还是恶意指令。
更常见的工程隐患是，AI 应用直接持有数据库连接凭据。一旦模型受到提示注入，或者生成了危险操作，请求会直接到达数据库，缺少中间层拦截。对 Agent 开发来说，这意味着安全边界不能只放在数据库内部，也不能只靠事后日志，而要在请求进入数据库之前完成过滤、分级和阻断。
MCP 隔离层：把权限判断提前到数据库之外
金仓提到的路径，是在 AI 客户端与 KingbaseES 之间引入 MCP（Model Context Protocol）作为隔离层。这个设计的关键不是简单增加一个网关，而是改变权限裁决的位置。
- AI 客户端不再直接持有数据库用户名、密码或 Token，只传递查询意图。
- MCP Server 负责在请求转发前完成 SQL 校验和权限预判。
- 数据库仍然是最终权限裁决者，但请求在到达数据库前，已经先经过一轮 SQL 类型白名单校验和风险分级。
这种结构回应了 Agent 开发中的一个基本原则：AI 不应直接掌握数据库凭据。把凭据从模型侧移开，至少能降低一种风险——模型即使被诱导，也无法直接以完整数据库账号权限执行操作。对安全团队而言，这也让“是否允许执行”的判断点前移，增加了可拦截的空间。
行级语义审计：不只看执行了什么，还要看谁让 AI 查了哪些行
如果只记录“账号 + SQL + 时间”，传统审计在 AI 场景中会显得不够。一个 MCP Server 可能同时服务多个 Agent、多个用户和多种任务。单看账号，无法还原真正的业务来源，也无法解释某次查询为什么发生。
金仓提到的做法，是把行级访问控制和审计绑定。权限不只回答“能不能查这张表”，还要回答“能查哪些行”。审计不只记录 SQL 文本，还记录语义上下文，例如查询属于哪个业务场景、由哪个 Agent 发起、命中了哪些敏感数据标签。
这种细粒度对 AI 场景很重要。一个 Agent 可能在一次推理中发起几十条查询，每条单独看都符合规则，但连续组合后可能构成对敏感数据的批量提取。行级控制限制可见范围，语义审计记录访问动机和数据标签，二者结合后才能更接近“可追溯”的要求。
输出校验与未解问题：安全不是开关，而是一组持续机制
数据库访问被控制后，风险并没有完全消失。大模型可能基于合规查询结果生成误导性或越界结论。金仓 KES AI 数据库构建了全链路 LLM 输出校验机制，按照“生成-校验-分级-输出”的闭环处理模型结果，并对高风险内容在输出给用户前进行拦截或标注。
这一步针对的是另一种隐患：数据本身没有离开数据库，但模型基于数据给出了不应给出的判断。在金融风控、医疗诊断、政务决策等场景里，这类风险可能比单纯的数据泄露更难被察觉。
不过，这套机制也并非万能。MCP Server 自身需要最小权限配置、独立部署和访问控制，否则隔离层可能失效；AI 能查哪些数据、能执行哪些操作，仍需要业务侧定义，工程上可以从默认关闭 DDL、大批量 DML 等高危操作开始；审计日志本身也要保证完整和防篡改，否则追溯能力会失去基础。
对行业而言，这类方案提供的价值在于把 AI 数据库安全从口号拉回工程问题。数据不出库只是必要条件，真正可落地的边界需要覆盖凭据、请求、行级权限、语义审计和最终输出。Agent 要进入生产环境，安全设计也必须从单点防御转向全链路控制。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-agent-jie-ru-shu-ju-ku-hou-an-quan-bian-jie-yao-cong-shu
