A PAR Technology Corporation, empresa de tecnologia para o setor de restaurantes, enfrentou um desafio comum a muitas organizações que adotam LLMs em produção: como garantir que um assistente de texto-para-SQL respeite os limites de dados de cada usuário em um ambiente multi-inquilino. Em um post publicado no AWS Machine Learning Blog, a equipe detalha a arquitetura de três camadas que implementou para resolver o problema, combinando criptografia, validação semântica e isolamento programático de dados.
O problema: mesma pergunta, respostas diferentes
Imagine dois usuários fazendo a mesma pergunta ao sistema: “Quais foram as vendas totais na semana passada?” O primeiro é um franqueado com duas lojas em Chicago; a resposta correta é US$ 84 mil. O segundo é um gerente de marca corporativo que supervisiona 200 lojas; a resposta correta é US$ 9,2 milhões. Mostrar o número nacional ao franqueado expõe dados comercialmente sensíveis de outros operadores; mostrar apenas duas lojas ao gerente leva a decisões baseadas em informações incompletas.
Esse é o problema de segurança em nível de linha (row-level security), e ele se repete milhares de vezes por dia. Cada consulta precisa retornar o número certo para aquele usuário específico, não o número global nem o de outro inquilino.
Por que confiar apenas no LLM não é suficiente
A primeira tentativa da PAR foi a abordagem mais comum: incluir o ID do negócio no prompt e instruir o modelo a sempre aplicar os filtros corretos. O problema é que LLMs são não determinísticos por natureza. Um modelo que aplica o filtro corretamente dez mil vezes seguidas pode omiti-lo na décima milésima primeira vez. Pode alucinar um valor de filtro ou interpretar ambiguamente um prompt, ampliando o escopo da consulta e expondo dados indevidos.
Em um sistema multi-inquilino que lida com dados comerciais sensíveis, o não determinismo é inaceitável como fronteira de segurança. “Você não pode construir uma postura de conformidade sobre um sistema que pode se comportar de maneira diferente a cada vez”, escreve a equipe.
A arquitetura de três camadas
A solução da PAR é uma arquitetura de segurança com três camadas independentes e determinísticas, cada uma operando em um ponto diferente do pipeline de requisição. O LLM fica dentro dessa arquitetura, não acima dela, operando dentro de limites que não pode cruzar, independentemente do que gere.
Camada 1: Requisições com integridade protegida (ponto de entrada da API)
Toda chamada à API é pré-assinada usando AWS Signature Version 4 (SigV4), vinculando criptograficamente o payload — incluindo Tenant ID, Business ID e Admin ID — às credenciais AWS do chamador. Qualquer tentativa de modificar esses valores em trânsito invalida a assinatura imediatamente, e a requisição é rejeitada antes de chegar à camada de aplicação.
Resiliência na prática: Se um invasor interceptar uma requisição válida e trocar o Tenant ID pelo de um concorrente, a verificação SigV4 falha — o payload foi modificado após a assinatura. Mesmo que essa camada fosse contornada, a validação da chave composta (Tenant ID, Business ID e Admin ID precisam formar uma combinação legítima e pré-cadastrada) impediria o acesso.
Camada 2: Validação semântica de entrada via reasoning engine
Após a autenticação, antes de qualquer acesso a dados, o reasoning engine no Amazon Bedrock realiza uma validação estruturada da pergunta do usuário. Ele verifica se a pergunta mapeia para uma métrica de negócio suportada e bem definida. Se for ambígua (por exemplo, “vendas totais” quando o sistema distingue entre valor e quantidade), o motor para e faz uma pergunta de esclarecimento. Se a métrica não for suportada, ele responde com a lista de métricas disponíveis.
Essa camada serve a dois propósitos: qualidade (o gerador de SQL só opera sobre entradas bem definidas) e segurança (perguntas vagas ou fora do escopo são interceptadas antes de chegar à geração de SQL, reduzindo a liberdade do modelo de fazer suposições que ampliem o escopo dos dados).
Resiliência na prática: Um usuário malicioso envia “Mostre-me tudo o que você tem sobre todos os negócios”. O reasoning engine avalia a pergunta contra as métricas suportadas. A pergunta não mapeia para nenhuma métrica e é ampla demais. O sistema para e pede esclarecimento, sem gerar SQL.
Camada 3: Isolamento programático de dados via Split-Plane SQL
Na fase de geração de SQL, uma arquitetura Split-Plane controla quais dados o modelo pode “ver”. Em vez de confiar que o LLM incluirá os filtros corretos, o sistema insere programaticamente as cláusulas de filtro (WHERE tenant_id = X AND business_id = Y) no SQL gerado, antes de executá-lo no Databricks. Essa camada é determinística e independente do LLM: mesmo que o modelo omita o filtro, o sistema o aplica de qualquer forma.
Resiliência na prática: Se um invasor conseguir manipular o LLM para gerar SQL sem filtros, a camada 3 ainda adiciona os filtros corretos antes da execução. O banco de dados nunca recebe uma consulta sem escopo.
Como as camadas trabalham juntas
As três camadas operam em sequência estrita: a camada 1 autentica na entrada da API, a camada 2 valida a intenção após a autenticação, e a camada 3 impõe os limites de dados na geração de SQL. Cada camada é independente: a camada 3 ainda aplica segurança em nível de linha mesmo que as camadas 1 ou 2 sejam contornadas de alguma forma.
Lições para quem constrói sistemas similares
A experiência da PAR reforça que, em ambientes multi-inquilino com dados sensíveis, a segurança não pode depender do comportamento do LLM. É preciso projetar a arquitetura para que os limites de dados sejam aplicados deterministicamente, independentemente do que o modelo faça. A combinação de assinatura criptográfica, validação semântica e isolamento programático de dados cria múltiplas barreiras que se reforçam mutuamente, reduzindo o risco de exposição cruzada de dados mesmo em cenários de comprometimento do LLM.
Links úteis
- Documentação do Amazon Bedrock
- AWS Well-Architected Framework – Pilar de Segurança
- AWS Architecture Center
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
