ML Red Teaming para LLMs: É possível usar apenas ferramentas open source?

Com o crescente número de Large Language Models (LLMs) e sistemas de agentes no ambiente corporativo, as abordagens tradicionais de segurança tornam-se insuficientes. As vulnerabilidades agora residem não apenas no código, mas também em prompts, na memória dos agentes, no contexto RAG (Retrieval-Augmented Generation) e no comportamento probabilístico dos próprios modelos.

ML Red Teaming (AI Red Teaming) é uma forma especializada de teste ofensivo onde uma equipe simula as ações de atacantes reais contra sistemas de machine learning, LLMs, IA generativa e sistemas de agentes. Diferente do pentest clássico, o objetivo aqui não é apenas "invadir", mas sim identificar vulnerabilidades inerentes aos componentes de IA, avaliar riscos e aumentar a resiliência real do modelo de IA utilizado.

Objetivos do ML Red Teaming:

• Identificar vulnerabilidades reais antes que atacantes o façam.
• Avaliar a resiliência de modelos e sistemas de agentes contra ataques.
• Obter uma avaliação de risco não teórica, mas confirmada por ataques práticos.
• Aumentar a confiança em sistemas de IA por parte de negócios e reguladores.
• Formar a base para a construção de defesas eficazes e monitoramento em SOC (Security Operations Center).

As tarefas principais do ML Red Teaming incluem a simulação de ataques baseados nas técnicas do MITRE ATLAS, a verificação da resiliência de modelos contra prompt injection e jailbreak, além do teste de proteção contra ameaças como extração de modelo e data poisoning. Atenção especial é dada à identificação de vulnerabilidades em sistemas de agentes, particularmente nos mecanismos de uso de ferramentas, gerenciamento de memória e orquestração.

Metodologias e Frameworks Diversas metodologias são empregadas no ML Red Teaming:

• Combinação de escaneamento automatizado com testes manuais por especialistas.
• Ataques multi-agente (um modelo ataca, outro avalia, um terceiro gera variações).
• Testes em diferentes níveis de maturidade: desde simples prompt injection até ataques complexos multi-etapas contra memória, ferramentas e orquestração de agentes.

Para o planejamento de ataques, frameworks chave são utilizados. O principal mapa de ameaças para sistemas de IA é o MITRE ATLAS. Em junho de 2026, ele incluía 16 táticas e 170 técnicas. O OWASP Top 10 for LLM Applications também é crucial, com a ameaça LLM01: Prompt Injection ainda em primeiro lugar. Recomendações do NIST AI RMF e NIST AI 100-2 são consideradas na avaliação de riscos. Para sistemas agentic AI, o framework OWASP ASI é adicionalmente utilizado.

Ferramentas Open Source vs. Soluções Corporativas Para a realização dos testes, podem ser usados scanners de ML Red Teaming integrados a Firewalls de IA/LLM ou ferramentas e frameworks open source. As soluções open source mais conhecidas incluem:

• Garak: Um scanner rápido e abrangente de vulnerabilidades de LLM, com mais de 100 probes, arquitetura plugável e suporte a múltiplos modelos.
• Promptfoo: Ferramenta para Red Teaming, avaliação e integração CI/CD, com interface web amigável.
• PyRIT: Focado em testes empresariais profundos de LLMs e agentes, com suporte a ataques multi-turn.
• DeepTeam e similares: Especializados em testes de sistemas de agentes.

No entanto, existem limitações significativas. PyRIT possui forte dependência da infraestrutura Azure AI Foundry, tornando-o inviável em ambientes isolados. Garak e Promptfoo oferecem testes linguísticos básicos, insuficientes para injeções semânticas complexas em cirílico ou formatos de dados pessoais russos. Ferramentas open source são ótimas para pesquisas pontuais, mas apresentam sérias restrições em ambientes corporativos reais, especialmente em empresas brasileiras:

• Apenas testes, sem proteção em tempo real: Exigem configuração manual de filtros e guardrails.
• Altos requisitos de expertise e trabalho manual: Necessidade de construir pipelines CI/CD, monitoramento e integração.
• Detecção, mas não correção: A maioria foca apenas na detecção de vulnerabilidades.
• Suporte limitado a português e especificidades locais: A maioria dos probes é focada no inglês, deixando de lado nuances linguísticas e formatos de dados locais.
• Ausência de compliance: Não atendem a requisitos regulatórios sem customizações extensivas.
• Isolamento de processos SOC: Falta de relatórios prontos, integração com SIEM/SOAR e monitoramento de anomalias.
• Velocidade de reação a novas ameaças: Dependente da comunidade e da expertise interna.

