导语：当 LLM 从“聊天工具”变成“能动手的系统组件”，数据库往往是最先被接入、也最容易被低估风险的一环。让 Agent 生成 SQL 并不难，难的是让它在生成之后依然可控。本文讨论 Agent 与数据库交互时的安全边界设计，重点落在 SQL 生成约束与权限控制两个层面。

一、问题从哪里开始

Agent 接入数据库的典型链路是：用户用自然语言提出需求，LLM 将其翻译为 SQL，执行后把结果回传给模型，再由模型组织成自然语言答复。这条链路里，风险并不集中在某一个点，而是分布在多个环节：

• 语义偏差：自然语言本身有歧义，模型可能生成“语法正确但语义错误”的查询，例如漏掉时间范围、误用聚合函数。
• 越权访问：模型不知道当前用户的数据边界，可能生成跨租户、跨部门的查询。
• 写操作失控：一旦允许 INSERT、UPDATE、DELETE 甚至 DDL，错误代价从“看到不该看的数据”升级为“改坏不该改的数据”。
• 注入与提示注入：用户输入或数据库中的内容都可能携带恶意指令，诱导模型生成非预期语句。

因此，安全设计的目标不是“让模型不犯错”，而是“让模型的错误无法造成不可逆后果”。

二、SQL 生成侧：把自由度收进笼子

1. 只读优先，写操作单独通道

最有效的第一道防线是权限层面的只读约束：Agent 默认只持有 SELECT 权限，写操作走独立通道，并附带人工确认或审批流程。这样即使模型生成错误语句，最坏结果也限于“读到不该读的数据”，而这类问题可以靠下一节的权限控制兜底。

2. 结构化生成，而非自由文本

让模型直接输出 SQL 字符串，等于把解析和校验的负担全部推给下游。更稳妥的做法是让模型输出结构化中间表示（例如表、字段、过滤条件、聚合方式），再由服务端模板渲染为 SQL。这样做的收益是：

• 可枚举的字段与操作，便于白名单校验；
• 过滤条件可以被程序化检查，而不是靠正则匹配；
• 渲染层可以统一处理参数化，天然规避拼接注入。

这一模式在工程上更易审计，但会增加一层 schema 描述与模板维护成本，需要权衡。

3. 强制参数化与语句校验

无论采用哪种生成方式，执行前都应经过统一校验层：语句类型白名单、涉及表与字段白名单、是否包含子查询或联合查询、是否带有 LIMIT 等。参数化查询应作为硬性要求，禁止任何形式的字符串拼接。

4. 限制执行代价

除了“能不能查”，还要管“查多狠”。为 Agent 发起的查询设置超时、最大返回行数、扫描行数上限，可以避免一次误生成的全表扫描拖垮数据库。这类限制属于工程约束，具体阈值需结合业务负载确定。

三、权限控制侧：让数据库自己说不

1. 最小权限的数据库账号

Agent 不应复用应用主账号或管理员账号。为 Agent 单独创建数据库账号，按库、表、列授予最小权限，是最基础也最容易被跳过的一步。列级权限在部分数据库系统中受支持，可用于屏蔽敏感字段。

2. 行级安全与租户隔离

多租户场景下，仅靠模型“记得加 WHERE tenant_id = ?”是不可靠的。更稳的做法是把租户条件下沉到数据库的行级安全策略，或由中间层在渲染 SQL 时强制注入，使模型无法绕过。

3. 身份透传，而非身份猜测

Agent 执行查询时使用的身份，应当来自已认证的调用方上下文，而不是模型从对话中推断出的“用户说自己是谁”。身份透传保证了权限判断的依据是可信的会话信息。

4. 审计与可回溯

每一次 Agent 发起的查询都应记录：原始自然语言请求、生成的 SQL、执行身份、耗时与返回行数。审计日志既是事后追责的依据，也是发现异常模式的素材。

四、一个可参考的分层结构

综合上述要点，可以把 Agent 与数据库之间的交互拆成四层：

1. 意图层：接收自然语言，产出结构化查询意图；
2. 生成层：将意图渲染为参数化 SQL，套用模板与白名单；
3. 校验层：检查语句类型、对象范围、代价上限；
4. 执行层：以最小权限账号执行，行级安全兜底，全程审计。

任何一层都可以独立拒绝请求，形成纵深防御。这种分层并不依赖特定模型或数据库产品，具备较好的通用性。

五、趋势判断

随着 Agent 从演示走向生产，数据库交互的安全重心正在从“提示词约束”转向“系统约束”。提示词可以被绕过，而权限、白名单、行级安全和审计是模型无法绕过的硬边界。可以预期，未来 Agent 框架会把数据库访问治理作为标准组件提供，而不是留给每个团队自行拼装。

结论

让 Agent 安全地使用数据库，核心不是让模型更聪明，而是让系统更克制：生成侧收窄自由度，权限侧守住底线，执行侧留下痕迹。三者结合，才能让“自然语言查数据”这件事从可用走向可信。

生成标记：本文由 ITPUB 文章生成平台基于已选素材整理生成。