Roteamento Seguro de Prompts: Evitando Vazamentos de Dados entre Clientes em Sistemas LLM

Você já parou para pensar no que acontece com os dados sensíveis da sua empresa quando você usa uma IA generativa compartilhada? A maioria das pessoas assume que o modelo "sabe" quem é você. Mas a realidade técnica é bem mais perigosa. Se a arquitetura do seu sistema não for projetada corretamente, um usuário do Cliente A pode acidentalmente ver informações do Cliente B. Isso não é ficção científica; é um risco real e crescente em sistemas de LLM (Large Language Models) multi-tenant.

O problema central não está apenas no prompt que o usuário digita. Ele está em como o sistema roteia essa solicitação através de bancos de vetores, caches e modelos de inferência. O conceito de Roteamento Seguro de Prompts (Secure Prompt Routing) refere-se à disciplina de garantir que cada requisição esteja vinculada a um escopo de autorização verificado antes de tocar qualquer dado. Não basta dizer ao modelo "não revele segredos". Você precisa de barreiras estruturais. Vamos explorar como isso funciona na prática e por que as soluções comuns falham.

A Ilusão da Segurança Baseada em Instruções

Muitos desenvolvedores cometem o erro clássico de tratar o prompt do sistema como uma camada de segurança. Eles escrevem: "Você é um assistente privado para a Empresa X. Nunca mencione dados da Empresa Y." Parece lógico, mas é frágil. Um ataque simples de injeção de prompt ou até mesmo uma pergunta mal formulada pode fazer o modelo alucinar ou misturar contextos recuperados incorretamente.

A OWASP (Open Worldwide Application Security Project), em suas diretrizes atualizadas de outubro de 2026, é clara: instruções em linguagem natural não são fronteiras de controle de acesso. O controle deve acontecer no código da aplicação e na infraestrutura de dados, antes que o conteúdo chegue ao modelo. Se você confia no LLM para filtrar o que é secreto, você já perdeu. A segurança precisa ser determinística, não probabilística.

Onde os Dados Vazam: Além do Prompt do Usuário

Pense no caminho que uma pergunta faz. Ela entra na API, passa pela autenticação, busca documentos relevantes em um banco de vetores (RAG), monta o contexto, envia para o modelo e retorna a resposta. Em cada um desses passos, há um ponto potencial de vazamento cross-tenant (entre clientes).

• Recuperação Vetorial: Se o filtro de tenant não for aplicado rigorosamente na consulta ao banco de vetores, fragmentos de outros clientes podem entrar no contexto.
• Caches de Resposta: Sistemas frequentemente armazenam respostas para economizar recursos. Se o cache não estiver isolado por tenant, o usuário A pode receber uma resposta pré-calculada baseada nos dados do usuário B.
• Metadados e Logs: Às vezes, o vazamento não está no texto final, mas nos metadados expostos ou nos logs de depuração que retêm conteúdo sensível indevidamente.
• Estado de Inferência Compartilhado: Este é o mais sutil. Pesquisas recentes, como o paper da NDSS 2025 "I Know What You Asked", mostram que mecanismos de otimização como o KV-cache compartilhado em servidores de inferência podem vazar informações através de canais laterais de tempo (timing side-channels). Mesmo que seus filtros estejam perfeitos, a infraestrutura subjacente pode estar falando demais.

Estratégias de Isolamento: Silo vs. Pool vs. Híbrido

Não existe uma solução única para todos. A escolha depende do seu nível de risco e orçamento operacional. Vamos comparar as três abordagens principais suportadas por bancos de vetores modernos como Pinecone, Weaviate, Qdrant e Milvus.

A abordagem "Pool" é tentadora pelo custo, mas exige disciplina extrema. Se um desenvolvedor esquecer de adicionar `WHERE tenant_id = 'X'` em uma nova funcionalidade de busca, você tem um vazamento imediato. A abordagem "Silo" é mais segura porque, se o código falhar, ele simplesmente não encontra os dados do outro cliente (falha fechada), mas torna-se um pesadelo de manutenção quando você tem milhares de clientes pequenos.

