por AgentRedTeam (LX AI)

Equipe de teste de ataque do AgentRedTeam e OWASP LLM01

Uma lista de verificação de teste de ataque para chatbots deixa de lado a maior parte do que torna um agente perigoso. No momento em que um modelo pode chamar ferramentas, ler arquivos ou enviar mensagens, a injeção de prompt se torna um caminho para a ação, e não apenas para texto. A lista GenAI LLM Top 10 da OWASP para 2026 mantém a Injeção de Prompt em LLM01, e é o lugar certo para iniciar uma avaliação de agente.

Por que os agentes alteram a matemática da injeção

De saída para ação

Em um chatbot puro, o objetivo de uma injeção é fazer com que o modelo diga algo que não deveria dizer. O impacto para por texto que deixa o modelo. Quando o mesmo modelo pode invocar uma ferramenta, o texto injetado pode se tornar um comando que a ferramenta executa. Um atacante que pode direcionar uma ferramenta de leitura de arquivos para acessar um documento confidencial ou uma ferramenta de envio de e-mail para encaminhar esse documento, transformou um truque de redação em uma violação de dados. A gravidade, portanto, depende do que a ferramenta pode fazer, e não da astúcia da resposta.

O alcance da ferramenta define o raio de explosão

O raio de explosão é a união de todos os recursos que as ferramentas do agente podem acessar. Se o agente tem apenas uma API de leitura para um blog público, o pior caso é o vazamento de informações públicas. Se o agente pode chamar uma ferramenta de escrita de banco de dados, uma ferramenta de exclusão de sistema de arquivos ou um gateway de pagamento externo, a mesma injeção pode apagar registros, alterar saldos ou transferir dinheiro. O trabalho da equipe vermelha deve mapear cada ferramenta para os armazenamentos de dados, serviços ou hardware que ela pode afetar, e então testar se uma injeção pode atingir esses ativos.

Conceitos errados comuns

- Supor que o comprimento da saída do modelo limita o dano – falso, porque uma string curta pode acionar uma chamada de ferramenta destrutiva. - Acreditar que filtrar a mensagem do usuário é suficiente – falso, porque injeções podem chegar dentro dos resultados da ferramenta ou prompts do sistema. - Pensar que um modelo de baixo parâmetro é seguro – falso, quando esse modelo é combinado com um conjunto de ferramentas poderoso.

Para uma referência rápida sobre codificação defensiva, consulte a folha de dicas da OWASP sobre Prevenção de Injeção de Prompt de LLM.

Superfícies para investigar além da caixa de chat

Prompt e configuração do sistema

O prompt do sistema frequentemente contém chaves de API, URLs de serviço ou linguagem de política interna. Um atacante que possa injetar nessa área pode obter credenciais diretas ou aprender onde direcionar mais investigações. Revise o prompt para quaisquer segredos estáticos e teste se eles podem ser ecoados ou exfiltrados por meio de uma chamada de ferramenta.

Esquemas de ferramentas e validação de argumentos

Cada ferramenta exposta define um esquema JSON para suas entradas. Se o esquema aceita strings em forma livre sem validação estrita, um atacante pode incorporar comandos dentro dessas strings. Por exemplo, uma ferramenta "run_sql" que aceita uma string de consulta raw é vulnerável a injeção de SQL, a menos que a camada do agente sanitize ou parametrize a entrada. Verifique se o agente impõe limites de tipo, limites de comprimento ou listas de permissões em cada argumento.

Pipelines de geração aumentada por recuperação (RAG)

Quando o agente busca dados de fontes externas – páginas da web, emails, sistemas de tickets – esses dados se tornam parte do contexto do modelo. Um atacante que controla alguma dessas fontes pode colocar instruções que o modelo tratará como confiáveis posteriormente. Investigue envenenando uma fonte externa conhecida e observando se o agente age sobre o comando oculto.

Propagação de instruções dentro dos resultados das ferramentas

Alguns designs retornam a saída da ferramenta diretamente para a próxima chamada de modelo sem re-sanitizar. Se uma ferramenta retorna um pedaço de texto que inclui uma nova instrução, o modelo pode obedecê-la na etapa seguinte. Isso cria uma injeção de dois estágios, onde a primeira etapa é dados de aparência benigna e a segunda etapa é o comando malicioso. Teste cada caminho de saída da ferramenta para ver se o agente re-alimenta resultados brutos no gerador de prompts.

Lista de verificação prática

- Extraia o prompt do sistema e procure segredos codificados. - Liste cada ferramenta, anote seu esquema e tente passar tipos de dados inesperados. - Identifique todas as fontes de dados externas usadas para RAG e injete marcadores benignos para verificar o alcance. - Capture as saídas das ferramentas e alimente-as novamente como novas entradas para ver se o agente as trata como comandos. - Documente qualquer cadeia onde uma única mensagem do usuário leva a várias invocações de ferramentas.

Para comparação com defesas clássicas de injeção, o SQL injection cheat sheet oferece padrões úteis: OWASP A03:2021 – Injeção.

O excesso de agência é o risco companion

O que significa excesso de agência

A OWASP coloca Excessive Agency em LLM03 para 2026. Ela descreve agentes que podem realizar ações irreversíveis – enviar e-mail, excluir arquivos, executar código – sem uma etapa de aprovação separada. O risco cresce quando a autonomia do modelo supera as salvaguardas ao redor de suas ferramentas.

Áreas de foco da equipe vermelha

