让大模型理解数据，但不接触数据：企业 AI 数据访问的新安全边界

最近看到一篇很适合企业 AI 安全落地的论文，题目叫**《Positive Data Control: A Secure Architecture for LLM-Mediated Data Governance》**。

https://assets-eu.researchsquare.com/files/rs-9317019/v1_covered_733b827c-2007-4c90-bed0-d8e2e8cd7429.pdf?c=1778254081

这篇论文讨论的是：当用户用自然语言向数据库提问时，能不能让大模型参与理解需求，但又不让大模型直接接触敏感数据？

我的判断是：这篇文章的价值不在算法创新，而在于提出了一个很清晰的LLM 数据访问安全架构范式。它对企业内部知识库、BI 问答、Text-to-SQL、数据治理 Agent 都有参考意义。

企业数据问答的真正风险，不在“会不会生成 SQL”

PDC 的核心思想：把数据访问从“事后审计”改成“事前拦截”

• 用户不直接访问数据库。

• LLM 不直接访问数据库。

• 所有请求必须经过控制层。

• 控制层在执行之前完成策略判断。

• 所有结果要经过后处理和审计。

“零知识治理”：大模型只看结构，不看数据

论文中有一个很容易被误解的词：zero-knowledge governance，零知识治理。

这里的“零知识”不是密码学意义上的零知识证明，不是说系统提供了严格的数学证明。论文自己的解释很明确：它说的是一种架构隔离。**大模型永远不能看到数据库里的真实值，不能看到行数据、单元格内容，也不能看到查询结果。**它只能看到元数据、字段说明、敏感标签、权限策略、用户角色和声明用途。

换句话说，大模型可以知道数据库里有一张员工表，可以知道里面有 salary 字段，也可以知道 salary 是 HR 限制字段。但它不能看到任何员工的真实工资。它可以知道客户表里有 email、phone、credit_score，也可以知道哪些字段属于 PII 或金融敏感信息，但它不能看到具体邮箱、手机号和信用分。

这套边界非常重要。企业引入大模型做数据问答时，常见的错误是把“让模型理解业务”误解成“把业务数据喂给模型”。实际上，很多治理决策并不需要真实数据值。判断一个用户能不能访问 salary 字段，不需要看某个人工资是多少；判断一个请求是否越权，不需要把客户名单发给模型；判断一个查询是否应该被聚合化，也不需要让模型看到原始记录。

论文用 Table 3 明确列出了大模型可以看到和不能看到的信息。大模型可以看到 schema、字段类型、join 关系、字段描述、敏感标签、权限规则、用途约束和用户身份上下文；大模型不能看到数据库真实值、查询结果、姓名、工资、SSN、信用分、交易金额，也不能看到包含敏感载荷的原始日志和数据库错误信息。

这给企业 AI 数据安全提供了一个很直接的产品原则：让模型理解数据结构和治理规则，但不要让模型接触数据内容。

这套架构怎么跑起来？

论文给出的 PDC 架构大致可以拆成六层：

这个设计的关键是职责分离。LLM 负责理解，验证器负责授权，沙箱负责执行，后处理负责输出控制，审计负责追责。论文也明确说，LLM Control Layer 的角色是辅助生成，不承担 enforcement；Validation Layer 才是主要的确定性执行边界；Post-processing 是输出侧的纵深防御；Audit Layer 提供问责和监控。

这和很多企业正在做的“AI 数据分析助手”有明显差别。很多系统的链路是用户提问、大模型生成 SQL、数据库执行、结果返回。PDC 要求在大模型和数据库之间增加强制验证层，并且执行结果不能再进入模型上下文。这个看似保守，但对于企业数据治理来说，恰恰是必要的。

论文实验：24 个端到端场景，38 个攻击场景

作者实现了一个原型系统，技术栈包括 Amazon Bedrock、Claude 3、Python 3.11、Streamlit 和 SQLite 内存数据库。原型数据库设计了 customers、orders、employees、transactions 四张表，用来模拟客户信息、订单信息、员工 HR 信息和金融交易信息。字段里包含 PII、财务敏感信息、HR 受限字段、用途受限字段等治理约束。

评测分成两部分。

第一部分是 24 个端到端治理场景，覆盖允许访问、角色违规、请求转换、跨域访问、用途限制、自然语言中嵌入攻击内容、模糊请求等类别。结果显示，在这 24 个场景中，有 9 个被直接允许，12 个被拒绝或阻断，3 个被修改或要求澄清。论文强调，在这个固定测试集内，没有观察到违反策略的请求被执行，也没有观察到允许场景被错误拒绝。

第二部分是 38 个定向攻击场景，包括 SQL 注入变体、DDL/DML 危险操作、权限提升、跨域访问、用途绕过等。论文报告这些攻击场景全部被阻断，成功阻断率为 100%。不过这个数字要谨慎理解，它说明原型在作者设计的攻击集上有效，但不能直接等同于工业级安全证明。论文自己也承认，当前验证层主要是保守的 pattern-based screening，未来需要加强到 SQL AST 级别，并覆盖更多真实用户查询和更多 SQL 方言。

