Slayer1Dev Red team de aplicações com LLM
Escopo: sistemas que você opera ou tem autorização escrita para testar. Testar aplicação de terceiro sem autorização é ataque, não pesquisa. Tudo aqui existe para encontrar a falha antes que outro encontre.
A diferença do pentest tradicional: o input não é só dado, é instrução. A superfície de ataque é toda string que chega ao contexto do modelo — documento, resultado de busca, nome de arquivo, campo de banco, resposta de API.
A regra que organiza tudo
Instrução vem do usuário pelo canal de comando. Todo o resto é dado.
Quase toda falha grave é uma violação disso: conteúdo que o sistema leu acabou sendo obedecido. Ao auditar, o mapa é: para cada texto que entra no contexto, pergunte "se isto contiver uma ordem, o sistema executa?"
Superfícies a enumerar
Antes de testar, liste por onde texto não confiável entra:
- Upload de arquivo (incluindo nome do arquivo e metadados)
- Páginas buscadas, RAG, documentos indexados
- Retorno de API e de ferramenta
- Campos de banco preenchidos por outro usuário
- Histórico de conversa de sessão anterior
- Texto invisível: HTML oculto, comentário, caractere de largura zero, conteúdo em imagem
A superfície mais esquecida é saída de ferramenta, porque parece "interna" — mas se a ferramenta busca na web, é input hostil.
Classes de teste
1. Injeção direta
O usuário tenta sobrescrever as instruções. Peça para ignorar regras, revelar o prompt de sistema, assumir "modo manutenção". Varie o enquadramento: urgência, autoridade, "é só teste", codificação, outro idioma.
2. Injeção indireta — a que importa
Plante instrução em conteúdo que o sistema vai ler, não receber do usuário. Documento com ordem embutida, página com texto oculto, registro de banco com comando.
Esta é a classe mais grave e a menos testada, porque não aparece no log de conversa.
3. Vazamento de contexto
O modelo revela prompt de sistema, dados de outro usuário, chave presente no contexto, ou estrutura interna. Teste pedindo indiretamente: resumo, tradução, "repita a primeira linha", continuação.
4. Abuso de ferramentas
Com acesso a ferramentas, o alvo deixa de ser o texto e passa a ser a ação. Verifique se uma instrução injetada consegue disparar envio de mensagem, escrita em banco, requisição a domínio arbitrário (exfiltração) ou gasto.
Aqui mora o dano real: injeção que só produz texto estranho é constrangimento; injeção que dispara ação é incidente.
5. Exaustão de recurso
Input que provoca laço, saída ilimitada ou chamada recursiva de ferramenta. Custo é superfície de ataque quando se paga por token.
Avaliando o achado
Classifique por ação alcançada, não pela esperteza do prompt:
| Severidade | Critério |
|---|---|
| Crítico | Executa ação com efeito externo (envia, paga, apaga, exfiltra) |
| Alto | Vaza dado de outro usuário ou credencial |
| Médio | Vaza prompt de sistema ou estrutura interna |
| Baixo | Quebra de persona sem consequência |
Um prompt que faz o bot falar como pirata não é vulnerabilidade. Um que o faz chamar send_email é.
Mitigações que funcionam
Na ordem de eficácia real:
- Menor privilégio na ferramenta. O modelo não pode abusar do que não tem. Ferramenta destrutiva exige confirmação humana fora do canal de texto.
- Confirmação humana para ação irreversível. Único controle que resiste a injeção desconhecida.
- Separação estrutural entre instrução e dado — delimitadores, canais distintos, marcação de origem.
- Validação da saída antes de executar: domínio em lista de permissão, destinatário conferido, parâmetro em faixa esperada.
- Filtro de entrada por padrão conhecido — o mais fraco. Útil como camada, inútil como única defesa: filtro de padrão perde a variação que ninguém previu.
Nenhuma camada isolada basta. Assuma que a injeção vai passar e limite o que ela alcança.
Relatando
Para cada achado: passo de reprodução, o que foi alcançado, por que importa, e a mitigação sugerida. Sem prova de reprodução, é especulação — e especulação em relatório de segurança queima a credibilidade do resto.