# LLM Redteam

> Testa a robustez de aplicações que usam LLM contra injeção de prompt, vazamento de contexto e abuso de ferramentas, seguindo o OWASP Top 10 para LLM. Use ao revisar a segurança de um agente, chatbot ou pipeline com IA que você opera ou tem autorização para testar.

- Skill: `slayer1dev/llm-redteam` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slayer1dev/llm-redteam`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slayer1dev/llm-redteam/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: Slayer1Dev (https://skillmd.com/u/slayer1dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/slayer1dev/llm-redteam

---


# 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:

1. **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.
2. **Confirmação humana para ação irreversível.** Único controle que resiste a injeção desconhecida.
3. **Separação estrutural** entre instrução e dado — delimitadores, canais distintos, marcação de origem.
4. **Validação da saída** antes de executar: domínio em lista de permissão, destinatário conferido, parâmetro em faixa esperada.
5. 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.