Enviar uma aplicação LLM significa enviar um sistema cujos modos de falha não são exceções ou stack traces mas saídas — um chatbot que vaza seu prompt de sistema, um agente que pode ser persuadido a chamar uma ferramenta que não deveria, um assistente de suporte que inventa com confiança uma política de reembolso. Nenhum destes lança um erro. Testes tradicionais, que afirmam que uma função retorna um valor esperado, não podem expressar a maioria deles. A disciplina que emergiu para preencher esse gap é red teaming de LLM: deliberadamente atacar seu próprio modelo e aplicação para encontrar as entradas que produzem comportamento inaceitável, antes que alguém mais faça.
Por 2026 isso amadureceu de experimentos de prompt ad-hoc em uma paisagem de ferramentas com camadas distintas. Este guia mapeia aquela paisagem — garak e PyRIT na camada de modelo, DeepTeam e promptfoo na camada de aplicação, Agentic Security para fuzzing de endpoint black-box, e Giskard e Inspect para scanning e avaliação rigorosa. O fio condutor é que estas ferramentas não são competidoras: elas capturam diferentes classes de falha, e executar apenas uma deixa gaps previsíveis.
O que você realmente está testando
Antes das ferramentas, ajuda nomear as classes de falha, porque demandam testes diferentes. Jailbreaks e injeção de prompt são o destaque: conseguir o modelo ignorar suas instruções, seja por manipulação direta ("ignore instruções anteriores") ou indiretamente através de conteúdo que ele recupera — um documento envenenado que carrega instruções que o modelo então segue. A injeção indireta é a variante mais séria em sistemas de RAG e agente, porque o atacante nunca toca a caixa de prompt.
Vazamento de dados cobre extração do prompt de sistema, de PII que o modelo viu em contexto, ou de dados de treinamento. Agência excessiva é a classe de falha que cresce mais perigosa conforme agentes ganham ferramentas: o modelo tomando uma ação que deveria ter recusado, ou encadeando ferramentas de um jeito que excede sua autoridade pretendida. Conteúdo prejudicial é conformidade direta com solicitações que a aplicação deveria recusar. E alucinação — fabricação confiante — é frequentemente o risco mais alto de negócio mesmo que seja o menos dramático.
Cada um destes vive em uma camada diferente. Susceptibilidade a jailbreak é amplamente uma propriedade do modelo. Agência excessiva e vazamento de prompt são propriedades da aplicação — seu prompt de sistema, suas ferramentas, seus guardrails. Alucinação é uma propriedade do pipeline, especialmente qualidade de recuperação. Esta estratificação é exatamente por que as ferramentas se dividem como fazem.
Scanners de nível de modelo: garak e PyRIT
garak (de NVIDIA) é a coisa mais próxima a nmap para LLMs. Ele executa uma biblioteca grande de investigações contra um modelo — famílias de jailbreak, injeção de prompt, toxicidade, vazamento de dados, ataques de codificação — e relata quais sucessos. Você o aponta para um modelo (um modelo HuggingFace, um endpoint OpenAI, um servidor local) e trabalha através de seu catálogo. Seu valor é amplitude e baixo esforço: você aprende rapidamente quais famílias de ataque conhecidas seu modelo é suscetível, sem desenhar nada você mesmo.
PyRIT (de Microsoft) visa um problema mais duro: ataques de múltiplos-turnos e multi-modais. Muitos jailbreaks reais não funcionam em uma mensagem única; funcionam estabelecendo contexto sobre vários turnos e escalando gradualmente. PyRIT fornece orquestração para isto — estratégias de ataque como crescendo (escalação lenta) e TAP (árvore de ataques com poda) que adaptam baseado nas respostas do modelo. É mais um SDK que um scanner: você compõe orquestradores, targets, conversores, e scorers. Isto o faz mais trabalho para começar e mais poderoso para pesquisa em ataques que uma investigação de um único shot não pode encontrar.
A limitação compartilhada é que ambos primariamente testam o modelo, não sua aplicação. Um modelo que resiste às investigações de garak em isolamento ainda pode ser trivialmente comprometido dentro de sua app, porque seu prompt de sistema, sua recuperação, e suas ferramentas criam uma superfície de ataque que o scan de nível de modelo nunca viu.
Suites de nível de aplicação: DeepTeam e promptfoo
É aqui onde DeepTeam e promptfoo se encaixam. Ambos testam sua aplicação como deployada, encapsulando o que quer que sua app realmente seja — prompt, recuperação, ferramentas, guardrails — e atacando aquele conjunto todo.
DeepTeam, da equipe DeepEval, expressa red teaming como Python: você fornece um model_callback que chama sua app, declara quais vulnerabilidades investigar (vazamento de PII, agência excessiva, viés, vazamento de prompt) e quais ataques usar, e ele gera e executa casos adversariais. Suas melhorias de ataque são a parte interessante — o mesmo ataque base reescrito como base64, em outra linguagem, como roleplay, ou escalado através de turnos, o qual é como atacantes reais evitam filtros ingênuos. Porque é código, cai em um conjunto de testes e executa em CI.
promptfoo vem disso de avaliação: é uma CLI dirigida por config para testar saídas de LLM que cresceu uma capacidade substancial de red-teaming, auto-gerando prompts adversariais através de dúzias de plugins de ataque e mapeando achados para frameworks de conformidade. Sua força é integração de CI e o fato que a mesma ferramenta cobre tanto evals de qualidade quanto testes de segurança, então um harness serves ambos os propósitos.
Para a maioria dos times enviando um produto de LLM, esta camada é mais importante que a camada de modelo, porque testa a coisa que você realmente deployou. O catch é que requer você definir o que "inaceitável" significa para sua aplicação — as ferramentas geram os ataques, mas você fornece o julgamento sobre quais saídas são falhas.
Abordagens black-box e scanning
Duas outras formas valem saber. Agentic Security trata seu endpoint como uma caixa preta e fuzza-a agenticamente — gerando investigações, observando respostas, adaptando — com a adição útil de testes de estresse de API. Aquela última parte é subestimada: um compartilhamento significante de deployments de LLM falham em limites de taxa, esgotamento de token, e abuso de recurso antes deles falharem em segurança de conteúdo, e a maioria das ferramentas de red-teaming ignora isto completamente.
Giskard inverte o fluxo de trabalho usual. Em vez de requer você especificar o que testar, ela escaneia o modelo — usando sua descrição do que a app faz para gerar investigações relevantes do domínio — e produz um relatório de vulnerabilidades detectadas, que ela pode então converter em um conjunto de testes reutilizável. Aquele padrão de scan-then-testify é valioso precisamente porque a parte mais dura de red teaming é saber o que procurar. Giskard encontra problemas que você não pensou em testar, então os fixa como testes de regressão.
Finalmente, Inspect do UK AI Safety Institute se senta ligeiramente à parte: é um framework de avaliação rigorosa ao invés de uma ferramenta de ataque, mas sua estrutura (datasets, solvers, scorers) e seu excelente visualizador de transcrição o tornam a escolha certa quando você precisa medição defensável e reproduzível — incluindo de comportamento agentic — ao invés de uma lista de vulnerabilidade.
Construindo uma prática em camadas
A conclusão prática é que estas ferramentas se compõem. Uma prática razoável de 2026 parece assim.
Quando você seleciona ou atualiza um modelo base, execute um scanner de nível de modelo — garak por amplitude, PyRIT se robustez de múltiplo-turno é importante para seu perfil de risco. Isto informa escolha de modelo e diz a você o que a fundação resiste por si.
Durante desenvolvimento, execute uma ferramenta de estilo de scan como Giskard contra sua aplicação real para descobrir classes de falha que você não tinha antecipado, e converta seus achados em testes.
Em CI, em cada prompt, modelo, ou mudança de ferramenta, execute uma suite de nível de aplicação — DeepTeam ou promptfoo — como um gate. Este é o automation de maior valor, porque prompts e definições de ferramenta são a superfície de controle de uma app de LLM e elas mudam constantemente. Uma edição de prompt que parece inofensiva pode remover a frase que estava prevenindo um jailbreak.
Antes de release, adicione fuzzing black-box contra o endpoint deployado, incluindo testes de estresse, para capturar problemas em nível de deployment que testes em nível de código perdem.
E mantenha humanos nisto. Toda ferramenta automatizada testa famílias de ataque conhecidas. Ataques novelistas — as específicas ao seu domínio, seus dados, e suas ferramentas — vêm de uma pessoa que entende a lógica de negócio pensando adversarialmente. Automação levanta o piso; não substitui o teto.
Injeção indireta: o ataque que quebra o modelo
Uma classe de ataque merece tratamento separado porque derrota a intuição que a maioria dos times começa com. Injeção de prompt direta — um usuário digitando "ignore suas instruções" — é o que todo mundo testa primeiro, e é a metade mais fácil. Injeção indireta é quando as instruções maliciosas chegam através do conteúdo que o sistema recupera: um documento em sua base de conhecimento, uma página web que o agente navega, um email que ele resume, um comentário de código que ele lê. O atacante nunca interage com sua caixa de prompt.
Isto importa enormemente para sistemas de RAG e agentes, porque sua proposição de valor inteira é consumir conteúdo externo. Um assistente de suporte que responde de sua documentação fielmente seguirá instruções embutidas em um documento se alguém conseguir um documento para o corpus — através de uma wiki pública, um ticket enviado por cliente, ou uma página scraped. Um agente que lê uma issue do GitHub pode ser instruído por aquela issue. O limite de confiança que as pessoas imaginam ("usuários são não confiáveis, nossos dados são confiáveis") não se mantém uma vez que qualquer parte do corpus é influenciável.
Testar para isto é mais duro que testar injeção direta, porque requer simular conteúdo envenenado, não prompts envenenados — você precisa colocar texto adversarial aonde recuperação achará e verificar que o modelo não age nisso. Ferramentas de nível de aplicação lidam com isto melhor que scanners de nível de modelo, uma vez que o pipeline de recuperação é parte do que eles exercem, mas frequentemente requer você construir o cenário deliberadamente.
As mitigações são arquiteturais ao invés de baseadas em prompt. Trate todo conteúdo recuperado como entrada não confiável, do mesmo jeito que trata entrada de usuário. Não deixe texto recuperado chegar a uma posição onde pode ser interpretado como instruções se você conseguir evitar estruturalmente. Constrainja que ferramentas um agente pode chamar ao processar conteúdo não confiável, e requeira confirmação para ações consequentes. E mantenha provenance: saber qual documento produziu uma resposta ruim é o que transforma um incidente em um fix.
O que red teaming não corrige
Uma cautela que merece ser declarada claramente: encontrar uma vulnerabilidade não é o mesmo que corrigi-la, e vulnerabilidades de LLM frequentemente não são completamente corrigíveis. Você não pode patchear um modelo do jeito que você patcha um buffer overflow. As respostas realistas são mitigação ao invés de eliminação: prompts de sistema mais apertados, guardrails de entrada e saída como LLM Guard, permissões de ferramenta constrangidas, aprovação humana para ações consequentes, e monitoramento para comportamento anômalo.
Isto muda o que um relatório de red team significa. Em segurança tradicional, um achado implica um fix. Em segurança de LLM, um achado frequentemente implica uma decisão de risco: este ataque sucessos em alguma taxa, aqui está a mitigação, aqui está o risco residual, é aceitável para este caso de uso? Times que esperam red teaming produzir uma limpeza de saúde serão perpetuamente desapontados. Times que o usam para quantificar e conscientemente aceitar risco recebem valor real.
O corolário é que arquitetura bate engenharia de prompt para as falhas que mais importam. Um agente que não pode ser enganado em transferir dinheiro porque estruturalmente não tem aquela permissão é mais seguro que um confiando no modelo para recusar. Agência excessiva é melhor endereçada dando menos agência. Saída mais útil de red teaming frequentemente é a realização que uma capacidade não deveria ter sido exposta em primeiro lugar.
A linha de fundo
Red teaming de LLM se tornou uma disciplina real porque falhas de LLM são saídas ao invés de erros, e testes ordinários não podem expressá-las. O ferramental de 2026 divide por camada, e aquela divisão é a chave para usá-lo bem: garak e PyRIT investigam o modelo, DeepTeam e promptfoo atacam a aplicação que você realmente deployou, Agentic Security fuzza o endpoint incluindo seus limites de recurso, e Giskard descobre problemas que você não sabia procurar. Execute mais de um, gate CI na camada de aplicação aonde prompts mudam mais, mantenha pensamento adversarial humano no loop, e trate achados como decisões de risco ao invés de bugs aguardando um patch — então corrija o que você conseguir na arquitetura ao invés de no prompt.
Referências e Recursos
Ferramentas
Background e análise
- Best LLM Vulnerability Scanners 2026: Garak, PyRIT, Promptfoo
- LLM Red Teaming Guide 2026: Tools, Attacks & Methodology — AppSec Santa
- LLM Red Teaming Tools Compared — QAwerk
- awesome-ai-security-tools
Cheatsheets relacionadas 1337skills