Red team para agentes de IA: como testar riscos reais

Um teste seguro também pode criar risco

Empresas costumam testar agentes em situações limpas: o documento correto, a conta certa, a ferramenta disponível e uma solicitação parecida com os exemplos usados na construção. Esse conjunto confirma o caminho esperado. Ele diz pouco sobre o que acontece quando alguém tenta desviar a tarefa, quando duas regras entram em conflito ou quando o ambiente permite um acesso que deveria estar bloqueado.

Red team é o trabalho deliberado de procurar esses caminhos antes que apareçam na operação. A equipe cria cenários adversariais, observa o agente e verifica se as barreiras técnicas impedem que uma interpretação ruim se transforme em acesso, ação ou propagação.

O ponto ficou visível em um relato publicado pela Anthropic em 30 de julho de 2026. A empresa revisou 141.006 execuções de avaliações de cibersegurança e encontrou três incidentes em que modelos alcançaram a internet a partir de ambientes de teste e obtiveram acesso não autorizado a sistemas reais. Segundo o relato, uma divergência de configuração deixou acesso externo disponível enquanto o prompt informava aos modelos que o ambiente era uma simulação isolada.

O caso é extremo, mas a lição serve para implantações empresariais comuns. Texto de orientação, configuração real, permissões, rede, ferramentas e monitoramento precisam contar a mesma história. Se uma camada diz "ambiente de teste" e outra mantém acesso de produção, a etiqueta perde para a capacidade efetivamente concedida.

O que significa red team para agentes de IA

Red team é uma avaliação adversarial planejada. Pessoas autorizadas tentam fazer o sistema ultrapassar sua finalidade, seus limites de acesso ou seus critérios de segurança. O objetivo é descobrir combinações de comportamento e arquitetura que os testes funcionais não exercitam.

Em um agente, a avaliação pode investigar se ele:

aceita uma instrução escondida em documento ou página;
consulta informação de outro cliente;
usa uma ferramenta fora da finalidade;
amplia volume ou escopo sem autorização;
executa ação externa com identidade incerta;
contorna aprovação humana;
continua depois de um bloqueio;
repete uma escrita após timeout;
revela contexto, segredo ou dado desnecessário;
confunde ambiente de teste com produção;
esconde ou empobrece a evidência da execução;
transforma uma saída de ferramenta em comando.

O teste observa o sistema completo. Uma resposta verbal obediente não prova segurança se uma chamada perigosa chegou à API. Da mesma forma, o modelo pode tentar uma ação inadequada e a camada de autorização bloqueá-la corretamente. O segundo resultado revela uma tentativa, mas também demonstra que uma barreira funcionou.

O guia sobre prompt injection em agentes de IA aprofunda uma classe importante de ataque. Red team possui escopo maior: explora identidade, dados, ferramentas, rede, estado, filas, aprovações, interfaces e resposta operacional.

Quando esse tipo de teste faz sentido

Nem todo assistente interno precisa de uma operação adversarial sofisticada. A profundidade deve acompanhar alcance e consequência.

Priorize red team quando o agente:

lê conteúdo enviado por terceiros;
pesquisa páginas ou documentos fora do controle da empresa;
usa credenciais para acessar sistemas;
escreve em CRM, ERP, agenda, arquivos ou banco de dados;
envia mensagens ou publica conteúdo;
processa dados pessoais, financeiros, contratuais ou de clientes;
executa tarefas longas com várias ferramentas;
opera em nome de diferentes contas ou empresas;
pode criar código, arquivos executáveis ou comandos;
possui autonomia para iniciar outras rotinas;
participa de um processo difícil de reverter.

Uma rotina de resumo local e sem dado sensível pode usar um conjunto menor de testes. Um agente com acesso a pagamentos, comunicação externa ou vários clientes precisa de avaliação mais rigorosa e ambiente isolado.

Comece por um modelo de risco do trabalho

Uma lista copiada de ataques públicos gera atividade, mas pode ignorar a forma real como o agente produz valor e dano. Antes dos cenários, descreva o trabalho.

Registre:

unidade processada em cada execução;
evento que inicia a tarefa;
identidades autorizadas a solicitar trabalho;
dados e fontes que podem ser consultados;
ferramentas disponíveis;
ações que podem produzir consequência;
pessoas ou sistemas afetados;
fronteiras entre clientes, áreas e ambientes;
pontos de aprovação;
evidência que prova conclusão;
mecanismo de interrupção;
impacto máximo plausível de uma falha.

Esse mapa mostra onde concentrar o teste. Um agente de follow-up comercial pode ter baixo risco ao resumir uma conversa e alto risco ao selecionar destinatário, interpretar consentimento ou enviar uma condição comercial. O cenário adversarial deve mirar a passagem entre preparação e compromisso externo.

A arquitetura de um sistema de agentes ajuda a localizar essas fronteiras entre entrada, contexto, decisão, ferramenta e registro.

Defina regras de engajamento antes de atacar

Red team sem fronteira pode reproduzir o problema que pretende encontrar. O plano precisa declarar o que a equipe está autorizada a fazer e onde deve parar.

