NL2SQL 生成 SQL 时怎样处理角色权限？

核心回答

角色权限要由业务后端和数据库执行层决定，不能交给模型自行遵守。生成前只提供可见元数据，生成后独立校验 SQL，执行时继续用最小权限和数据范围策略约束。 提示词中的“禁止越权”只能帮助模型生成合适语句，不能作为授权检查。

用户身份、租户和角色来自可信登录态。模型返回的 user_id、tenant_id 或“用户已授权”等文本，不能改变这次查询的权限。

三层分别限制什么

生成前限制可见知识。 后端把当前身份映射为允许的数据源、表、列和业务范围，再过滤可检索的表结构、示例及字段值。禁止访问的字段即使最终没有查，也不应先被送入模型上下文。业务口径和权限规则分开维护，不能让同义词配置顺带扩大权限。

生成后检查整个语句。 按对应数据库方言解析语法树，解析真实表、列及别名关系，覆盖子查询、公共表表达式、集合操作等结构；拒绝无法可靠解析或无法确定权限的查询。不能仅检查开头是 SELECT，还要限制多语句、写入、文件导出、锁定查询、危险函数和系统对象等行为。具体允许集合应由执行网关配置。

数据库继续强制执行。 使用不具备写入、管理或额外文件权限的账号，只开放所需对象。行级范围可以通过经过验证的查询代理、受控视图或数据库原生策略落实；不能声称加上只读账号就实现了租户隔离。若通过语法树注入范围条件，需验证别名、连接和嵌套查询下的语义，并防止绕过代理直连。

PostgreSQL 可采用行级安全策略，但要注意表所有者、超级用户及具有绕过权限的角色可能不受普通策略限制。不能把这一能力直接套称为 MySQL 的同名原生功能。

从提问到执行的权限链

图中模型只负责生成候选语句，独立网关和数据库继续执行权限约束：

flowchart TD
    A["后端认证身份与有效权限"] --> B["过滤可见结构、术语和示例"]
    B --> C["模型生成候选 SQL"]
    C --> D["独立网关：解析、鉴权与成本检查"]
    D -->|通过| E["最小权限数据库连接：强制数据范围与超时"]
    D -->|不通过| F["拒绝执行并返回受控原因"]
    E --> G["按相同权限范围返回与缓存结果"]

校正后的候选语句也回到网关检查。生成时隐藏字段能减少无关信息暴露，执行时的强制约束负责防止越权，两者不能互相替代。

查询后的边界也要守住

查询结果、下载接口、缓存和日志要沿用相同的数据范围。缓存键应包含租户、有效权限范围及相关版本，权限变化时使受影响缓存失效，避免通过共享缓存拿到其他用户结果。

权限用后端策略和拒绝用例验证：跨租户聚合、未授权列出现在过滤或排序中、通过子查询读取敏感表、撤权后命中旧缓存，都应被拦截。单纯让模型回答“我无权访问”不能证明系统已阻断访问。

对应教程

参考资料