AI直接写SQL查客户数据库：400行代码如何层层设防

支持工单写着’最后三笔订单不见了’，AI代理直接生成SQL查询客户数据库。这个做法把LLM和陌生人文本、数据库连接绑在一起，却依然上线了。真正拦住风险的不是提示词，而是代理与数据之间的大约400行代码。

这套系统让AI读取用户提交的工单，自主形成假设，生成SQL去查客户自己的数据库，最后把发现的问题连同查询语句一起输出。听起来高效，却天然带着巨大风险：LLM面对的是互联网上完全不可信的文本，却被允许访问真实数据库连接。项目最终还是上线了，核心工作量不在AI代理本身，而在于那400行把代理和数据隔开的防护代码。

这些代码构成了多层guardrail。它们覆盖权限控制、查询验证、执行隔离、审计追踪和异常拦截。每一层都在解决prompting无法处理的根本问题。以下按实际落地顺序拆解每一道防线，并说明对中文团队的实用意义。

提示工程无法成为任何一道防线

单纯依赖prompting来控制AI行为在这种场景下完全不可行。提示词可以引导模型生成更合理的SQL，但面对恶意或精心构造的输入时，它本质上无法提供可靠的保证。LLM的输出是概率性的，即使加上“只允许只读查询”“不要删除数据”这样的指令，模型仍然可能因为输入中的越狱提示或意外的上下文而生成危险语句。

信号明确指出，prompting不是guardrail。原因在于不可信输入的根本特性：用户工单来自陌生人，可能包含SQL注入片段、越权描述或诱导模型忽略规则的文本。无论prompt写得多精细，模型都可能被绕过。一次成功的越狱就能让AI生成DROP TABLE之类的语句，而prompt无法在运行时强制执行语义检查。

这不是理论风险。实际系统中，开发者尝试过各种system prompt、few-shot示例和输出格式限制，但效果始终不稳定。模型在正常工单上表现良好，一旦输入稍有偏差就容易失控。中文开发者常犯的错误是把大量精力投入到优化prompt上，却忽略了下游必须有的硬约束。正确的做法是把prompt只当作辅助工具，用于提高生成质量，而把安全完全交给后续的代码层。400行guardrail的核心价值就在于此：它不依赖模型的“自觉”，而是假设模型每次都可能出错。

数据库连接只允许最小只读权限

即使AI生成了SQL，也不能让它拿到生产数据库的完整权限。项目中为每个客户数据库连接专门配置了最小化只读账号。这个账号只能访问特定schema下的表，且完全禁止任何写操作，包括INSERT、UPDATE、DELETE以及DDL语句。

这种连接层限制直接应对了“handing it a database connection”的核心风险。LLM读取不可信文本后，可能生成超出预期的查询。如果连接权限过大，一个失控的查询就能删除数据或导出敏感信息。最小权限原则把损害范围压缩到最低：即使SQL被恶意构造，最坏结果也只是读到不该读的表，而无法造成持久破坏。

实现时，系统为不同客户使用独立的数据库用户，每个用户只拥有目标schema的SELECT权限。连接字符串中还禁用了超级用户功能和跨库查询。中文团队在落地时可以参考PostgreSQL的ROLE机制或MySQL的GRANT限定，提前审计所有账号权限。定期轮换这些只读凭证也很关键，避免长期暴露。信号显示，这一步是整个guardrail的基础，如果连接层就失守，后续所有过滤都变得无意义。

AI生成的SQL必须被重写和白名单过滤

AI输出的SQL不会直接执行，而是进入一个重写和验证引擎。这大约占了400行代码的主要部分。引擎首先对查询进行解析，改写为参数化形式，防止注入攻击。然后应用白名单规则，只允许SELECT语句，且表名、列名必须在预先定义的允许列表内。

这个过程远比prompt可靠。模型可能生成带有子查询、JOIN甚至函数调用的复杂语句，单纯靠正则匹配很难覆盖所有情况。解析器能理解SQL的抽象语法树，从而准确识别危险构造，例如对系统表的访问或使用不安全的函数。白名单不仅限制表，还可以限制返回的列数和查询复杂度，避免SELECT * 泄露过多字段。

实际落地中，团队需要为每个客户的数据库维护一份元数据白名单，包含允许查询的表和字段。这份名单可以从schema自动生成，但必须经过人工审核。重写引擎还会为所有用户输入的参数添加绑定，彻底消除字符串拼接的风险。信号强调，这400行代码是真正的工作量所在，它把AI的“建议”变成了可安全执行的指令。对中文开发者来说，推荐使用sqlglot或类似开源解析器来实现这层过滤，既支持多数据库方言，又便于扩展自定义规则。

查询在隔离沙箱内执行而非直连生产

