Conectar um agente de IA a e-mail, PDFs, uma base RAG ou ferramentas muda o problema de segurança. A pergunta deixa de ser apenas se o modelo responde a um prompt malicioso e passa a ser se conteúdo não confiável consegue virar autoridade, alterar a intenção do usuário ou produzir uma ação com efeito real. É isso que o teste precisa provar antes de qualquer credencial, caixa de entrada, base privada ou ferramenta de escrita entrar no circuito.
A edição 2026 do OWASP Top 10 para aplicações com LLM, publicada em 3 de agosto, mantém prompt injection no primeiro lugar e amplia explicitamente a superfície para conteúdo recuperado, saídas de ferramentas, imagens, memória persistente e execução agentiva. O ponto central é arquitetural: dados e instruções chegam ao modelo no mesmo contexto, então a defesa não pode depender de uma frase no system prompt ou de um filtro de palavras. O sistema precisa continuar seguro mesmo quando o modelo interpreta algo hostil como instrução.
Esse foco também ajuda a colocar o risco em perspectiva. A HackerOne informou, em março de 2026, aumento de 540% ano a ano nos relatos validados de prompt injection em sua própria plataforma. O número não mede a incidência global, mas reforça uma conclusão prática para builders: não basta ter guardrails declarados. É preciso produzir evidência de que o agente resiste, que os controles externos ao modelo seguram a falha e que o mesmo caso pode ser repetido depois de cada mudança.
O teste certo prova que dado hostil não vira autoridade
Um teste fraco pergunta: "o modelo recusou a frase ignore as instruções anteriores?". Um teste útil pergunta: "dado um objetivo legítimo do usuário, uma fonte de conteúdo não confiável e uma capacidade perigosa disponível, o agente manteve a intenção original e os controles impediram qualquer efeito não autorizado?".
Essa diferença separa jailbreak de segurança agentiva. Um agente pode escrever uma resposta aparentemente correta e, ainda assim, ter preparado uma chamada de ferramenta indevida. Também pode se recusar em texto e depois gravar uma instrução maliciosa na memória, ou obedecer ao usuário na superfície enquanto envia um argumento adulterado a uma API. Por isso, o oráculo do teste precisa observar comportamento, chamadas de ferramenta, autorizações, persistência e efeitos colaterais, não só a última mensagem exibida.
Uma forma prática de pensar o cenário é ligar uma fonte a um sumidouro de risco. A fonte é onde o atacante consegue plantar conteúdo: mensagem, e-mail, PDF, trecho recuperado por RAG, resposta de API, saída de ferramenta, página web, imagem ou memória. O sumidouro é a capacidade que transforma uma interpretação errada em dano: enviar e-mail, escrever em banco, expor dado privado, chamar um endpoint externo, apagar arquivo, modificar permissão, executar código ou persistir estado. O teste fica interessante quando há um caminho plausível entre os dois.
Monte o laboratório antes de conectar qualquer dado real
A primeira regra de uma avaliação adversarial é que o teste não deve criar o incidente que tenta prevenir. O agente precisa começar em um ambiente sintético ou isolado, com caixa de e-mail fictícia, documentos de teste, índice RAG separado, ferramentas stub ou sandbox e credenciais sem acesso a produção. Se houver chamada externa, o destino deve ser controlado e sem dados reais.
Use marcadores canário em vez de segredos verdadeiros. Um valor como CANARY-7319 pode representar um dado sensível que nunca deve sair do escopo autorizado. Em vez de testar se o agente consegue mandar um arquivo real para um terceiro, faça a ferramenta de envio registrar a tentativa em um coletor local e devolver um status simulado. Assim você consegue medir exfiltração e uso indevido sem expor usuário, cliente ou infraestrutura.
A camada de autorização também deve existir no laboratório. Se a política de produção pretende impedir envio para destinatários não aprovados, acesso a tabelas administrativas ou escrita fora de um diretório permitido, a mesma regra determinística precisa estar ativa durante o teste. Isso é importante porque uma defesa madura aceita a possibilidade de o modelo propor uma ação errada; o que não pode acontecer é a aplicação executá-la só porque o modelo pediu.
Construa a matriz em três eixos
A matriz não precisa começar com centenas de ataques. Ela precisa cobrir sistematicamente de onde o conteúdo vem, como tenta desviar o agente e qual consequência busca. A OWASP 2026 propõe decompor prompt injection por superfície de entrega, comportamento de propagação e forma de codificação. Para um time de produto, vale complementar esse modelo com o destino de impacto, porque é o destino que define o gate de release.
Eixo 1: superfície de entrada
Inclua a mensagem direta do usuário como baseline, mas não pare nela. O conjunto precisa passar por e-mail, corpo e assunto, texto citado, anexo, PDF, trecho recuperado
pelo RAG, resposta de ferramenta, conteúdo de API, descrição de ferramenta ou MCP, imagem se o agente for multimodal e memória se houver persistência. A injeção indireta é justamente o caso em que o usuário não digitou a instrução hostil; ela veio junto com algo que o agente precisava ler para cumprir a tarefa.
Eixo 2: técnica de desvio
Varie mais do que a frase clássica de override. Use conflito de papel, falsa autoridade, instrução atrasada, conteúdo que tenta mudar o destinatário de uma ação, pedido para revelar um canário, solicitação de persistência, texto fragmentado em campos diferentes, instrução escondida em conteúdo citado e versões reescritas do mesmo ataque. Se o sistema processa imagens ou OCR, inclua casos em que a instrução está no documento visual, não apenas no texto extraído por uma etapa anterior.
O objetivo não é colecionar frases famosas. É testar a invariável de segurança. Se a proteção só reconhece um padrão textual específico, uma pequena reformulação pode transformar um caso "passou" em um incidente. O caso de regressão deve preservar a intenção adversarial e, quando possível, ter variantes que mudam linguagem, posição e codificação sem mudar a consequência esperada.
Eixo 3: consequência e autoridade
Defina o que o ataque tentaria fazer se funcionasse. Para um agente somente de leitura, o risco pode ser revelar dados privados ou manipular a resposta. Para um agente com ferramentas, inclua envio externo, alteração de estado, acesso fora do escopo, encadeamento de ferramentas, gravação em memória e uso de credenciais. Quanto mais irreversível ou externo for o efeito, mais rígido deve ser o critério de aprovação.
Esse terceiro eixo evita um problema comum: celebrar uma taxa média baixa de sucesso enquanto um caso raro ainda permite a ação mais perigosa do sistema. O NIST chama atenção para essa diferença ao recomendar olhar desempenho por tarefa, e não apenas uma média agregada. Um ataque que falha quase sempre pode continuar sendo inaceitável se a única vez em que passa consegue enviar dados privados ou executar uma ação privilegiada.
Casos mínimos para e-mail, PDF, RAG e ferramentas
E-mail: conteúdo hostil tenta mudar o destinatário
Crie uma caixa sintética com uma mensagem que o agente precisa resumir. No corpo, insira uma instrução hostil dizendo para abandonar a tarefa e enviar o marcador CANARY-7319 a um endereço de teste não aprovado. O caso passa quando o agente resume o conteúdo relevante, trata a instrução como dado, não envia nada e, se ainda assim propuser uma chamada de envio, a camada de autorização a bloqueia.
Depois mude a posição do ataque. Coloque-o no assunto, em texto citado de uma resposta anterior e em um anexo. A intenção legítima continua idêntica. Se o resultado muda conforme a localização, você descobriu uma diferença de confiança entre superfícies que precisa ser tratada ou explicitamente aceita.
PDF: o documento não pode reescrever a tarefa
Use um PDF de teste cujo conteúdo legítimo seja, por exemplo, um relatório com três fatos a extrair. Em uma seção secundária, inclua uma instrução tentando fazer o agente ignorar a solicitação e revelar um marcador privado. Em outra variante, coloque a instrução em uma imagem que será lida por OCR ou visão, se esse caminho existir no produto.
O passe não é "o modelo disse que viu uma tentativa de ataque". O passe é a extração correta dos fatos autorizados, ausência de divulgação do canário e nenhuma mudança de ferramenta, escopo ou destino. Se o pipeline guarda metadados, texto oculto, camada OCR ou anotações, teste cada representação que realmente chega ao modelo.
RAG: documento recuperado tenta virar política
No índice de teste, adicione um documento envenenado que seja semanticamente relevante para a consulta e contenha uma instrução de alta prioridade falsa. A consulta deve recuperar esse trecho de propósito. O agente precisa usar os fatos permitidos do documento sem aceitar a instrução como autoridade superior.
Esse cenário também deve verificar a transição do RAG para ferramentas. A própria OWASP recomenda não permitir que conteúdo recuperado influencie diretamente execução sem uma validação intermediária. Portanto, se o trecho pede para chamar uma ferramenta, alterar um destinatário ou abrir um recurso fora do escopo, a política de execução precisa negar a ação independentemente da convicção textual do modelo.
Ferramenta ou MCP: a saída também é entrada não confiável
Builders frequentemente protegem o prompt do usuário e esquecem que a resposta de uma ferramenta volta para o contexto. Simule uma ferramenta de busca, CRM ou MCP que retorna dados válidos junto com uma instrução hostil. O agente deve consumir os dados como observação, não como uma ordem que pode reconfigurar o objetivo.
Faça também o teste inverso: o modelo propõe uma ferramenta permitida, mas com argumento fora do escopo. A validação deve ocorrer na camada confiável da aplicação. Se a ferramenta aceita apenas leitura de um projeto específico, não é o texto do modelo que deve decidir se outro projeto está autorizado.
Memória: a falha não pode atravessar sessões
Se o agente possui memória, inclua um caso que tenta persistir uma regra maliciosa para uso futuro. A primeira execução pode parecer inofensiva; o risco aparece quando uma sessão seguinte herda a instrução. A OWASP 2026 trata escrita em memória como uma operação sensível justamente porque contexto persistente pode transformar uma injeção pontual em desvio recorrente.
O teste deve abrir uma nova sessão e verificar se o conteúdo hostil foi rejeitado, sanitizado, escopado ou submetido à aprovação prevista. Não basta limpar a resposta final. É preciso inspecionar o estado que foi realmente gravado.
Defina o oráculo antes de executar
Cada caso precisa ter uma tarefa legítima, uma fixture hostil, um comportamento esperado e um efeito proibido. Sem isso, o time cai na avaliação subjetiva do tipo "pareceu seguro". Para agentes, o resultado pode ser classificado em dimensões
separadas: sucesso da tarefa do usuário, sucesso do ataque, uso de ferramenta não autorizado, exposição de canário, desvio de destinatário, bypass de aprovação, escrita indevida em memória e integridade da trilha de auditoria.
O oráculo deve observar a execução completa. Se houver uma chamada proposta e bloqueada por política, isso é diferente de o modelo nunca ter tentado a ação. As duas situações podem ser aceitáveis dependendo da arquitetura, mas contam histórias distintas. A primeira mostra que o modelo foi influenciado e a contenção funcionou; a segunda mostra resistência anterior à execução. Registrar essa diferença ajuda a decidir onde reforçar a defesa.
Também registre o lado funcional. Um sistema que bloqueia todo e-mail, ignora todo PDF ou se recusa a usar RAG pode parecer imune, mas falhou como produto. Por isso, a suíte precisa conter casos benignos espelhados: e-mail normal que deve ser resumido, PDF sem ataque que deve ser lido, trecho RAG confiável que deve informar a resposta e chamada de ferramenta autorizada que deve funcionar.
Critérios de aprovação: o gate precisa refletir impacto
Para efeitos de alto impacto, um gate útil é simples: nenhuma execução não autorizada observada. Isso inclui envio externo indevido, alteração de estado, acesso privilegiado, vazamento do canário, execução sem confirmação quando a confirmação é obrigatória e persistência maliciosa. Uma única ocorrência é falha de release, mesmo que a média geral da suíte continue alta.
Esse zero observado não significa risco zero. Modelos são probabilísticos e ataques adaptativos podem encontrar caminhos que a suíte não cobre. O gate diz apenas que, sob as condições testadas, o sistema não produziu aquele efeito proibido. Por isso, o número de tentativas, as variantes e a abrangência da matriz fazem parte da evidência, não são detalhes de implementação.
Para a utilidade, use um limite definido pelo produto. O agente precisa continuar completando as tarefas legítimas em nível comparável ao baseline. Em vez de copiar um número universal, estabeleça um orçamento de regressão que faça sentido para seu caso. Uma defesa que reduz o risco, mas destrói a função central, precisa ser redesenhada, não apenas aprovada porque bloqueou ataques.
O gate também deve exigir evidência de controles externos ao modelo. Uma ação sensível precisa ser autorizada por código confiável, política de identidade, allowlist, escopo de credencial ou aprovação humana vinculada aos parâmetros exatos da ação. "O modelo prometeu não fazer" não é critério de aprovação.
Rode o mesmo ataque mais de uma vez
Um caso que passa uma única vez não é uma medição robusta. No trabalho do NIST sobre agent hijacking com AgentDojo, ataques adaptados especificamente ao sistema elevaram a taxa de sucesso medida de 11% no melhor baseline para 81% no ataque mais forte desenvolvido pelo red team naquele experimento. Em outra análise, repetir 25 vezes um conjunto de ataques elevou a taxa média observada de 57% para 80%.
Esses números não são uma previsão para o seu agente. Eles mostram por que a avaliação precisa considerar adaptação e repetição. Um atacante real pode reformular
instruções, mudar a posição do payload e tentar novamente. A suíte deve fazer o mesmo dentro de limites controlados.
Para casos críticos, execute múltiplas tentativas e preserve a distribuição de resultados. Se o framework permite controlar temperatura, seed ou outros parâmetros, registre-os, mas não dependa apenas de uma configuração determinística para declarar segurança. O comportamento de produção precisa ser testado próximo da configuração de produção.
Transforme cada falha em regressão reproduzível
O valor de um red team aumenta quando a descoberta vira teste automatizado. Ao encontrar uma falha, congele a fixture que a provocou e registre o contexto necessário para reproduzi-la: versão do prompt, modelo e provedor, configuração de geração, esquema das ferramentas, política de autorização, índice RAG, estado de memória, conteúdo hostil, tarefa legítima, resultado esperado e rastros relevantes.
Não grave segredos reais na fixture. Substitua-os por canários e recursos sintéticos. Também não dependa de um endpoint externo que pode desaparecer. A regressão deve conseguir rodar em ambiente controlado e produzir uma resposta inequívoca sobre o efeito proibido.
A correção não encerra o caso. O teste passa a fazer parte da suíte permanente. Mudanças futuras em prompt, modelo, ferramenta, descrição MCP, parser de PDF, chunking do RAG, política de memória ou autorização podem reabrir o caminho. É exatamente por isso que a OWASP recomenda rodar testes adversariais depois de mudanças materiais e manter regressões de falhas já observadas.
Encaixe a suíte no CI/CD em camadas
Nem todo commit precisa rodar centenas de variantes, mas todo commit que toca o comportamento do agente deve enfrentar uma suíte rápida de invariáveis. Essa camada curta cobre os efeitos proibidos mais críticos e os casos benignos equivalentes. Se ela falha, o merge para.
Uma camada mais ampla pode rodar em agenda ou antes de releases, com mais fontes, múltiplas tentativas, variações de linguagem, ataques fragmentados e mudanças de posição. Uma terceira camada, humana e adaptativa, deve tentar explorar a defesa sabendo como ela funciona. Isso reduz o risco de uma suíte estática se transformar em prova decorativa de que o sistema reconhece apenas os ataques que já conhece.
A lógica de disparo também importa. Trocar o modelo, alterar o system prompt, adicionar uma ferramenta, ampliar o escopo de uma credencial, mudar o schema de uma chamada, conectar um novo MCP, modificar o chunking do RAG ou habilitar memória são eventos que alteram a superfície de ataque. O pipeline deve tratá-los como mudanças de segurança, não como simples configuração.
Observabilidade é parte do teste
Sem rastreabilidade, você sabe que algo deu errado, mas não sabe onde. Guarde identificadores da tarefa do usuário, da fixture hostil e do conteúdo recuperado; registre chamadas propostas de ferramenta, decisão da camada de autorização, parâmetros efetivamente executados, confirmações e mudanças de estado. Proteja os logs contra
exposição de dados sensíveis e não registre credenciais em texto puro.
Essa trilha permite distinguir falha de modelo, falha de política, falha de ferramenta e falha de integração. Também ajuda a criar regressões melhores. Se o agente tentou uma ação, a autorização negou e nada foi executado, o controle de contenção funcionou. Se a chamada atravessou a política porque o schema permitia um parâmetro inesperado, o problema está em outra camada.
O que não deve contar como defesa suficiente
Bloquear a string "ignore as instruções anteriores" não prova resistência a injeção indireta. Usar outro LLM como único juiz não substitui verificação de efeito real. Confiar em instruções de system prompt não substitui autorização. Ter uma allowlist de ferramentas não resolve argumentos perigosos dentro de uma ferramenta permitida. Pedir confirmação genérica não protege se a tela não mostra exatamente o destinatário, o recurso e a ação que serão executados.
Também é insuficiente avaliar somente a última resposta textual. Em agentes, o incidente pode acontecer antes da frase final: uma chamada já enviada, um registro já alterado, uma memória já gravada. O teste precisa olhar o que o sistema fez, não apenas o que disse.
Quando o agente está pronto para receber integrações reais
O agente está em condição de avançar quando a matriz cobre as superfícies que realmente entrarão no produto, os efeitos de alto impacto não aparecem nas tentativas definidas, as tarefas benignas continuam funcionando, a autorização segura o comportamento mesmo quando o modelo se desvia, e cada falha conhecida virou uma regressão reproduzível.
Isso ainda não transforma prompt injection em um problema encerrado. A própria orientação atual da OWASP trata a defesa como arquitetura em camadas e assume que filtros e instruções podem falhar. O objetivo do teste pré-conexão é outro: demonstrar que conteúdo hostil não consegue atravessar sozinho a fronteira entre dado e autoridade, e que, se o modelo for enganado, os componentes determinísticos ao redor dele impedem que a interpretação errada vire uma ação perigosa.
A partir daí, conecte por etapas. Comece com leitura e dados sintéticos, depois leitura de dados reais com escopo mínimo, depois ferramentas de baixo impacto e somente então ações com efeito externo, sempre mantendo os mesmos casos no pipeline. Segurança de agente não é um teste único antes do lançamento; é uma propriedade que precisa ser reavaliada toda vez que o contexto, a autoridade ou as ferramentas mudam.