A Complexidade da Prática de Escaneamento Executar um scanner é apenas a ponta do iceberg. A principal dificuldade reside em avaliar a qualidade e a completude dos testes. LLMs operam de forma estocástica, o que significa que o mesmo input pode gerar outputs diferentes. Por isso, múltiplos testes são necessários para identificar vulnerabilidades de forma confiável. A avaliação de risco se expande para além das vulnerabilidades clássicas de software, abrangendo o comportamento probabilístico e a compreensão da linguagem natural.

Classes de Ataques em Scanners ML Red Teaming Existem diversas classes de ataques a serem verificados. Embora conjuntos de regras para escaneamento sejam amplamente disponíveis, soluções como o INFERA AI.Firewall utilizam regras próprias adaptadas a cenários corporativos reais:

1. Jailbreak e Bypass de Restrições: Classe de ataque perigosa, especialmente para serviços em nuvem e chatbots públicos. Permite acesso ao prompt do sistema, dados confidenciais ou manipulação do modelo. Testes incluem prompts de role-playing e simulações de prompts de sistema, além de jailbreaks adaptativos multi-etapas.

2. Prompt Injection: Ataque conhecido, com grande impacto em sistemas de agentes que tomam decisões sobre chamadas de ferramentas e mudanças de estado. Requer testes tanto nos sistemas de agentes quanto nos LLMs subjacentes.

3. Vazamento de Dados e Prompt do Sistema: Verifica se o modelo reproduz dados de treinamento ou confidenciais em resposta a prompts. É crucial que o scanner seja configurado para identificar dados específicos da organização (contexto RAG, dados de fine-tuning).

4. Toxicidade e Conteúdo Inseguro: Bloco mais solicitado, focado em evitar a exposição pública de conteúdo que possa desacreditar a empresa, como linguagem ofensiva ou declarações políticas.

5. Alucinações e Desinformação: Ataques que visam provocar a geração de informações falsas ou inventadas pelo modelo. Um "modelo juiz" compara a saída do modelo alvo com um valor de referência para determinar a correção. Em sistemas corporativos, recusas em executar tarefas fora do escopo (ex: um chatbot médico se recusando a escrever código) são consideradas comportamentos seguros.

6. Ataques Multi-etapas: Bloco mais volumoso e demorado, onde o modelo atacante gera continuamente novas variações de prompts e reformula mensagens anteriores. O contexto é gradualmente diluído, levando o LLM a "esquecer" restrições e regras iniciais.

7. Ataques a Dados Corporativos: Testes utilizando dados corporativos reais, como know-how, fórmulas internas e informações setoriais sensíveis. O "modelo juiz" analisa as respostas em busca de palavras-chave e fragmentos relacionados a dados corporativos protegidos.

Resultado e Integração O resultado do scanner ML Red Teaming é enviado ao SOC (ou ASOC/ASPM), contendo tipo de ataque, técnica, texto do ataque e resposta do modelo. Esses dados são usados para reconfigurar o AI.Firewall, atualizar regras e políticas. A integração entre o scanner e o firewall é essencial para um funcionamento coeso, permitindo a aplicação imediata de proteções como filtragem, bloqueio e mascaramento de dados.

Por que Abordagens Clássicas de Red Teaming Falham para IA Métodos clássicos de Red Teaming foram desenvolvidos para sistemas determinísticos. Com ML e LLMs, o comportamento é probabilístico e a superfície de ataque se expande para modelos, dados, prompts e sistemas de agentes. As exigências para os especialistas aumentam, necessitando de conhecimento em ML, segurança da informação e pensamento de Red Team. Testes devem ser contínuos, e os critérios de sucesso migram de "exploit alcançado" para métricas estatísticas de eficácia. As respostas vão além de patches, incluindo retreinamento de modelos e implementação de guardrails.

Recomendações Práticas

• Para CISOs: Incluir ML Red Teaming em programas Red Team/Purple Team, analisar o MITRE ATLAS regularmente e implementar ferramentas AI/LLM Firewall.
• Para SOCs: Adicionar controle de uso de LLMs/IA em SIEM/SOAR, treinar analistas em técnicas de prompt injection e jailbreak, criar planos de teste baseados no MITRE ATLAS e integrar resultados de scanners ML Red Teaming nos processos de resposta.

Ferramentas open source são um excelente ponto de partida para experimentação e desenvolvimento de expertise. No entanto, para uso industrial maduro de IA, especialmente em setores regulados e ambientes isolados, uma abordagem holística e testes contínuos são indispensáveis. Somente assim é possível passar de "sabemos que há riscos" para "gerenciamos ativamente os riscos".