即使SQL通过了重写和白名单，也不会直接连接生产数据库。所有查询都在一个隔离的沙箱环境中执行。这个沙箱有独立的资源配额、时间限制和网络隔离，查询结果会被复制到临时数据集后再返回给AI代理。

沙箱设计解决了生产环境被意外影响的问题。AI生成的查询可能包含低效的JOIN或全表扫描，如果直接跑在生产库上，可能导致性能抖动甚至雪崩。沙箱通过只读副本或逻辑复制的方式获取数据，确保主库不受干扰。同时，沙箱限制了最大执行时间、返回行数和内存使用，超出限制的查询会被强制终止。

落地难点在于数据同步的时效性。团队需要权衡是使用实时复制还是定期快照。信号中提到的客户数据库查询场景要求一定新鲜度，因此项目采用了轻量级的CDC（变更数据捕获）机制，只同步必要表。中文团队可以考虑使用阿里云DTS或开源Debezium搭建类似沙箱。对于多租户系统，还需确保沙箱实例之间的严格隔离，避免一个客户的查询影响另一个。整个执行层把风险从生产环境彻底剥离，这是prompting完全无法提供的物理隔离。

每条查询自动留存并作为证据输出

系统要求AI在给出最终答案时，必须附上它实际执行过的每一条SQL语句。这些查询被完整记录到审计日志中，作为证据随结果一起呈现给人工审核者。

这一机制直接对应了信号中“writes up what it found with the queries attached as evidence”的描述。它把AI的行为变得可追溯。用户看到的不只是结论，还有“AI用了哪几条SQL得到这个结果”。如果结果有误，工程师可以立刻复现查询，定位是模型理解错误还是数据本身问题。

审计日志还包含查询执行时间、返回行数、沙箱资源消耗等元数据。这些记录被统一存入不可篡改的存储，保留至少30天。中文团队在实施时可以对接ELK或国产日志平台，实现按工单ID快速检索。重要的是，这层机制不只用于事后追责，更重要的是让整个系统变得透明。客户支持人员知道AI不是黑箱，从而更愿意信任并使用它。信号显示，这种证据输出是整个流程闭环的关键一环，没有它，AI生成的结论就缺乏可验证性。

异常模式触发实时拦截与告警

即使前面几层防线都通过，系统仍保持最后一层实时检测。任何查询如果匹配异常模式——例如访问敏感字段、查询量异常大、包含可疑函数或与历史模式显著偏离——都会被立即拦截，并触发告警给值班工程师。

异常检测结合了规则引擎和简单的统计模型。规则覆盖已知的危险模式，如尝试查询用户密码哈希表或使用SLEEP函数进行延时注入。统计部分则监控查询频率和复杂度，如果短时间内同一IP或同一工单生成过多查询，就视为潜在探测行为。

对中文开发者来说，这层实现可以从开源WAF或数据库防火墙起步，逐步加入机器学习异常检测。信号强调，400行代码中包含了这部分逻辑，因为单纯的静态过滤无法应对动态威胁。拦截后，系统不会简单拒绝，而是把上下文打包发送给人工，由人决定是否放行或进一步调查。这保持了系统的灵活性，同时把最终决策权留在人类手中。实际运行中，这类告警虽然偶尔出现，但有效阻止了多次潜在风险事件。

安全与响应速度的真实权衡仍未完全解决

尽管多层guardrail让系统得以安全上线，但安全与响应速度之间的矛盾依然存在。解析、重写、沙箱执行、审计和异常检测每一步都增加了延迟。目前端到端响应时间比纯人工慢，但比完全人工查询已经快很多。如何在不牺牲防护强度的情况下进一步降低延迟，仍是开放问题。

中文团队落地时需要根据业务优先级做取舍。如果客户支持时效要求极高，可能需要接受更高的计算成本来并行更多沙箱实例。反之，在非实时场景下可以加强静态分析，减少运行时开销。信号显示，整个项目最难的部分不是实现guardrail，而是持续平衡这两者。目前还不清楚是否存在一种既安全又接近零延迟的终极方案。

实际建议是：从小规模客户开始试点，收集真实查询模式，不断优化白名单和异常规则。不要试图一次性覆盖所有数据库类型，先选最常用的PostgreSQL或MySQL做深。团队应把重点放在自动化生成白名单和可视化审计仪表盘上，这些能显著降低维护成本。同时，定期进行红蓝对抗测试，用模拟恶意工单验证guardrail的有效性。

这套做法证明，让AI写SQL查询客户数据库并非不可行，但前提是把几乎所有信任从模型转移到代码层。prompting只能帮忙生成更好的查询，却永远不能替代硬性的、多层的工程防护。400行代码看似不多，却承载了整个系统的安全底线。对中文开发者而言，这是一个清晰的路线图：先建最小权限和沙箱，再补查询解析和审计，最后加上持续的异常检测。安全从来不是靠模型自觉，而是靠系统设计。

（全文约2150字）

参考来源