Implementando o Fail-Closed (Falha Fechada)

O princípio de ouro aqui é "Fail Closed". O que isso significa na prática? Significa que, se houver qualquer dúvida sobre a autorização, o sistema deve retornar zero resultados, não resultados parciais.

Imagine um cenário onde a verificação de permissão falha devido a um timeout no serviço de identidade. Um sistema inseguro pode tentar buscar tudo e filtrar depois. Um sistema seguro aborta a recuperação. A OWASP recomenda explicitamente que a verificação de acesso ocorra antes da seleção top-k dos vetores. Filtrar "recuperar tudo e depois limpar" é perigoso porque expõe pontuações de similaridade e pode permitir ataques de sondagem (query probing) para descobrir quais documentos existem, mesmo que não possam ser lidos.

Além disso, a autorização para ferramentas é distinta da autorização para leitura. Só porque um usuário pode ler um documento interno não significa que ele tem permissão para executar uma ação sugerida por esse documento (como enviar um e-mail ou deletar um registro). Ferramentas devem ter esquemas de saída validados e confirmações independentes.

O Desafio dos Caches e Memória Persistente

Caches são armadilhas comuns. Se você usa Redis ou Memcached para armazenar respostas de LLM, precisa garantir que a chave do cache inclua não apenas o hash da pergunta, mas também o ID do tenant e o nível de permissão do usuário. Uma resposta gerada para um gerente (que vê todos os dados) não pode ser servida a um analista júnior, mesmo que a pergunta seja idêntica.

A invalidação também é crítica. Se um documento muda de classificação ou é excluído, todos os chunks derivados, embeddings e respostas em cache associadas a esse documento devem ser purgados imediatamente. Sistemas que dependem de TTL (Time-To-Live) longos correm o risco de servir dados desatualizados ou revogados.

Verificação Adversarial e Testes Contínuos

Como você sabe que seu roteamento é seguro? Testes unitários padrão não bastam. Você precisa de testes adversariais repetíveis. A OWASP sugere incluir casos de teste que cubram especificamente cenários de fronteira:

1. Consultas Cross-Tenant: Tentar acessar dados de outro tenant usando IDs manipulados.
2. Permissões Obsoletas: Simular a remoção de acesso de um usuário enquanto ele mantém uma sessão ativa.
3. Injeção Indireta: Enviar documentos com prompts injetados que tentam ignorar as restrições de formato ou escopo.
4. Reuso de Conexão: Garantir que o próximo request em uma conexão HTTP reutilizada não herde o contexto de memória do anterior.

O critério de aceitação não deve ser "o modelo recusou educadamente", mas sim "o conteúdo não autorizado nunca entrou no contexto do modelo". Instrumente suas requisições com IDs de correlação para rastrear exatamente quais documentos foram recuperados e por qual decisão de autorização.

Governança e Normas Emergentes

Embora não exista um produto único chamado "Secure Prompt Routing", frameworks como o NIST AI Risk Management Framework (lançado em 2023) e o perfil específico para IA Generativa (NIST AI 600-1, julho de 2024) fornecem o vocabulário necessário. Eles enfatizam que a gestão de riscos de IA deve mapear controles de fronteira de tenant para requisitos de privacidade e governança de dados.

No Brasil, com a LGPD em vigor, a responsabilidade sobre esses vazamentos é clara. Se o seu provedor de LLM compartilha estado de inferência sem isolamento adequado, você pode estar violando obrigações contratuais e legais, mesmo que o modelo em si seja "seguro". A tendência futura aponta para uma maior granularidade: à medida que adicionamos agentes persistentes e memórias de longo prazo, a superfície de ataque cresce. O isolamento no plano de dados (retrieval) e no plano de inferência (servidor do modelo) são complementares, não substitutos.