PAR Technology 在 AWS 上构建多租户安全的 LLM 分析系统

为餐厅行业提供软件服务的 PAR Technology Corp. 在 AWS 官博上分享了其在 Amazon Bedrock 上构建多租户 LLM 分析系统的工程实践。该系统面向数百家餐饮品牌和数千名业务用户，要求自然语言提问被准确转换为 SQL，同时必须在架构层面强制行级安全（Row-Level Security），避免跨租户数据泄露。

业务背景与核心挑战

PAR 服务的客户从独立门店到覆盖数百门店的大型连锁集团不等，公司希望让非技术背景的业务人员用英语直接提问，并在数秒内拿到基于自有数据的结果。难点在于，同一个问题在不同租户语境下对应完全不同的数据切片。官方给出的例子是：同一天早上，两个用户都问「上周总销售额是多少」，一家经营芝加哥两家门店的加盟商应得到 8.4 万美元，而管理全国 200 家门店的品牌经理应得到 920 万美元——两个答案对各自的用户都是正确的。

这意味着系统每天处理数千次查询时，必须为每位用户返回「属于他的那个数字」，而不是全局数字或其他租户的数字。

不能把安全边界交给 LLM

PAR 团队最初的思路和许多 LLM 应用团队一样：在 prompt 中加入用户业务 ID，让模型自行套用过滤条件。但他们很快意识到问题——大语言模型本质上是概率生成器而非确定性策略引擎，即便一万次都正确应用了过滤器，第一万零一次也可能遗漏、幻觉出错误的过滤值，或在歧义问题上扩大查询范围。

在多租户分析场景中，这种非确定性无法作为安全边界，更无法支撑合规要求。LLM 在系统中只应充当「推理引擎」，而非「策略执行者」，数据隔离必须在架构层确定性完成。

三层架构概览

为满足 Zero Trust 要求，PAR 设计了一个三层叠加的安全架构，让每一层独立工作，即便 LLM 本身被攻破或被诱导，也能阻止跨租户数据外泄：

• AWS SigV4 加密请求签名：在请求进入系统时完成身份与租户上下文的加密绑定。
• Amazon Bedrock 上的语义校验：对模型生成的 SQL 做意图与作用域校验，识别可疑的范围扩张。
• Split-Plane SQL 程序化数据隔离：在数据库执行层把租户过滤条件以确定性方式注入查询，确保最终 SQL 只能访问授权数据切片。

三层职责清晰分离：身份认证由签名层负责，意图安全由语义层负责，数据边界由 SQL 层负责，任何单层被绕过都不会单独导致数据泄露。

从 V1 到生产

PAR 透露，V1 版本在概念验证阶段效果不错：用户输入自然语言问题，系统调用 Amazon Bedrock 上的 Anthropic Claude Sonnet 4（模型 ID anthropic.claude-sonnet-4-20250514-v1:0）生成 SQL，查询 Databricks 数据仓库后返回自然语言答案。但当准备进入生产、面对真实客户数据时，团队意识到仅靠 LLM 解读意图和生成 SQL 的架构「分析上有前景，架构上脆弱」。一旦用户故意构造越权 prompt、会话被劫持、或模型漏掉过滤条件，整个数据边界就会失守。

为此团队回到架构本身，将安全控制从 prompt 层下沉到独立的系统组件，让数据访问边界不再依赖模型行为，而是由可验证、可审计的程序化机制保障。文章披露了 V1 的局限以及驱动 V2 重构的核心问题，但完整的生产架构细节在官方原文后续章节中展开。

这套实践对正在搭建多租户 LLM 应用、尤其是需要把自然语言查询落到生产数据库的团队具有直接参考价值：它把「让模型做对」转化为「让系统架构强制做对」，明确划定了 LLM 在安全体系中的合理位置。