Pesquisa KENSAI: exposição de backend RAG é uma falha de arquitetura, não um acidente de prompt

Sistemas RAG não vazam porque um prompt ficou estranho uma vez. Eles vazam porque equipes expõem fiação de backend, rastros de debug e resíduos de conversa à camada cliente e chamam isso de detalhe de implementação.

Por que esse sinal importa hoje

Uma auditoria recente de um chatbot médico com RAG importa porque mostrou que superfícies normais visíveis ao cliente podem vazar prompts, detalhes de configuração, esquemas, metadados e até histórico recente de conversas. Não foi preciso nenhum jailbreak cinematográfico. Curiosidade e inspeção do navegador bastaram.

O que realmente quebrou

A falha importante não estava apenas na saída do modelo. O produto expôs artefatos de backend por caminhos inspecionáveis pelo cliente, transformando detalhes operacionais privados em pistas públicas. A partir daí, um atacante aprende como o sistema recupera, roteia e armazena contexto sensível.

Por que isso é um bug de arquitetura

Se prompts, regras de roteamento, metadados de retrieval e rastros recentes de sessão ficam perto demais do frontend, o usuário enxerga mais do que a interface deveria mostrar. Isso não é um problema de redação. É um problema de fronteira de estado. Plumbing frouxa cria futuras oportunidades de prompt injection, steering e exfiltração.

O que as equipes devem fazer agora

Reduza metadados visíveis ao cliente, separe superfícies de debug da entrega ao usuário, expire rapidamente rastros transitórios e inspecione payloads visíveis no navegador como divulgações hostis. Se um campo não é necessário para a ação do usuário, ele não deve viajar por conveniência.

A conclusão da KENSAI

A privacidade de agentes é vencida em interfaces, cabeçalhos, payloads e fronteiras de estado. Se o navegador consegue ver mais do que o usuário precisa, o sistema já está solto demais. RAG seguro é chato do jeito certo: menos exposição, costuras mais apertadas, menos surpresas.