LLM 不是安全边界

我认为这篇论文最值得关注的地方，不在于它做出了多复杂的系统，而在于它把 LLM 在企业数据治理里的位置摆正了。

LLM 的优势是语义理解。它可以理解用户自然语言请求，可以把模糊的业务意图转成结构化查询，可以解释为什么某些请求被拒绝，也可以把不合规请求改写成合规替代方案。比如，用户想“查看所有客户”，系统可以不给原始客户列表，而是返回聚合统计；用户想查“客户姓名和订单总额”，系统可以去掉姓名，只返回按权限允许的聚合结果。

但 LLM 的弱点也很明确。它容易被提示注入影响，可能生成错误 SQL，可能误解权限策略，也可能在复杂上下文中表现不稳定。因此，它不能承担最终授权职责。真正能承担安全边界的，必须是可以审计、可复现、可测试、可验证的确定性系统。

这对当前 Agent 安全也有启发。Agent 系统里的工具调用、数据访问、文件读写、工单创建、代码执行，本质上都属于“高风险动作”。如果这些动作只靠模型自己判断，就会形成隐性权限扩张。PDC 的思路可以迁移到 Agent 场景：模型可以提出动作建议，但动作进入真实系统之前，必须经过策略验证、权限校验、沙箱执行、结果过滤和审计记录。

所以，这篇论文其实给出了一个很朴素但很重要的判断：企业 AI 安全的重点，不是让模型永远不犯错，而是让模型犯错时不能直接造成事故。

对 AI 安全产品的启发

如果把这篇论文转成产品设计，可以得到一套比较清晰的企业 AI 数据访问安全框架。

**第一，企业需要建设治理元数据层。**没有字段敏感标签，没有表关系说明，没有角色和用途策略，大模型就只能靠猜。PDC 架构把元数据、策略和权限提升为一等治理对象，模型看到的是这些治理工件，而不是原始数据。

**第二，AI 数据问答必须有独立 SQL 验证器。**只靠 prompt 提醒模型“不要越权”是不够的。验证器应该在执行前检查只读约束、表字段权限、危险关键字、SQL 注入、LIMIT、聚合限制、用途限制和跨域访问。生产环境里，这一层最好做到 SQL AST 级别，而不是停留在关键词和正则。

**第三，结果返回也要做安全控制。**即使查询本身合规，结果也可能泄露敏感信息。PII 脱敏、字段裁剪、最小化返回、小样本聚合保护、异常结果拦截，都应该成为输出后处理的一部分。论文也提到，未来可以进一步引入 k-anonymity 或差分隐私，用来降低聚合结果带来的推断风险。

**第四，审计要覆盖完整链路。**企业不能只记录“谁查了数据库”，还要记录用户原始请求、声明用途、模型生成的候选 SQL、验证层的拒绝或修改原因、最终执行语句和输出处理结果。这样才能在出现争议、误用或攻击时追溯完整路径。

局限性

这篇论文更像一个架构原型和设计范式验证，不能直接理解为成熟产品方案。

它的实验数据库规模很小，只有四张表和少量记录；测试场景也是作者预设的固定集合，不能代表真实企业中千差万别的数据模型、权限策略和用户表达方式。验证器目前也偏保守，主要依赖 pattern-based screening，对复杂 SQL 方言、嵌套查询、窗口函数、数据库特定函数、编码绕过等情况覆盖不足。论文也承认，后续需要更大规模测试、更多场景生成、多模型对比，以及基于 AST 的 SQL 验证。

还有一个问题是，它主要处理只读数据访问。但企业 Agent 的真实边界通常不止于查询。未来的 AI 助手可能会写数据、修改配置、触发审批、发起交易、创建工单，甚至调用外部系统 API。到了这个阶段，PDC 的思想仍然有价值，但执行层需要加入更严格的事务控制、审批流、回滚机制和动作级审计。

同时，元数据本身也不是完全无风险。表名、字段名、敏感标签、组织角色、业务规则，都可能泄露企业内部结构。所以即使大模型不接触真实数据，元数据访问也应该遵循最小权限原则。

写在最后

这篇论文给出的答案很清楚：企业可以让大模型参与数据治理，但不能把数据治理交给大模型。

大模型适合做自然语言接口，适合补齐用户意图和结构化查询之间的鸿沟，也适合给用户解释为什么某些请求被拒绝。但权限判断、SQL 校验、执行控制、结果脱敏和审计记录，必须由确定性系统承担。

从这个角度看，PDC 不是一个单纯的 Text-to-SQL 安全方案，而是一种更通用的企业 AI 安全架构思想：让模型靠近意图，远离数据；让模型生成建议，让系统控制执行；让 AI 提升效率，但不把安全边界让渡给 AI。

这可能会成为企业 AI 落地中越来越重要的一条原则。

让大模型理解数据，但不接触数据。让大模型参与流程，但不掌握最终权限。

这才是企业 AI 数据访问真正应该建立的新边界。