O OWASP LLM Top 10 deixa a categoria clara mas raramente traz o exemplo que faz o CTO entender. Este guia dá um caso concreto para cada uma das 10 categorias, com o padrão de detecção e a correção mínima.
O OWASP LLM Top 10 é a categoria emergente mais importante em 2026 para produtos com IA generativa. Este guia dispensa a teoria e vai direto ao caso concreto de cada categoria.
LLM01: Prompt Injection
Caso real: app de suporte com LLM que interpretou input do cliente como comando de admin.
Detecção: teste com input contendo "Ignore instruções anteriores e...". Se o LLM obedecer, você está vulnerável.
Correção: system prompt separado do input; delimitadores explícitos; nunca autorizar ação transacional via LLM.
LLM02: Insecure Output Handling
Caso real: LLM retornou HTML em <script>alert(1)</script> que app renderizou sem sanitizar. XSS armazenado por prompt.
Correção: trate output de LLM como input de usuário. Sanitize com DOMPurify antes de renderizar.
LLM03: Training Data Poisoning
Caso real: fine-tune de modelo com dados de fóruns que continham prompts maliciosos. Modelo aprendeu comportamento pornográfico e vazou em produção.
Correção: auditoria manual do dataset de fine-tune; nunca treine em conteúdo user-generated sem curadoria.
LLM04: Model Denial of Service
Caso real: atacante enviou prompts de 100k tokens para inflar custos. R$ 30k de conta OpenAI em 6 horas.
Correção: limite de tokens por request por usuário; rate limit; billing alert em USD.
LLM05: Supply Chain Vulnerabilities
Caso real: empresa usava embedding model open-source de repo abandonado. Repo foi comprometido, versão nova incluía backdoor.
Correção: pin versão + verificação de checksum. Prefira modelos de fornecedores conhecidos.
LLM06: Sensitive Information Disclosure
Caso real: LLM com RAG multi-tenant vazou contratos de cliente A em resposta a cliente B.
Correção: filtro de tenant no retrieval, não só no prompt. Nunca confie no LLM para respeitar boundaries.
LLM07: Insecure Plugin Design
Caso real: plugin de "buscar por URL" foi usado como SSRF para acessar metadata AWS.
Correção: plugins usam SafeHttpClient centralizado, mesma proteção de SSRF do resto do backend.
LLM08: Excessive Agency
Caso real: agente de IA tinha permissão de "enviar e-mail". Prompt injection resultou em envio de spam de e-mail corporativo.
Correção: permissões mínimas para o agente. Ação sensível exige confirmação humana.
LLM09: Overreliance
Caso real: dev copiou código gerado por LLM que continha função authenticate() fake que sempre retornava true. Foi para produção sem revisão.
Correção: revisão obrigatória de código IA. SAST focado em anti-padrões.
LLM10: Model Theft
Caso real: API pública de LLM proprietário. Atacante extraiu pesos aproximados via 200k queries.
Correção: monitorar padrões de query; rate limit por conta; verificação de propósito para acesso a modelos únicos.
Como usar essa lista
Para cada categoria, faça 3 perguntas ao seu produto:
- Onde essa categoria pode nascer no meu app?
- Que teste eu tenho no CI para detectar?
- Que log/alerta captura quando alguém tenta?
Se as 3 respostas não existem para uma categoria, você tem trabalho ali.
TL;DR
- LLM01, 06, 07, 08 são os que mais aparecem em produção.
- Prompt injection é o vetor comum de 6 das 10.
- Isolar autorização do LLM resolve metade.
- Sanitizar output resolve mais um quarto.
A Varredura testa LLM01, 02, 06, 07 automaticamente em endpoints de IA. Rodar agora.
Sua app em produção passa por essa análise?
Rode uma varredura autônoma em ~60 segundos. Sem cadastro.