企业AI数据安全边界：大模型理解但不接触数据的访问策略
最近研读了一篇关于企业AI数据安全落地的论文《Positive Data Control: A Secure Architecture for LLM-Mediated Data Governance》。它直指一个核心挑战：如何让大语言模型理解用户的自然语言查询，同时确保其完全无法触及任何敏感数据本身。
这篇论文的价值，在于它清晰地定义了一种LLM数据访问的安全架构范式。这对于企业内部的知识库问答、BI分析、Text-to-SQL乃至数据治理Agent的设计，提供了极具参考价值的工程蓝图。
企业数据问答的真正风险，不在“会不会生成SQL”
企业内部的数据访问需求持续增长。传统的治理手段，如基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）、数据库权限、审批流程和审计日志，已运行多年。但这里存在一个根本矛盾：业务用户不会用“表名、字段名、策略名”来提问，他们习惯用自然语言表达，例如：
“帮我查一下客户订单情况。”“分析一下某个部门员工薪资。”“导出所有客户信息。”
自然语言请求与数据库的结构化权限之间，存在巨大的语义鸿沟。大语言模型（LLM）擅长弥合这条鸿沟——它能将自然语言翻译成SQL，也能解释策略。然而，如果简单地让LLM直接连接数据库，一系列新风险便随之而来：提示注入、恶意SQL生成、越权查询、敏感字段泄露，以及查询结果被模型上下文吸收。论文明确指出，已有研究证实Text-to-SQL系统存在提示注入和恶意查询生成的风险，因此绝不能让LLM直接靠近敏感数据。
于是，作者提出了一个核心思路：LLM只负责理解请求并草拟SQL，而真正的权限判断、SQL校验、执行控制和结果脱敏，全部交由确定性的系统来完成。这套方法论，就是论文所称的“积极数据控制”（Positive Data Control, PDC）。
PDC的核心思想：把数据访问从“事后审计”改成“事前拦截”
论文用一个巧妙的类比来解释PDC：传统的数据访问，好比用户直接操纵飞机操纵杆，治理主要依赖用户自觉、权限配置和事后的飞行记录分析；而PDC则类似于现代飞机的“电传操纵”系统（fly-by-wire）——用户发出飞行意图，但中间有一个控制层负责解读、校验、限制并记录所有指令，之后才允许操作真正传递到舵面。
这一设计的关键转变在于：
- 用户不直接访问数据库。
- LLM也不直接访问数据库。
- 所有请求必须经过一个独立的控制层。
- 控制层在执行前就必须完成策略判断。
- 所有返回结果都要经过后处理和审计。
这对AI安全至关重要。当前许多企业在构建AI数据问答系统时，容易将“大模型能力”本身误当作权限系统的一部分。论文的观点恰恰相反：LLM可以参与语义理解，但它绝不能成为安全边界本身。
“零知识治理”：大模型只看结构，不看数据
论文中提出了一个容易引起误解的概念：“zero-knowledge governance”（零知识治理）。需要澄清的是，这里的“零知识”并非密码学中的零知识证明，不涉及复杂的数学验证。论文的解释很明确：它指的是一种架构上的隔离原则。即，大模型永远不能看到数据库里的真实数值、行数据、单元格内容，也不能看到查询的原始结果。它能接触的，仅限于元数据、字段说明、敏感标签、权限策略、用户角色以及声明的查询用途。
换句话说，模型可以知道数据库里有一张“员工表”，表里有一个“salary”字段，并且知道这个字段属于“HR受限”类别。但它绝不能看到任何一位员工的实际工资数额。同样，它可以了解“客户表”中包含email、phone、credit_score等字段，并知道哪些属于个人身份信息（PII）或金融敏感信息，但它绝不能接触具体的邮箱、手机号或信用分数。
划定这条边界至关重要。企业在引入大模型进行数据问答时，常犯的一个错误是把“让模型理解业务”等同于“把业务数据喂给模型”。事实上，大量的数据治理决策根本不需要真实数据值。判断一个用户能否访问“salary”字段，无需知道某人的工资是多少；判断一个请求是否越权，也无需把客户名单发给模型；决定一个查询是否应该进行聚合处理，同样不需要模型看到原始记录。
论文中的Table 3清晰地列出了信息隔离的范畴：模型可以看到表结构（schema）、字段类型、关联关系、字段描述、敏感标签、权限规则、用途约束和用户身份上下文；模型不能看到数据库真实值、查询结果、具体姓名、工资、社会安全号（SSN）、信用分、交易金额，也不能接触包含敏感信息的原始日志或数据库错误信息。
这为企业AI数据安全提供了一个极其直接的产品设计原则：让模型理解数据“结构”和治理“规则”，但坚决不让模型接触数据“内容”。
这套架构如何运转？
论文提出的PDC架构大致可以分为六个层次：
- 用户界面与身份绑定层：用户提交自然语言请求，同时必须附带认证身份、角色、部门及声明用途。这意味着请求在进入系统之初，就已明确了“谁在问、以什么身份问、为了什么目的问”。
- LLM控制层：LLM接收结构化的提示（prompt），其中包含表结构描述、字段敏感性标注、策略规则和用户权限上下文。基于这些信息，LLM生成一个候选SQL语句，并附上简短的理由。此处的输出被视为“不可信的草稿”。
- 确定性验证层：这是主要的安全执行边界。该层检查SQL是否为只读查询，是否包含DDL/DML等危险操作、SQL注入痕迹、危险关键字，是否访问了用户无权访问的表或字段，是否需要自动添加LIMIT限制，是否违反了聚合约束或用途约束等。
- 沙箱执行层：只有通过验证的SQL才会被送入执行环境。该环境具备资源限制、隔离和超时控制，旨在降低拒绝服务（DoS）攻击或超大查询带来的风险。
- 结果后处理层：即使SQL通过了验证，返回的结果仍需进行PII脱敏处理。例如，邮箱地址部分脱敏，手机号完全脱敏，SSN则始终完全脱敏。这相当于在输出侧设置了第二道保险。
- 审计层：系统完整记录请求链路，包括身份、角色、声明目的、原始自然语言请求、模型生成内容、验证结果、最终执行的查询及决策，以满足合规、追责和策略优化的需求。
整体来看，这是一种典型的“解释层”与“执行层”分离的架构。LLM在左侧负责理解意图，数据库和验证器在右侧负责安全执行，中间由一条明确的“零知识边界”隔开。
这个设计的关键在于职责分离：LLM负责理解，验证器负责授权，沙箱负责执行，后处理负责输出控制，审计负责事后追责。论文也明确强调，LLM控制层的角色是辅助生成，不承担强制执行的职责；验证层才是主要的确定性安全边界；后处理是输出侧的纵深防御；审计层则提供问责与监控能力。
这与当前许多企业正在构建的“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）的筛查，未来需要加强到SQL抽象语法树（AST）级别，并覆盖更多真实的用户查询和SQL方言。
LLM不是安全边界
这篇论文最值得关注的地方，或许不在于它构建了多么复杂的系统，而在于它重新摆正了LLM在企业数据治理中的位置。
LLM的优势在于语义理解。它能理解用户的自然语言请求，能将模糊的业务意图转化为结构化查询，能解释为何某些请求被拒绝，也能将不合规的请求改写成合规的替代方案。例如，用户想“查看所有客户”，系统可以不返回原始客户列表，而是提供聚合统计；用户想查“客户姓名和订单总额”，系统可以去掉姓名，只返回权限允许内的聚合结果。
但LLM的弱点同样明确。它容易受到提示注入的影响，可能生成错误SQL，可能误解权限策略，在复杂上下文中的表现也可能不稳定。因此，它不能承担最终的授权职责。真正能充当安全边界的，必须是可审计、可复现、可测试、可验证的确定性系统。
这对当前AI Agent的安全设计也有启发。Agent系统中的工具调用、数据访问、文件读写、工单创建、代码执行等，本质上都属于“高风险动作”。如果这些动作仅靠模型自身判断，就会形成隐性的权限扩张。PDC的思路可以迁移到Agent场景：模型可以提出动作建议，但在动作触及真实系统之前，必须经过策略验证、权限校验、沙箱执行、结果过滤和审计记录。
所以，这篇论文实际上给出了一个朴素而重要的判断：企业AI安全的重点，不是追求模型永远不犯错，而是确保模型即使犯错，也无法直接造成安全事故。
对AI安全产品设计的启发
将这篇论文的思路转化为产品设计，可以得到一套比较清晰的企业AI数据访问安全框架。
- 建设治理元数据层：这是基础。没有字段敏感标签、表关系说明、角色和用途策略，大模型就只能“盲猜”。PDC架构将元数据、策略和权限提升为一等治理对象，模型看到的是这些“治理工件”，而非原始数据。
- 部署独立的SQL验证器：仅靠提示词提醒模型“不要越权”是远远不够的。验证器必须在执行前检查只读约束、表字段权限、危险关键字、SQL注入、LIMIT限制、聚合限制、用途限制和跨域访问。在生产环境中，这一层最好能做到SQL AST级别，而非停留在关键词和正则匹配。
- 实施结果返回安全控制：即使查询本身合规，返回的结果也可能泄露敏感信息。PII脱敏、字段裁剪、最小化返回、小样本聚合保护、异常结果拦截，都应成为输出后处理的标准组成部分。论文也提到，未来可以进一步引入k-匿名化或差分隐私，以降低聚合结果带来的推断风险。
- 实现全链路审计：企业不能只记录“谁在何时查询了数据库”。必须记录用户原始请求、声明用途、模型生成的候选SQL、验证层的拒绝或修改原因、最终执行语句以及输出处理结果。只有这样，才能在出现争议、误用或攻击时，追溯完整的决策路径。
局限性
需要明确的是，这篇论文更像一个架构原型和设计范式的验证，不能直接等同于成熟的商业产品方案。
其实验数据库规模很小，仅包含四张表和少量记录；测试场景也是作者预设的固定集合，难以代表真实企业中千差万别的数据模型、权限策略和用户表达习惯。验证器目前也偏于保守，主要依赖基于模式的筛查，对于复杂SQL方言、嵌套查询、窗口函数、数据库特定函数以及编码绕过等情况，覆盖可能不足。论文也承认，后续需要更大规模的测试、更多场景的生成、多模型对比，以及基于AST的SQL验证。
另一个问题是，它主要处理的是“只读”数据访问。但企业AI助手的真实边界通常不止于查询。未来的AI助手可能会涉及写入数据、修改配置、触发审批、发起交易、创建工单，甚至调用外部系统API。到了这个阶段，PDC的思想依然有价值，但执行层需要加入更严格的事务控制、审批流程、回滚机制和动作级别的审计。
同时，元数据本身也并非完全无风险。表名、字段名、敏感标签、组织角色、业务规则，都可能泄露企业内部的结构信息。因此，即使大模型不接触真实数据，对元数据的访问也应遵循最小权限原则。
写在最后
这篇论文给出的答案非常清晰：企业可以让大模型“参与”数据治理，但绝不能把数据治理“交给”大模型。
大模型适合充当自然语言接口，适合弥合用户意图与结构化查询之间的鸿沟，也适合向用户解释请求被拒绝的原因。但权限判断、SQL校验、执行控制、结果脱敏和审计记录，这些职责必须由确定性的系统来承担。
从这个角度看，PDC不仅仅是一个Text-to-SQL的安全方案，更是一种通用的企业AI安全架构思想：让模型靠近“意图”，远离“数据”；让模型生成“建议”，让系统控制“执行”；让AI提升效率，但绝不将安全边界让渡给AI。
这很可能成为未来企业AI落地中，一条越来越重要的核心原则。
让大模型理解数据，但不接触数据。让大模型参与流程，但不掌握最终权限。
这才是企业AI数据访问真正应该建立的新边界。