O OWASP LLM Top 10 virou a referência padrão para segurança de aplicações com IA — e, como todo Top 10, virou também um checklist que times preenchem sem testar. "Cobrimos as dez categorias" costuma significar que alguém leu as dez descrições.
Este guia é o oposto: o que cada categoria significa quando você está com as mãos no sistema, que evidência prova a exploração, e onde a severidade real se concentra.
O ponto de partida: mapear antes de testar
Nenhuma das dez categorias pode ser avaliada sem um mapa da superfície. Antes do primeiro payload, documente:
- Endpoints — quem chama o modelo, com que autenticação, com que limites de taxa.
- System prompts — o texto completo, incluindo instruções injetadas dinamicamente.
- Ferramentas e plugins — cada função que o modelo pode invocar e o que ela pode fazer.
- Pipeline RAG — de onde vêm os documentos, quem pode escrever neles, como são indexados.
- Fluxo de dados — o que entra no contexto, o que sai, o que é persistido.
Sem esse mapa, um teste de LLM é uma sessão de tentativa e erro contra uma caixa preta. Com ele, cada categoria abaixo tem alvos concretos.
LLM01 — Prompt Injection
O que é. Entradas manipuladas que alteram o comportamento do modelo, contornam guardrails ou disparam ações não intencionadas.
O que testar. Separe direto de indireto. Injection direto (o usuário é o atacante) é o caso fácil e o menos interessante. Injection indireto — a instrução chega dentro de um documento recuperado, de um e-mail processado, de uma página que o agente navegou — é onde os incidentes reais acontecem, porque não exige acesso do atacante ao sistema.
Evidência que vale. Não é o modelo dizendo algo que não deveria. É o modelo executando algo que não deveria: uma chamada de ferramenta não autorizada, um dado que atravessou um limite de tenant, uma ação de escrita disparada por texto de terceiro.
LLM02 — Tratamento inseguro de saída
O que é. A saída do modelo é consumida a jusante sem validação — e vira XSS, SSRF, injeção de comando ou de SQL.
O que testar. Siga a saída. Ela é renderizada em HTML? Passada a um shell? Interpolada em uma query? Usada como URL? Cada um desses destinos é uma vulnerabilidade tradicional com um novo ponto de entrada.
Por que importa. Esta é a categoria que converte um problema de IA em RCE. Trate a saída do modelo exatamente como você trata input de usuário não confiável — porque é isso que ela é.
LLM03 — Envenenamento de dados de treinamento
O que é. Manipulação de dados de pré-treino, fine-tuning ou embedding para introduzir vieses ou backdoors.
O que testar. Em avaliações de aplicação, o alvo prático raramente é o pré-treino — é o corpus de embeddings. Quem pode escrever no vector store? Um ticket de suporte enviado por um cliente acaba indexado? Se sim, o controle de acesso de escrita ao índice é um controle de segurança de primeira ordem.
LLM04 — Negação de serviço do modelo
O que é. Operações que degradam desempenho, inflam custo ou derrubam o serviço.
O que testar. Esgotamento de janela de contexto, prompts recursivos, expansão descontrolada de chamadas de ferramenta. Meça o custo, não só a latência: em arquiteturas com agentes, um único input pode disparar uma cascata de chamadas pagas.
LLM05 — Supply chain
O que é. Modelos pré-treinados, datasets, plugins e extensões de terceiros que carregam vulnerabilidades.
O que testar. Proveniência dos pesos, verificação de integridade, formato de serialização, permissões dos plugins instalados. A pergunta de auditoria é direta: se o repositório de origem do modelo fosse comprometido hoje, você saberia?
LLM06 — Divulgação de informações sensíveis
O que é. Exposição de PII, segredos ou system prompts via respostas ou canais laterais.
O que testar. Vazamento de system prompt (subestimado — é o mapa das ferramentas e limites), vazamento entre tenants em contexto compartilhado, PII recuperada de documentos que o usuário não deveria alcançar. Verifique o controle de acesso na recuperação, não só na interface.
LLM07 — Design inseguro de plugins
O que é. Integrações de ferramentas que permitem ações não autorizadas ou execução de código.
O que testar. Cada plugin como uma API sem autenticação, porque na prática é isso: quem autoriza a chamada é o modelo, e o modelo é influenciável por texto. Parâmetros validados? Escopo verificado por usuário ou herdado do serviço? Um plugin que executa com credencial de serviço transforma qualquer injection em escalação.
LLM08 — Agência excessiva
O que é. Permissões ou autonomia além do necessário — exploráveis para ações arbitrárias.
O que testar. Enumere as capacidades reais e compare com o caso de uso declarado. Um assistente de leitura com permissão de escrita, um agente de triagem com acesso a produção, uma integração com token de administrador porque "era mais simples".
Por que importa. Esta categoria é o multiplicador de severidade de todas as outras. Reduzir agência é a mitigação de melhor custo-benefício em segurança de IA — e não depende de o modelo resistir a nada.
LLM09 — Dependência excessiva
O que é. Confiar na saída do modelo sem validação — decisões erradas, código vulnerável, desinformação.
O que testar. É tanto controle de processo quanto técnico. Existe revisão humana onde a decisão tem consequência? Código gerado passa pelo mesmo gate de segurança que código escrito à mão? Em fluxos financeiros ou clínicos, o modelo decide ou recomenda?
LLM10 — Roubo de modelo
O que é. Extração, replicação ou exfiltração não autorizada de modelos e pesos proprietários.
O que testar. Extração por consulta em massa, acesso direto ao artefato de pesos, exposição do endpoint de model serving. Para a maioria das empresas que consomem modelos de terceiros, esta é a categoria de menor prioridade — o que não significa que os controles de armazenamento e acesso possam ser ignorados.
Onde a severidade realmente se concentra
Nas avaliações que conduzimos, os achados críticos se agrupam em três categorias: LLM02 (tratamento de saída), LLM07 (design de plugins) e LLM08 (agência excessiva). As três compartilham uma característica: não são falhas do modelo. São falhas da aplicação ao redor do modelo.
Isso tem uma consequência prática desconfortável. Trocar o modelo por um mais alinhado não resolve nenhuma delas. O que resolve é arquitetura — validação de saída, escopo de autorização por usuário, princípio do menor privilégio nas ferramentas.
LLM01 continua sendo a categoria com maior volume de achados. Mas volume não é severidade: prompt injection isolado, em um sistema sem agência e com saída validada, é um incômodo. Prompt injection em um agente com permissão de escrita e ferramentas com credencial de serviço é comprometimento.
Do relatório à decisão
Um teste OWASP LLM Top 10 que entrega dez seções e uma lista de achados não resolve o problema do CISO, que é ordem de correção. O que fecha essa lacuna:
- Evidência reproduzível por achado — o payload, a resposta, o efeito observável. Se não reproduz, não é achado.
- Classificação por impacto ao negócio, não por categoria OWASP. LLM08 em um chatbot público e LLM08 em um agente com acesso ao ERP não são o mesmo risco.
- Ligação com a kill chain. Um achado que só permite o estágio 1 é diferente de um que encadeia até exfiltração.
O Top 10 é um bom mapa de cobertura. Ele não é, sozinho, um programa de segurança.
Nosso pentest de IA/LLM cobre as dez categorias com PoC reproduzível e classificação AI-VRM. Veja também o Promptware Kill Chain para o modelo de encadeamento de achados.