O experimento: 2 mil hackers contra um assistente jurídico de IA

Fernando Ibanez, desenvolvedor chileno, criou um assistente jurídico movido por IA e fez algo que poucos teriam coragem: convidou a internet para tentar invadi-lo. Mais de 2 mil pessoas aceitaram o desafio em menos de uma semana.

O assistente, chamado HackMyClaw, respondia perguntas jurídicas usando um modelo de linguagem grande (LLM) com acesso a documentos confidenciais simulados. O objetivo era descobrir o máximo possível de vulnerabilidades antes de um eventual lançamento real.

O resultado foi um mapa detalhado dos ataques mais eficazes contra sistemas de IA em produção e licoes práticas que todo desenvolvedor deveria conhecer antes de colocar qualquer LLM em contato com dados sensíveis.

Como funciona a segurança em sistemas de IA

Diferente de aplicações tradicionais, um assistente de IA não tem uma lista fixa de comandos validos. O modelo processa linguagem natural e decide o que fazer com base no contexto. Isso abre vetores de ataque que simplesmente não existem em sistemas convencionais.

O principal conceito aqui é o prompt injection: o atacante insere instruções dentro da mensagem do usuário que sobrescrevem ou manipulam as instruções originais do sistema. Pense como um SQL injection, mas para linguagem natural.

Outro vetor e o vazamento de contexto: o modelo, ao tentar ser útil, acaba revelando informações do system prompt, documentos anexados ou histórico de conversas anteriores. Não por bug de código, mas porque foi treinado para ajudar e não tem nocao clara do que deve ser sigiloso.

Os 5 ataques mais comuns documentados

Dos ataques registrados no experimento, cinco padrões apareceram com maior frequência e maior taxa de sucesso:

  • Ignore previous instructions: o clássico. Instruções diretas para o modelo esquecer o system prompt e obedecer o atacante. Funcionou surpreendentemente bem em variantes mais elaboradas.
  • Roleplay e personas: pedindo ao modelo para fingir ser outro assistente sem restrições, adotando um papel sem filtros éticos.
  • Exfiltração por indireta: em vez de pedir o documento secreto diretamente, perguntar o que o sistema não pode dizer ou pedir um resumo do que ele sabe sobre determinado cliente.
  • Injeção via documento: enviar um PDF ou texto contendo instruções ocultas para o modelo. O sistema processa o documento e executa os comandos embutidos.
  • Ataque por exaustão: conversas longas para confundir o modelo sobre quais instruções são originais e quais foram injetadas durante a sessão.

Como começar a proteger seu sistema de IA

Se você esta construindo qualquer aplicação com LLMs, especialmente com acesso a dados sensíveis, aqui esta o caminho mínimo para não ser o próximo estudo de caso.

Passo 1: Separe privilégios. O modelo de linguagem não deve ter acesso direto a banco de dados, arquivos ou APIs sensíveis. Use uma camada intermediaria que valida cada ação antes de executar.

Passo 2: Nunca confie no output do modelo. Trate toda saída do LLM como entrada de usuário não confiável. Se o modelo retorna um comando SQL, valide antes de executar.

Exemplo prático: prompt injection em um chatbot de suporte

Imagine um chatbot de suporte com acesso ao histórico de pedidos dos clientes. O system prompt define que o assistente deve responder apenas sobre pedidos do cliente autenticado.

Um atacante envia uma mensagem pedindo ao modelo para ignorar as instruções anteriores e listar todos os pedidos do banco de dados em formato JSON. Dependendo do modelo e da implementação, isso pode funcionar.

A solução não e apenas melhorar o prompt de sistema, mas garantir que a busca no banco de dados use o ID do usuário autenticado como filtro obrigatório no código, independente do que o modelo peca.

Comparação: estratégias de proteção

Existem varias estratégias para mitigar ataques em sistemas de IA, cada uma com trade-offs diferentes:

  • Guardrails de modelo: camadas de classificação que analisam entrada e saída. Eficaz contra ataques óbvios, mas aumenta latência e tem custo adicional.
  • Arquitetura de privilegio mínimo: o modelo só acessa o que é estritamente necessário para a tarefa. Mais robusto, exige mais engenharia.
  • Fine-tuning defensivo: treinar o modelo especificamente para reconhecer e recusar tentativas de manipulação. Caro e não elimina 100% dos casos.
  • Monitoramento e alertas: detectar padrões suspeitos em produção e acionar revisão humana. Complementa as outras abordagens.

A conclusão do experimento e que nenhuma técnica isolada e suficiente. Sistemas de IA em produção precisam de defesa em profundidade, assim como qualquer outro sistema crítico.

Pontos positivos e limitações do red teaming de IA

O experimento mostrou que o red teaming aberto e eficaz para descobrir vulnerabilidades que equipes internas não imaginaram. A diversidade de atacantes gera criatividade que equipes pequenas não conseguem replicar.

Por outro lado, o red teaming não substitui uma auditoria estruturada de segurança. Muitos dos ataques bem-sucedidos exploraram decisões de arquitetura que um teste de penetração formal teria identificado mais rapidamente.

A limitação mais importante: o que funciona hoje pode não funcionar com versões futuras do modelo, mas o inverso também é verdade. Atualizações de modelo podem introduzir novos comportamentos inesperados.

Casos de uso reais: quem precisa se preocupar agora

Não e só quem esta construindo assistentes jurídicos que deve se preocupar. Qualquer aplicação com LLMs e dados sensíveis e um alvo em potencial:

  • Sistemas de RH com IA: acesso a salários, avaliações e dados pessoais de funcionários.
  • Chatbots de suporte com histórico de clientes: pedidos, endereços, dados de pagamento.
  • Assistentes de código com acesso a repositórios privados: segredos em variáveis de ambiente, lógica de negócio proprietária.
  • Agentes autónomos com permissão de escrita: o pior cenário. Um agente que pode enviar emails, criar registros ou executar código e um vetor de ataque crítico.

Dicas e boas práticas de segurança para LLMs

Com base nos resultados do experimento e nas melhores práticas da industria, aqui esta o que usuários experientes fazem:

  • Nunca colocar segredos (tokens, senhas, dados privados) no system prompt. Eles vazam com facilidade.
  • Usar IDs internos em vez de nomes ou dados sensíveis nas mensagens enviadas ao modelo.
  • Logar todas as interações em produção para auditoria posterior.
  • Definir um escopo estrito de ações que o modelo pode sugerir, sem executar comandos sem validação.
  • Testar regularmente com novos ataques. O cenário de ameaças evolui rapidamente.

Um erro comum de iniciantes e confiar que o modelo vai entender que não deve revelar informações. O modelo não tem nocao de confidencialidade por padrão. Isso precisa ser aplicado no código, não apenas no prompt.

Vale a pena fazer red teaming no seu sistema de IA?

Sim, especialmente se você esta colocando um LLM em contato com dados de usuários, documentos sensíveis ou qualquer ação no mundo real. O experimento mostrou que os ataques são variadíssimos e criativos demais para serem antecipados por uma equipe pequena sozinha.

Se você ainda esta na fase de prototipo, e o momento ideal para testar. Corrigir vulnerabilidades de arquitetura antes do lançamento e muito mais barato do que depois. Se já esta em produção, comece pelo básico: separação de privilégios e monitoramento de anomalias.

O próximo passo prático: leia o relatório completo do experimento no site do autor e aplique pelo menos as três primeiras medidas de proteção esta semana.