OWASP LLM Top 10 2026: o que mudou e o que isso exige

O OWASP LLM Top 10 virou a lista de referência para quem precisa justificar prioridade em segurança de aplicações com modelo de linguagem. Em agosto de 2026 o OWASP GenAI Security Project publicou uma nova edição, anunciada formalmente em setembro, e ela não é um ajuste de redação: três riscos mudaram de posição de forma relevante, um nome saiu e outro entrou.

Este artigo compara as duas edições item a item, explica o que cada movimento diz sobre o que está acontecendo em produção e termina com o que fazer na prática. Se o seu ponto de partida for o risco em si, e não a lista, o caminho é o guia de segurança de LLM e GenAI.

O que mudou da edição de 2025 para a de 2026

A lista de 2026 ficou assim, com a posição de 2025 entre parênteses:

• LLM01 Prompt Injection (era 1): entrada manipulada que faz o modelo ignorar a instrução de sistema.
• LLM02 Sensitive Information Disclosure (era 2): dado sensível que sai pela resposta.
• LLM03 Excessive Agency (era 6): permissão de agir além do necessário.
• LLM04 Supply Chain (era 3): risco em modelo, dataset, plugin ou dependência de terceiro.
• LLM05 Data and Model Poisoning (era 4): dado de treino, de ajuste fino ou de embedding manipulado.
• LLM06 Unbounded Consumption (era 10): consumo sem limite de recurso e de custo.
• LLM07 Misinformation (era 9): resposta errada entregue com confiança.
• LLM08 Hidden Context Exposure (categoria nova).
• LLM09 Vector and Embedding Weaknesses (era 8): falha na base vetorial que sustenta o RAG.
• LLM10 Improper Output Handling (era 5): saída usada sem validação por quem a recebe.

Prompt injection continua no topo, e isso por si só já é informação: é o terceiro ciclo seguido em que o problema mais básico do modelo é também o mais explorado. O que mudou de verdade está em três linhas. Excessive agency subiu três posições, improper output handling caiu cinco, e a categoria de vazamento do prompt de sistema deu lugar a uma formulação mais ampla.

Excessive agency saiu do sexto lugar e virou o terceiro

Excessive agency é o risco de dar ao modelo mais permissão, mais ferramenta ou mais autonomia do que a tarefa exige. Em 2024 isso era quase teórico na maioria das empresas, porque o modelo respondia perguntas e nada mais. Em 2026 ele executa: abre chamado, consulta banco, chama API, move arquivo, aprova etapa de processo.

A subida para o terceiro lugar é a lista reconhecendo que a superfície saiu do texto e entrou na ação. Um prompt injection em um chatbot produz texto enganoso; o mesmo prompt injection em um agente com credencial de escrita produz uma transação. É a diferença entre um incidente de conteúdo e um incidente de sistema, e ela está detalhada em MCP e agentic AI security, com a parte de operação em MCP em produção.

O controle prático não é novo, é o mesmo princípio de menor privilégio de sempre, aplicado a um ator que não é humano nem processo tradicional: cada ferramenta exposta ao agente precisa de escopo explícito, a ação com efeito externo precisa de confirmação ou de limite, e a credencial usada pelo agente precisa ser dele, não do usuário que o invocou.

Hidden context exposure, a entrada nova

A edição de 2025 tinha uma categoria chamada system prompt leakage, que tratava do vazamento das instruções de sistema. A de 2026 não traz esse item e traz, no oitavo lugar, hidden context exposure: a exposição do que estava no contexto do modelo sem que ninguém tivesse decidido torná-lo visível.

A formulação é mais larga de propósito, porque o contexto deixou de ser só o prompt de sistema. Hoje ele costuma reunir, na mesma janela, as instruções da aplicação, o histórico da conversa, os trechos que o RAG recuperou, a memória que o agente guardou de sessões anteriores, a descrição das ferramentas disponíveis e, com frequência, dado de outro usuário que passou por ali. Qualquer um desses pedaços pode sair na resposta, e o que vaza não é o segredo que alguém escondeu: é o material que a aplicação juntou por conveniência.

Na prática, o controle começa por uma pergunta de inventário que poucas equipes sabem responder de cabeça: o que exatamente entra na janela de contexto de cada chamada, e quem decidiu que entraria. Depois vêm as medidas: separar contexto por usuário e por tenant, não colocar segredo em prompt, classificar o que o recuperador pode trazer e registrar o contexto efetivo de cada chamada para conseguir auditar depois.

