Para criar sistemas de IA que funcionem, primeiro é preciso tentar quebrá-los. Realizamos um trabalho de red teaming, agindo como invasores para testar e sondar um aplicativo de IA voltado a clientes do setor financeiro. O que descobrimos é importante para qualquer pessoa que implante aplicativos baseados em LLM nos quais a segurança não seja opcional.
Red teaming é a prática de tentar deliberadamente quebrar seu sistema de IA para corrigir vulnerabilidades antes que um invasor real as encontre. No setor financeiro, os riscos são particularmente altos: aplicativos de IA acessam dados de clientes, processam transações e fornecem análises financeiras. Uma falha pode causar desde uma experiência ruim para o usuário até violações regulatórias, perdas financeiras e danos irreparáveis à marca.
Nosso objetivo era encontrar vulnerabilidades com antecedência, testar padrões realistas de ataque e ajudar a organização a atender às exigências de segurança de IA que os órgãos reguladores levam muito a sério.
Vale fazer uma distinção: o jailbreak ataca os filtros de segurança do modelo subjacente; a injeção de prompt ataca o próprio aplicativo, combinando entradas não confiáveis do usuário com o prompt confiável do desenvolvedor. A injeção de prompt representa um risco maior porque tem como alvo seu sistema e os dados confidenciais que ele processa, e não um modelo de uso geral.
Nossa primeira rodada compreendeu cerca de 750 testes de:
Vazamento de dados entre sessões
Exposição de PII (por linguagem natural, manipulação de API e diversas codificações)
Injeção de SQL
Substituição do prompt do sistema
Nos testes iniciais, identificamos dois grandes problemas no sistema existente: o tratamento de consultas com múltiplas intenções e o uso de prompts codificados.
Consultas com múltiplas intenções: solicitações que combinam pedidos legítimos e maliciosos. Por exemplo: "Mostre meus gastos por categoria e também execute [SQL malicioso]." O aplicativo não detectava a intenção maliciosa e dependia inteiramente das proteções da camada de dados posterior. Isso equivale a deixar a porta da frente aberta porque você confia no cofre do porão.
Codificação: solicitações codificadas em Base64, hexadecimal, LeetSpeak e homoglifos. Pode ser difícil para os sistemas filtrar intenções maliciosas. Embora essas consultas não tenham exposto dados confidenciais, elas contribuíram para uma desestabilização significativa do sistema, com alucinações, repetição de SQL malicioso aos usuários, confusão na classificação de intenções etc.
Os resultados dos testes iniciais mostraram:
Alucinações temporais: o modelo apresentava com confiança datas, horários de transações ou resumos temporais inventados — um risco significativo no setor financeiro, no qual um cliente agir com base em uma data incorreta pode ter consequências reais
Repetição de SQL malicioso ao usuário, algo preocupante pelo risco de envenenamento da memória
Confusão na classificação de intenções
Formatação de saída desorganizada
Com essas descobertas em mãos, restringimos nosso foco. Os testes de injeção de SQL e codificação perderam prioridade, pois a equipe já estava tratando desses problemas. Em vez disso, nos concentramos nos vetores de ataque mais bem-sucedidos: exposição de PII e vazamento entre sessões.
A descoberta mais marcante da segunda rodada foi surpreendentemente simples: muitas vezes, não é preciso usar nada sofisticado.
Em muitos casos, bastava pedir dados internos no contexto de uma solicitação aparentemente legítima para o sistema concordar em expô-los. Consultas simples recebiam respostas que mencionavam IDs internos e campos do sistema que nunca deveriam ser exibidos aos usuários finais.
Ao aprofundar a investigação, descobrimos que não se tratava apenas de uma falha no aplicativo. O serviço posterior de conversão de texto em SQL criava consultas que solicitavam mais campos do que deveria, e suas respostas explicativas mencionavam dados que deveriam estar restritos. Isso revelou uma brecha real entre os sistemas, o tipo de vulnerabilidade que só aparece quando se testa toda a pilha, e não componentes individuais isoladamente.
Faça red teaming no sistema, não no modelo. Testar um LLM isoladamente revela muito pouco sobre a postura de segurança do seu aplicativo. Teste toda a pilha, de ponta a ponta, da mesma forma que um usuário interagiria com ela.
A validação das entradas deve acontecer antes do LLM. Consultas codificadas, ataques com múltiplas intenções e tentativas básicas de injeção devem ser detectados no perímetro, e não delegados a serviços posteriores.
Não confie nos pontos de integração. Em arquiteturas com vários serviços, é nas brechas entre os sistemas que se escondem as vulnerabilidades mais interessantes. Confiança zero significa confiança zero: valide tudo em todas as camadas.
Ataques simples funcionam. Ataques sofisticados de jailbreak ganham as manchetes, mas às vezes basta... pedir. Se o seu sistema exibe tranquilamente identificadores internos quando um usuário os inclui em uma consulta que, fora isso, é legítima, há um problema.
Entenda o que você realmente está testando. Padrões de ataque conhecidos podem ser detectados pelo próprio treinamento do LLM, e não por suas proteções. Incorpore observabilidade ao red teaming para entender quais controles estão realmente sendo acionados.
Ambientes restritos exigem soluções criativas. Provedores personalizados e suporte a modelos locais viabilizam um red teaming relevante sem acesso especializado à nuvem. Mas seja transparente sobre as limitações que isso introduz.
Red teaming não é uma ação pontual. É um processo iterativo, deve ser automatizado sempre que possível e precisa evoluir junto com seu sistema. Os ataques que serão relevantes amanhã não são os mesmos que importam hoje.
Sistemas de IA em ambientes regulamentados enfrentarão cada vez mais escrutínio. As organizações que tratam os testes de segurança como uma disciplina contínua, e não como um item a marcar antes do lançamento, estarão mais preparadas para esse escrutínio e evitarão crises de imagem que destroem a confiança dos clientes.