- Verifique se as ferramentas destrutivas exigem uma confirmação explícita de um humano ou de um serviço separado. - Tente encadear duas ou mais ferramentas juntas usando apenas saídas intermediárias geradas pelo modelo. - Veja se o agente pode elevar seus próprios privilégios, por exemplo, chamando uma ferramenta que atualiza sua própria chave de API. - Teste gatilhos baseados em tempo: é possível usar uma chamada de ferramenta atrasada para contornar um limite de taxa ou um tempo de sessão?

Matriz de risco ilustrativa

Categoria de ferramenta | Privilégio típico | Confirmação necessária | Abuso potencial se faltar Leitura de arquivo | Acesso somente leitura a pastas designadas | Nenhum (leitura é geralmente segura) | Exfiltração de logs, código-fonte, configuração Escrita de arquivo | Criar ou sobrescrever arquivos | Sim – aprovação do usuário ou solicitação assinada | Inserção de backdoors, corrupção de dados Escrita de banco de dados | INSERT/UPDATE/DELETE em tabelas | Sim – aprovação de transação ou autenticação de dois fatores | Perda de dados, fraude financeira, escalada de privilégios HTTP externo | Rede externa para domínios arbitrários | Sim – verificação de lista de permissões | Exfiltração de dados, sinalização C2, SSRF Execução de código | Shell ou interpretador arbitrário | Sim – sandbox isolado + aprovação | Comprometimento total do host, implantação de ransomware

A tabela mostra por que uma equipe vermelha deve verificar cada linha: se a coluna de confirmação estiver faltando, o agente pode mudar de benigno para prejudicial com uma única entrada envenenada.

O que um relatório de investigação deve conter

Campos essenciais

Um achado útil precisa de mais do que um booleano "passar/falhar". Registre a exata expressão do usuário que acionou a cadeia, a lista ordenada de ferramentas que o agente chamou e o efeito observável final (por exemplo, um arquivo escrito, uma solicitação de rede enviada, uma linha de banco de dados alterada). Inclua os argumentos brutos das ferramentas como foram enviados e o rastreamento de raciocínio interno do modelo, se o seu framework expõe isso.

Orientação de gravidade

- Baixo – vazamento de informações públicas ou alteração de estado reversível. - Médio – acesso a dados internos que não são regulamentados, ou uma ação reversível que exige redefinição manual. - Alto – alteração de dados regulamentados, transação financeira ou execução de código arbitrário. - Crítico – porta de acesso persistente, destruição de dados ou capacidade de manter uma posição após o término da sessão.

Priorize a correção de achados de alta e crítica primeiro; itens de baixa gravidade podem ser abordados em um sprint de endurecimento posterior.

Dicas de remediação práticas

- Adicione validação de nível de esquema que rejeite strings contendo palavras-chave SQL ou metacaracteres de shell. - Envie ferramentas destrutivas em um microserviço que exija um token de aprovação assinado. - Implemente uma lista de permissões de saída para chamadas HTTP de saída e registre cada tentativa de conexão. - Sanitize as saídas das ferramentas antes que elas sejam reinsertadas no prompt do modelo – remova ou escape qualquer conteúdo que pareça uma instrução. - Use uma réplica somente leitura para qualquer ferramenta de consulta de banco de dados, a menos que uma gravação seja explicitamente necessária.

Red teaming não é um substituto para controles de design

Por que testes complementam, não substituem, salvaguardas

O trabalho de red team descobre lacunas que já existem na implementação. Ele não cria as garantias que vêm do design de ferramentas de privilégio mínimo, portas de confirmação ou segmentação de rede. Trate cada teste como uma etapa de validação: se os controles param a cadeia injetada, você tem evidências de que eles funcionam; se não, você tem um defeito concreto para corrigir.

Controles a priorizar

- Execute cada ferramenta em um usuário do sistema operacional dedicado com o conjunto mínimo de capacidades de sistema de arquivos. - Exija um serviço de aprovação separado para qualquer chamada que possa modificar o estado, registre a decisão e aplique timeout. - Aplique políticas de rede que limitem as conexões de saída para serviços internos conhecidos e uma lista curta de APIs externas. - Criptografe segredos em repouso e nunca os coloque na prompt do sistema; use um serviço de cofre instead. - Registre cada invocação de ferramenta com ID de usuário, carimbo de data/hora, hash de entrada e hash de saída para revisão forense.

Quando esses controles estão em vigor, as descobertas da equipe vermelha mudam de “encontramos uma maneira de quebrá-lo” para “tentamos X e os controles bloquearam”, o que é um sinal mais forte de maturidade de segurança.

O que isso não é

Nenhuma garantia de completude

Este guia não promete que seguir os passos irá capturar todas as possíveis injeções. Técnicas novas, vulnerabilidades de ferramentas de zero dia ou recursos de agente não divulgados podem evadir as verificações descritas aqui.

Não é uma solução 100 %

A aplicação das mitigações reduz o risco, mas não o elimina. A defesa em profundidade requer monitoramento contínuo, revisões regulares da cadeia de ferramentas e atualizações à medida que novas versões da OWASP são lançadas.

Alegação de nunca perder é falsa

Nenhum método de equipe vermelha (red-team) pode alegar nunca perder uma falha. O objetivo é aumentar o custo para um atacante e tornar a exploração bem-sucedida notável e rastreável.

Não é um substituto para codificação segura

As recomendações pressupõem que você já segue práticas básicas de codificação segura – validação de entrada, codificação de saída e princípio do menor privilégio. Elas adicionam camadas específicas de agente sobre essa base.

Referências

- https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html - https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - https://genai.owasp.org/llmrisk/llm01-prompt-injection - https://owasp.org/Top10/2021/A03_2021-Injection