SheepNav
新上线今天0 投票

多租户LLM分析系统的行级安全实践:PAR如何构建安全Agent

PAR Technology Corporation 为餐饮行业构建技术平台,服务超过300家餐饮企业。在开发自然语言文本到SQL的自主分析Agent时,核心挑战在于:如何在多租户环境下,确保每个用户通过LLM生成的SQL查询仅返回其授权数据,即使LLM本身被攻击或操纵。本文详细介绍了PAR通过三层架构实现的行级安全方案:

核心问题:数据边界

考虑两个用户同时提问“上周总销售额是多少?”:

  • 特许经营店主:仅管理芝加哥两家门店,正确答案为84,000美元。
  • 品牌经理:负责全国200家门店,正确答案为920万美元。

相同问题、相同数据库,但结果截然不同。若向店主展示全国数据,不仅是数据治理失败,更可能泄露其他运营商的商业敏感信息。

三层安全架构

PAR构建的解决方案包含三个独立的安全层,每层独立运作,降低跨租户数据泄露风险:

1. 加密请求签名(AWS SigV4)

所有用户请求必须通过AWS SigV4进行加密签名,确保请求身份的真实性和完整性,防止伪造或篡改。

2. 语义验证(Amazon Bedrock)

在LLM生成SQL之前,通过Amazon Bedrock对用户意图进行语义验证,确保查询范围与用户权限匹配。例如,特许经营主的查询会被自动限定在其门店ID范围内。

3. 程序化数据隔离(Split-Plane SQL)

通过Split-Plane SQL技术,在数据库层面实现行级数据隔离。每个SQL查询在生成时自动注入租户标识,确保仅返回该用户有权访问的数据行。

设计优势

  • 纵深防御:即使某一层被绕过,其他层仍能阻止数据泄露。
  • 零信任原则:不信任任何单一组件,包括LLM本身。
  • 性能平衡:三层验证仅增加微秒级延迟,不影响用户体验。

行业启示

随着LLM在企业分析中的普及,多租户安全成为关键挑战。PAR的方案展示了如何通过架构设计而非单纯依赖模型行为来保障数据安全,为金融、医疗等同样需要严格数据隔离的行业提供了可复用的参考模式。

延伸阅读

  1. 我为什么总是在电站上插着这三样设备——日常也能发挥大作用
  2. Tidal 将不再为 AI 生成音乐支付版税,但并未全面封禁
  3. 首次在苹果店更换iPhone电池,我学到了宝贵一课
查看原文