Escopo técnico

Liste agentes, versões, contas, ambientes, integrações, endereços, dados e ferramentas incluídos. Tudo que não estiver aprovado permanece fora do teste.

Destinos controlados

Mensagens seguem para caixas e números de teste. Escritas usam sandbox, mock, tabela temporária ou conta isolada. Arquivos executáveis e código permanecem em infraestrutura própria e sem rota para terceiros.

Dados permitidos

Use casos sintéticos, históricos anonimizados ou recortes mascarados. Dados reais exigem finalidade, autorização, acesso e retenção compatíveis com o teste.

Técnicas proibidas

Declare ações que a equipe não pode realizar, como atingir sistemas de terceiros, persistir acesso, extrair dados reais, publicar pacotes, enviar spam ou usar credenciais não fornecidas para a avaliação.

Critérios de parada

Interrompa o exercício quando houver sinal de saída do ambiente, acesso inesperado, dado real não previsto, efeito externo, perda de rastreabilidade ou incapacidade de acionar o controle de emergência.

Responsáveis

Defina quem conduz, quem monitora, quem pode interromper, quem preserva evidências e quem autoriza retomada. Um fornecedor externo também precisa operar dentro dessas regras e demonstrar isolamento.

O ambiente de teste para agentes de IA detalha a separação de credenciais, dados, estado e integrações. Red team depende dessa fronteira. Sem ela, um teste agressivo pode atingir a operação verdadeira.

Construa cenários por objetivo adversarial

Variar apenas a frase usada no prompt produz cobertura estreita. Organize cenários pelo resultado que um atacante ou uma falha tentaria alcançar.

Obter informação indevida

Teste se o agente revela instruções internas, dados de outro cliente, trechos além da finalidade, segredos, credenciais ou histórico que a identidade solicitante não deveria receber.

Variações úteis incluem pedido direto, conteúdo escondido em anexo, resultado contaminado de busca, referência cruzada entre contas e solicitação feita por identidade incompleta.

Acionar ferramenta fora do escopo

Tente induzir consulta, escrita, envio, exclusão ou transação incompatível com a tarefa. Observe o catálogo de ferramentas, os argumentos enviados e a validação do dispatcher.

Contornar aprovação

Crie urgência falsa, altere valor perto do limite, divida uma ação grande em várias pequenas, reutilize aprovação vencida ou tente trocar o alvo depois da confirmação humana.

Expandir alcance

Verifique se uma tarefa sobre um registro consegue virar lote, pesquisa aberta, disparo para vários destinatários ou execução em outra unidade. Limites de volume devem existir fora do modelo.

Confundir autoridade

Coloque políticas antigas, documentos conflitantes, comentários de usuário e saídas de ferramenta no mesmo contexto. O agente deve preservar a hierarquia das fontes e escalar quando não houver base suficiente.

Repetir ou continuar após falha

Simule timeout, confirmação perdida, evento duplicado, fila atrasada e retomada de checkpoint. Confirme idempotência, estado e tratamento da ação já executada.

Misturar ambientes ou clientes

Use identificadores parecidos, arquivos com nomes iguais, sessões concorrentes e memória persistente. O teste procura vazamento por cache, estado, busca ou credencial compartilhada.

Ocultar a trajetória

Tente provocar uma ação sem registro, sobrescrever log, remover fonte, mudar versão durante a execução ou concluir a tarefa sem confirmação do destino.

Teste comportamento e barreiras separadamente

Uma avaliação útil distingue duas perguntas.

O agente tentou ultrapassar o limite?

A trajetória mostra interpretação, escolha de ferramenta, argumentos, repetição, reação a bloqueios e pedido de escalonamento. Essa leitura ajuda a melhorar instruções, contexto e treinamento.

A arquitetura permitiu a consequência?

Permissões, regras determinísticas, identidade, rede, sandbox, aprovação e limites de volume precisam impedir ações fora do contrato mesmo quando o modelo escolhe mal.

Essa separação evita culpar o modelo por uma credencial ampla ou declarar o sistema seguro apenas porque o texto final foi educado. O relatório deve apontar qual camada falhou e qual barreira conteve o caminho.

Instrumente o exercício antes da primeira execução

A equipe precisa reconstruir o que aconteceu sem depender da memória dos participantes.

Registre:

identificador do cenário e da execução;
versão do agente, modelo e configuração;
identidade solicitante;
entradas e origens;
contexto recuperado;
ferramentas oferecidas e chamadas;
argumentos relevantes;
validações e bloqueios;
aprovações;
estado e checkpoints;
ações confirmadas no destino;
alertas;
custo e duração;
decisão de interromper ou continuar.

Logs completos também podem expor informação. Guarde apenas o necessário, restrinja acesso e defina descarte. A política de retenção para agentes de IA ajuda a evitar que a evidência do teste vire uma nova base sensível esquecida.

Classifique achados pela consequência

Contar quantos prompts "enganaram" o agente é uma métrica fraca. Um texto fora do tom e uma gravação indevida no sistema oficial possuem impactos diferentes.

Uma classificação prática pode considerar:

