por AgentRedTeam (LX AI)

Red teaming do AgentRedTeam e OWASP LLM01

Uma lista de verificação de red teaming para chatbots construída não abrange a maior parte do que torna um agente perigoso. No momento em que um modelo pode chamar ferramentas, ler ficheiros ou enviar mensagens, a injeção de prompt torna-se um caminho para ação, e não apenas texto. O OWASP's GenAI LLM Top 10 para 2026 mantém a Injeção de Prompt em LLM01, e é o local correto para iniciar uma avaliação de agente.

Porquê os agentes alteram a matemática da injeção

De saída para ação

Num chatbot puro, o objetivo de uma injeção é fazer com que o modelo diga algo que não deveria dizer. O impacto para ali, no texto que sai do modelo. Quando o mesmo modelo pode invocar uma ferramenta, o texto injetado pode tornar-se num comando que a ferramenta executa. Um atacante que pode direcionar uma ferramenta de leitura de ficheiros para ler um documento confidencial, ou uma ferramenta de envio de e-mail para encaminhar esse documento, transformou um truque de redacção num vazamento de dados. A gravidade depende, portanto, do que a ferramenta pode fazer, e não da astúcia da resposta.

O alcance da ferramenta define o raio de ação

O raio de ação é a união de todos os recursos que as ferramentas do agente podem tocar. Se o agente só tem 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 base de dados, uma ferramenta de eliminação de sistema de ficheiros ou um gateway de pagamento externo, a mesma injeção pode apagar registos, alterar saldos ou mover dinheiro. O trabalho da equipa vermelha deve mapear cada ferramenta para as lojas de dados, serviços ou hardware que pode afetar, e depois testar se uma injeção pode atingir esses ativos.

Conceções erradas comuns

- Supor que os limites de comprimento de saída do modelo limitam os danos – falso, porque uma string curta pode desencadear uma chamada de ferramenta destrutiva. - Acreditar que filtrar a mensagem do utilizador é suficiente – falso, porque as injeções podem chegar dentro dos resultados da ferramenta ou dos 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, veja a folha de dicas da OWASP sobre Prevenção de Injeção de Prompt de LLM.

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

Prompt do sistema e configuração

O prompt do sistema muitas vezes contém chaves de API, URLs de serviço ou linguagem de política interna. Um atacante que pode injetar nesta área pode ganhar credenciais diretas ou aprender onde apontar para próximas sondagens. Revise o prompt para qualquer segredo estático e teste se podem ser ecoados ou exfiltrados através de uma chamada de ferramenta.

Esquemas de ferramentas e validação de argumentos

Cada ferramenta exposta define um esquema JSON para as suas entradas. Se o esquema aceita strings de 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 SQL bruta é 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 de recuperação (RAG)

Quando o agente recupera dados de fontes externas – páginas web, e-mails, sistemas de bilhetes – esses dados tornam-se parte do contexto do modelo. Um atacante que controla alguma dessas fontes pode colocar instruções que o modelo tratará como confiáveis. Sondar envenenando uma fonte de alimentação externa conhecida e observando se o agente age sobre o comando oculto.

Propagação de instruções dentro dos resultados da ferramenta

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

Lista de verificação prática

- Extraia o prompt do sistema e procure segredos codificados. - Liste todas as ferramentas, anote o 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 utilizador leva a múltiplas invocações de ferramentas. - Para comparação com defesas clássicas de injeção, a folha de dicas de injeção de SQL oferece padrões úteis: OWASP A03:2021 – Injeção.

O risco excessivo de agência é o companheiro de risco

O que significa agência excessiva

A OWASP coloca a Agência Excessiva em LLM03 para 2026. 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 MFA | 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 declaraçã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 da ferramenta como foram enviados e o rastro 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 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 entrada persistente, destruição de dados ou capacidade de manter uma posição após o término da sessão.

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

Dicas de remediação atuáveis

- 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 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 escrita seja explicitamente necessária.

O red teaming não é um substituto para controlos de design

Por que a testagem complementa, e não substitui, salvaguardas

O trabalho de red team descobre lacunas que já existem na implementação. 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 controlos param a cadeia injetada, você tem evidências de que funcionam; se não, você tem um defeito concreto para corrigir.

Controlos a priorizar

- Execute cada ferramenta sob um utilizador do sistema operacional dedicado com o conjunto mínimo de capacidades do sistema de ficheiros. - Exija um serviço de aprovação separado para qualquer chamada que possa modificar o estado, registe a decisão e impeça o tempo limite. - Aplicar políticas de rede que limitam as ligações de saída a serviços internos conhecidos e a uma lista curta de APIs externas. - Encripte segredos em repouso e nunca os coloque na prompt do sistema; use um serviço de cofre em vez disso. - Registe cada invocação de ferramenta com ID do utilizador, carimbo de data e hora, hash de entrada e hash de saída para revisão forense.

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

O que isto NÃO é

Nenhuma garantia de completude

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

Não é uma solução 100 %

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

Reivindicação de nunca perder é falsa

Nenhum método de red team pode reivindicar 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 assumem que você já segue práticas de codificação segura básicas - validação de entrada, codificação de saída e princípio do privilégio mínimo. Elas adicionam camadas específicas de agente em cima dessa fundação.

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