OWASP Top 10 para Aplicações LLM

Definição

O OWASP Top 10 para aplicações LLM é uma lista mantida pela comunidade com as classes de vulnerabilidade mais críticas em aplicações construídas sobre grandes modelos de linguagem, publicada pelo OWASP GenAI Security Project e revisada periodicamente conforme o ecossistema muda.

Escopo

Qualquer aplicação construída sobre um grande modelo de linguagem: interfaces de chat, sistemas de recuperação, agentes e as ferramentas que eles invocam. É voluntária, não certificável e deliberadamente descritiva: classifica riscos, não prescreve controles nem concede conformidade.

Requisitos-chave

• A injeção de prompts lidera a lista desde a primeira edição e continua sendo a classe sem solução limpa: apenas contenção em camadas.
• A edição de 2025 cobre injeção de prompts, divulgação de informação sensível, cadeia de suprimentos, envenenamento de dados e modelo, tratamento indevido da saída, excesso de agência, vazamento do system prompt, fragilidades de vetores e embeddings, desinformação e consumo sem limite. A lista é revisada periodicamente, então consulte a edição vigente e não uma cópia em cache.
• Várias entradas são na prática específicas de agentes: excesso de agência e tratamento indevido da saída só ficam graves quando o modelo pode agir.
• É uma taxonomia, não um conjunto de controles. Mapear um achado para LLM06 diz que tipo de problema é, não o que construir.
• É a língua franca da área: revisões de segurança, questionários de fornecedores e relatos de falha a citam, e essa é boa parte do motivo para conhecê-la por número.
• Cobrir a lista não é uma postura de segurança. Cada entrada precisa de um controle na sua arquitetura, e uma entrada sem controle é um risco aceito, tenha alguém escrito isso ou não.

Controles

Mapeie a lista sobre a sua própria arquitetura

Percorra cada entrada diante das suas entradas reais, ferramentas, armazenamentos de dados e saídas. O exercício vale mais do que a lista, porque revela as entradas que não se aplicam e as superfícies que a lista não nomeia.

Atribua responsável e controle por entrada

Cada classe aplicável precisa de um componente concreto que a limite e de uma pessoa que o mantenha. Uma entrada mapeada para nada é uma lacuna com número de referência.

Trate a injeção de prompts como contenção, não como prevenção

LLM01 não tem solução confiável na camada do modelo. Os controles que importam são ferramentas com privilégio mínimo, restrição de saída, tratamento da saída e portões de aprovação para ações de alto impacto.

Limite a agência explicitamente

Para LLM06, escreva o que o agente pode fazer, com quais credenciais e contra quais alvos — e aplique isso abaixo do modelo, não no prompt.

Trate a saída do modelo como entrada não confiável

Para LLM05, tudo o que o modelo emite e chega a um renderizador, a um shell, a uma consulta ou a outro sistema precisa da mesma codificação e validação que você aplicaria à entrada de um desconhecido.

Limite o consumo

Para LLM10, limites de taxa, cotas e timeouts transformam um ataque de disponibilidade e custo em uma recusa registrada. É a entrada que mais se pula porque não parece segurança até a fatura chegar.

Refaça o mapeamento quando a lista ou o sistema mudar

A lista é revisada e o seu catálogo de ferramentas cresce. Um mapeamento feito uma vez é um documento sobre um sistema que já não existe.

Lista de verificação

• 01Leia a edição vigente em vez de um resumo, este incluído.
• 02Produza uma tabela de mapeamento: entrada → aplica? → controle → responsável.
• 03Para cada entrada aplicável sem controle, registre-a como risco aceito, com motivo e detecção compensatória.
• 04Escreva um teste por controle e veja o teste falhar antes de confiar nele.
• 05Revise as entradas que só mordem com ferramentas: excesso de agência, tratamento indevido da saída, cadeia de suprimentos.
• 06Confirme que limites de taxa e cotas existem e devolvem sinais corretos a clientes bem-educados.
• 07Refaça o mapeamento sempre que uma ferramenta, uma fonte de dados ou um nível de autonomia mudar.
• 08Use a numeração da lista nos achados para que revisores e fornecedores falem da mesma classe.

Erros comuns

• Tratar a lista como meta de conformidade: cobrir dez títulos enquanto a arquitetura real segue sem exame.
• Supor que o trabalho de segurança do fornecedor do modelo cobre LLM01. Ele reduz as tentativas; as consequências continuam inteiramente suas.
• Mapear contra uma edição em cache. A lista é revisada, e um mapeamento antigo deixa de cobrir em silêncio as classes atuais.
• Pular LLM10 porque consumo sem limite parece problema de operações e não de segurança.
• Confundir nomear uma classe com controlá-la. Uma tabela de mapeamento impecável sem aplicação é documentação do risco, não redução dele.

Exemplos

• Um agente que resume e-mails de clientes mapeia para LLM01 (o corpo do e-mail é entrada de instruções não confiável), LLM02 (o resumo pode repetir dados que quem pergunta não deveria ver) e LLM06 (a ferramenta de CRM transforma o sequestro em ação): três entradas de uma única funcionalidade, cada uma com um controle diferente.
• Um sistema RAG sobre uma wiki interna mapeia para LLM01 por injeção indireta a partir de qualquer editor de páginas, para LLM04 se o índice puder ser envenenado e para LLM08 por recuperação que devolve documentos fora das permissões de quem pergunta.
• Um endpoint MCP público mapeia sobretudo para LLM10: somente leitura e dados públicos, então o limite de consumo — limites de taxa com cabeçalhos corretos — é a entrada que faz o trabalho de verdade.

FAQs

É possível estar em conformidade com o OWASP LLM Top 10?

Não. É um documento de conscientização e classificação, não uma norma certificável. Ele combina naturalmente com um sistema de gestão como a ISO 42001 ou um framework como o NIST AI RMF, que é onde as obrigações de governança de fato vivem.

Quais entradas mudam mais ao dar ferramentas ao modelo?

Excesso de agência e tratamento indevido da saída. Sem ferramentas produzem uma resposta errada; com ferramentas produzem uma ação, e a gravidade passa de constrangimento a incidente.

Qual a relação com o MITRE ATLAS?

Respondem perguntas diferentes. O OWASP nomeia as classes de vulnerabilidade da sua aplicação; o ATLAS cataloga as táticas e técnicas que um adversário usa contra sistemas de IA. Uma é uma lista de verificação sobre o seu design, a outra é um mapa do manual do atacante.

Referências

• OWASP — Top 10 for LLM Applications
• OWASP — LLM01: Prompt Injection
• MITRE ATLAS — Adversarial Threat Landscape for AI Systems
• NIST — AI Risk Management Framework (AI RMF 1.0)

Governança relacionada