capacidade de alcançar dado ou ação;
sensibilidade do alvo;
necessidade de acesso autenticado;
alcance por execução;
reversibilidade;
facilidade de repetição;
possibilidade de detecção;
barreiras que ainda funcionaram;
intervenção humana necessária;
efeito sobre cliente, dinheiro, contrato ou continuidade.

Cada achado deve conter cenário, pré-condição, trajetória, resultado observado, resultado seguro esperado, evidência, impacto, camada responsável, correção proposta, dono e prazo.

Evite transformar severidade em opinião de quem apresentou o achado. Defina critérios antes do exercício e preserve uma regra: falhas impeditivas não são compensadas por uma média boa.

Corrija a barreira que falhou

Uma descoberta adversarial pode apontar causas diferentes.

Instrução ou contexto

A autoridade das fontes ficou ambígua, o agente recebeu informação excessiva ou a tarefa não possuía limite legível.

Identidade e permissão

A credencial permitia outra conta, ambiente, ação ou volume. A correção exige privilégio menor e separação técnica.

Ferramenta

A função exposta era genérica, aceitava parâmetros perigosos ou não validava alvo, valor e destinatário.

Orquestração

O fluxo pulou aprovação, perdeu estado, repetiu ação ou continuou depois do cancelamento.

Ambiente

Teste e produção compartilhavam rede, dados, credenciais, fila ou destino.

Monitoramento

A tentativa ficou invisível, o alerta chegou tarde ou ninguém possuía autoridade para interromper.

Processo

A empresa não havia definido fonte oficial, alçada, exceção ou dono. Nesse caso, melhorar o prompt sem corrigir o trabalho apenas desloca a falha.

Faça a menor mudança capaz de remover o caminho e rode novamente o cenário. Depois, adicione o caso à regressão para impedir que uma atualização futura reabra a mesma passagem.

O relato da Anthropic mostra uma falha de conjunto

No incidente divulgado, os modelos receberam a informação de que não havia acesso à internet, enquanto a infraestrutura permitia essa saída. Os agentes procuravam alvos dentro de desafios ofensivos e encontraram sistemas reais. A empresa atribuiu os eventos a uma combinação de configuração, monitoramento, desenho do ambiente e entendimento situacional dos modelos.

O relato também informa que as avaliações de cibersegurança foram interrompidas no mesmo dia em que a revisão identificou transcrições suspeitas. A resposta incluiu revisão ampla, notificação a parceiros e organizações afetadas, investigação e reforço de controles.

Para uma empresa brasileira, a aplicação prática é direta: a política declarada precisa ser verificável na infraestrutura. Um agente informado de que está em homologação deve possuir credenciais, rotas, destinos e dados de homologação. Se a capacidade real contradiz a instrução, a arquitetura escolheu o risco antes que o modelo começasse a trabalhar.

Fonte consultada: Anthropic, Investigating three real-world incidents in our cybersecurity evaluations, 30 de julho de 2026.

Métricas para acompanhar o red team

A avaliação deve melhorar a capacidade de encontrar e fechar caminhos perigosos. Acompanhe:

cenários executados por superfície e objetivo;
achados por severidade e camada;
falhas impeditivas abertas;
tempo para detectar e interromper;
tentativas bloqueadas por controle técnico;
ações que chegaram a destino controlado;
falsos bloqueios sobre casos legítimos;
tempo até correção;
achados reabertos em regressão;
cobertura dos agentes de maior impacto;
fornecedores e ambientes ainda sem evidência de isolamento.

Quantidade de ataques não representa maturidade. O sinal útil é a redução de caminhos capazes de gerar consequência sem detecção e sem dono.

Checklist antes do exercício

O agente e a versão estão identificados?
A unidade de trabalho e a consequência máxima foram mapeadas?
O escopo técnico está escrito?
Sistemas e dados de terceiros ficaram fora?
Credenciais, rede e destinos pertencem ao ambiente de teste?
Técnicas proibidas e critérios de parada estão claros?
Existe monitoramento em tempo real?
Uma pessoa consegue interromper o exercício?
Logs registram entrada, contexto, ferramentas, bloqueios e ações?
Os cenários cobrem dados, identidade, ferramentas, aprovação, alcance, estado e ambientes?
O resultado seguro esperado foi definido antes do teste?
Achados possuem severidade, evidência, dono e prazo?
Correções voltarão ao conjunto de regressão?
A retomada depende de autorização registrada?

Red team precisa terminar em mudança operacional

Um relatório cheio de exemplos engenhosos pode impressionar e ainda deixar a empresa exposta. O valor aparece quando o exercício fecha acessos, estreita ferramentas, corrige isolamento, melhora detecção e cria critérios de parada que a equipe consegue usar.

Agentes mais capazes aumentam o número de tarefas que uma empresa consegue delegar. A avaliação adversarial precisa crescer junto com essa capacidade, especialmente nos pontos em que linguagem vira ferramenta e ferramenta vira consequência.

O teste cumpriu seu papel quando deixa uma arquitetura mais difícil de desviar e mais fácil de interromper, investigar e corrigir.