Por que o tratamento da saída caiu para o décimo

Improper output handling é usar a resposta do modelo sem validar, e a consequência é conhecida: a saída vira HTML em um navegador, consulta em um banco, comando em um terminal. Cair do quinto para o décimo lugar não significa que o risco sumiu, e a leitura mais provável é outra: esse é um dos poucos itens da lista que o time de aplicação já sabia tratar, porque é saneamento de entrada não confiável, disciplina que existe desde muito antes de LLM.

Vale notar o que isso implica para quem lê a lista de fora para dentro. Posição baixa não quer dizer severidade baixa. Em uma aplicação que injeta a resposta do modelo direto no DOM, improper output handling continua sendo o caminho mais curto para execução de script no navegador do cliente, independentemente de estar em décimo.

Como a lista é construída, e por que isso muda a leitura

Segundo o material de divulgação do projeto, a edição de 2026 foi construída a partir de um acervo de cerca de 7.700 incidentes de segurança em IA, combinado com o voto de praticantes, e o voto pesou mais que o dado de incidente na ordenação final.

Isso define o que a lista é e o que ela não é. Ela é um retrato do que a comunidade vê acontecer com mais frequência, útil para priorizar programa, treinar time e justificar orçamento. Ela não é uma avaliação de risco do seu sistema, porque risco depende do que a sua aplicação faz, de que dado ela toca e de que permissão ela carrega. A lista ordena; quem ordena para você é a sua própria modelagem de ameaça.

O que veio junto: o padrão de controle de agentes

A edição de 2026 não saiu sozinha. O mesmo projeto publicou um padrão de controle voltado a agentes e uma lista específica para aplicações agênticas, reconhecendo que o problema de um agente que planeja, chama ferramenta e age não cabe inteiro na lista pensada para aplicações de chat e de recuperação.

Para quem já tem agente em produção, é essa linha que merece leitura primeiro. Para quem ainda está em piloto, a ordem continua sendo a lista principal, porque os três primeiros itens dela aparecem em qualquer desenho, com agente ou sem.

O que fazer com a mudança, em ordem de esforço

Mudança de lista não vale nada enquanto não vira tarefa. A ordem abaixo começa pelo que custa pouco e termina no que precisa de projeto:

• Reler o inventário de aplicações com IA e marcar quais já executam ação, porque são essas que subiram de risco com o novo terceiro lugar. Se o inventário não existe, o ponto de partida é descobrir o uso não autorizado que já acontece.
• Listar o que entra no contexto de cada chamada, por aplicação, e apontar o dono de cada pedaço. É o exercício que torna hidden context exposure tratável.
• Revisar escopo de ferramenta e credencial de cada agente, com confirmação humana nas ações de efeito externo. O critério para decidir onde o humano entra está em human-in-the-loop.
• Checar a procedência de modelo, dataset e dependência, que é o quarto item da lista e tema de cadeia de suprimentos de IA.
• Tratar a base vetorial como sistema com controle de acesso, não como cache, no desenho descrito em RAG e LangChain.
• Transformar os itens em casos de teste, no conjunto adversarial versionado descrito em red team de IA e avaliação de modelos, para que a lista vire portão e não apresentação.
• Levar o resultado para a instância que decide, no formato que o conselho consome, assunto de governança de IA no conselho.

Perguntas Frequentes

Conclusão

A edição de 2026 diz, na ordem dos itens, o que mudou no mundo real: o modelo saiu do texto e entrou na ação, e o contexto virou um depósito que ninguém inventaria. Prompt injection segue em primeiro porque continua sendo o defeito de origem, e as duas posições seguintes passaram a tratar do que acontece quando esse defeito encontra permissão e dado.

Para quem mantém programa de segurança, a leitura útil não é decorar a nova ordem. É usar os três movimentos como gatilho de revisão: quais aplicações passaram a executar ação desde o último inventário, o que entra na janela de contexto de cada uma, e quem autorizou cada ferramenta que o agente pode chamar.

E vale manter a lista no lugar certo da conversa. Ela prioriza o que a comunidade vê com mais frequência. A severidade no seu caso continua vindo da sua modelagem de ameaça, do dado que a aplicação toca e da permissão que ela carrega.