Segurança de LLM em 2026: o OWASP Top 10 ligado a controles e testes

Segurança de LLM significa construir o sistema em volta de um modelo de linguagem de modo que, quando o modelo for enganado, nada importante quebre. Não dá para tornar o próprio modelo imune: ele lê instruções e dados como um único fluxo de tokens, e a orientação da OWASP de 2026 diz com todas as letras que hoje não existe prevenção confiável contra prompt injection. Então o trabalho passa para o código em volta. Estreite o que o modelo alcança, verifique fora do modelo cada ação que ele pede, limite o que ele pode gastar e trate o que ele escreve como entrada não confiável. O checklist que a maioria dos times usa é o OWASP Top 10 para aplicações LLM, cuja edição 2026 saiu em agosto de 2026. Abaixo, cada um dos dez riscos está ligado a como ele aparece numa aplicação real, ao controle que o limita e a um teste que você roda antes do lançamento.

Quais são os riscos do OWASP Top 10 para aplicações LLM em 2026?

Esta é a lista 2026 na ordem oficial, lida em genai.owasp.org em 07/10/2026. Os controles e testes foram condensados das seções de mitigação do documento da OWASP e reduzidos ao que um time pequeno consegue de fato rodar.

A lista cobre o modelo como componente dentro da sua aplicação. Quando o modelo passa a agir sozinho, com ferramentas, memória entre sessões e ações em sistemas seguintes, a OWASP aponta para uma segunda lista, o Top 10 para aplicações agênticas, publicado em dezembro de 2025. A maioria dos agentes em produção precisa das duas.

O que mudou na lista de 2026, e por que isso importa?

A edição 2026 é a primeira conferida com dados de incidentes. O projeto reuniu 7.714 incidentes de bancos públicos de vulnerabilidades e de um banco de danos causados por IA, classificou os 6.639 que tinham detalhe suficiente e deu a esse registro um quarto do peso, com a votação dos profissionais respondendo pelos outros três quartos.

A ordem mudou mais do que em anos anteriores:

• Excessive Agency subiu para o terceiro lugar. A OWASP chama essa de a mudança mais importante: é nos agentes que o estrago está acontecendo.
• Unbounded Consumption subiu quatro posições, para o sexto. Os profissionais agora dão mais peso a custo e esgotamento de recursos do que a posição antiga dava.
• Improper Output Handling caiu do quinto para o décimo e agora cobre também o código inseguro que os assistentes geram em escala.
• System Prompt Leakage virou Hidden Context Exposure, que cobre schemas de ferramentas, instruções de desenvolvedor e texto de políticas além do prompt de sistema.
• Misinformation está em sétimo, mas os líderes do projeto da OWASP chamam atenção para ela: os votantes a colocaram perto do fim, o registro de incidentes perto do topo.

Um detalhe vale saber antes de planejar o orçamento. Ordenado só pelo registro bruto de incidentes, prompt injection sai do top 10. A OWASP lê isso como efeito da defesa: os times combatem injeção com força, então menos explorações limpas chegam aos bancos públicos. Ela continua em primeiro porque a superfície existe em qualquer lugar onde um modelo lê entrada não confiável.

Quais são os 3 principais riscos de segurança de IA?

Pela lista de 2026: prompt injection, divulgação de informação sensível e agência excessiva. Eles são mais bem lidos como uma cadeia.

Uma injeção entra pelo conteúdo que o modelo lê: um chamado de suporte, uma página web, um convite de agenda, o título de uma issue. O que ela consegue fazer depois depende dos dados que o modelo vê (risco dois) e do que o modelo consegue fazer acontecer (risco três). A entrada de prompt injection da OWASP diz que a maioria dos incidentes de alto impacto registrados ficou grave porque a injeção caiu num sistema cujas ferramentas ou escopos deixavam o modelo agir com os privilégios do usuário.

Isso dá um teste que você faz num quadro branco. Simon Willison chama de lethal trifecta (a tríade letal), a Meta chama a sua versão de Rule of Two (regra de dois), e o documento da OWASP cita as duas: um agente que lê conteúdo não confiável, alcança dados privados e se comunica com o exterior (ou muda estado) tem tudo de que um atacante precisa. Tire uma perna e o pior resultado encolhe. A OWASP diz que qualquer agente com as três precisa de aprovação humana para cada ação.

Por que um filtro de prompt não resolve prompt injection?

Porque o atacante se adapta e o filtro não. A entrada da OWASP 2026 cita Nasr et al. (2025): em 12 defesas recentes, ataques que quase nunca funcionavam em testes estáticos tiveram sucesso em mais de 90% das vezes contra a maioria delas quando o atacante pôde se adaptar à defesa. Esquemas de separação estrutural como o StruQ foram contornados do mesmo jeito.

Os guardrails gerenciados mostram o mesmo padrão na fronteira de entrada. A ML6 testou quatro deles com 80.000 prompts em holandês, numa divisão de 63/37 entre benignos e nocivos, usando configurações padrão ou quase padrão (publicado em 22 de junho de 2026):

O idioma importa (a ML6 testou holandês de propósito) e configurações ajustadas dariam outros números, mas a conclusão vale para qualquer idioma: um guardrail é uma camada que reduz a taxa de ataque. Parta do princípio de que algumas injeções passam e projete para que um modelo enganado não consiga fazer muita coisa.

O que um pen test deixa passar numa aplicação LLM?

Um pen test web padrão continua importando: autenticação, gestão de sessão, injeção nas suas próprias APIs e infraestrutura valem para uma aplicação LLM. O que ele normalmente não exercita:

• Injeção indireta: os testadores digitam na caixa do chat. As instruções perigosas chegam por documentos, páginas recuperadas, e-mails e resultados de ferramentas que o modelo lê por conta própria.
• Permissões das ferramentas: um pen test verifica se um endpoint está autorizado. Raramente pergunta se o modelo deveria poder chamá-lo, ou com qual escopo.
• Persistência em memória e RAG: uma injeção gravada na memória de longo prazo ou num banco vetorial afeta toda sessão posterior que lê dali. Uma única sessão de teste não mostra isso.
• Custo: esgotar o seu orçamento de inferência é um ataque da lista de 2026. Poucos escopos de pen test incluem um teste de gasto.
• Atacantes adaptativos: um conjunto fixo de prompts mede o que os ataques estáticos conseguem, e Nasr et al. mostraram o quanto isso subestima um atacante que se adapta.
• Destinos da saída: a saída do modelo que chega a um navegador, a um terminal, a um banco de dados ou a outro agente precisa da mesma revisão que a entrada do usuário, e muitas vezes fica fora do escopo testado.

Quando contratar um, coloque esses itens no documento de escopo pelo nome e peça os payloads usados. Se o testador não souber dizer como chegou ao modelo pelo conteúdo recuperado, o caminho indireto não foi testado.

Quais boas práticas de segurança de IA cobrem a maior parte da lista?

Seis controles, todos eles código que é seu, fecham a maior parte dos dez riscos. Estas boas práticas de segurança de IA saem direto das seções de mitigação da OWASP.

1. A autorização fica fora do modelo. O modelo propõe; o código decide. Cada chamada de ferramenta passa por uma verificação do usuário, da ação e dos argumentos, o que a OWASP chama de complete mediation (mediação completa). Isso limita injeção, agência excessiva e exposição de contexto oculto de uma vez, porque nada no prompt concede coisa alguma. O hábito que coloca uma chave de serviço no bundle do cliente também coloca chaves de API em prompts de sistema; as duas saem do mesmo jeito.
2. Privilégio mínimo para cada ferramenta. Uma ferramenta que resume e-mails recebe acesso de leitura, não de envio nem de exclusão. Um recomendador de produtos recebe leitura de uma tabela. Evite ferramentas abertas (shell, buscar qualquer URL) quando uma estreita resolve. Se você está construindo um servidor MCP, a implantação em etapas de um servidor MCP em 90 dias, primeiro só leitura e depois ações com uma pessoa no circuito, aplica isso diretamente.
3. Verificação de acesso dentro da recuperação. Filtre por tenant e por permissão do documento na consulta ao índice, antes de os resultados voltarem. Isso cobre tanto a divulgação de informação sensível quanto o caso entre tenants das fraquezas em vetores.
4. Tetos rígidos, aplicados no código. Limites de tokens por usuário e por minuto, tetos de gasto que param a inferência, e limites de passos, recursão e tempo nos agentes.
5. A saída é entrada não confiável. Codifique para o lugar onde ela cai, use consultas parametrizadas, bloqueie imagens Markdown renderizadas automaticamente e prévias de links, e remova caracteres de controle antes de a saída chegar a um terminal ou a um log. Código que o modelo escreve para você também é saída e passa pela mesma revisão.
6. Uma pessoa aprova o que não tem volta. Pagamentos, mensagens externas, exclusões. Mostre a quem revisa a ação exata que será executada, não um resumo dela. Onde traçar essa linha, e quanto custa, está em o que a sua IA não pode decidir.

Uma lição de um pipeline movido a modelo que rodamos no nosso próprio site (cartas montadas a partir dos números das nossas auditorias) está por trás do item 1: uma regra no prompt não se sustentou. Um modelo redigindo a partir das nossas próprias medições inverteu uma porcentagem, somou duas medições separadas como se fossem uma e ordenou dois números ao contrário. Uma instrução no prompt contra isso não sobreviveu a duas reescritas do prompt. Código que confere cada afirmação contra os dados de origem antes de qualquer envio sobreviveu. É o padrão claim-check-act (afirmar, verificar, agir) da OWASP para desinformação.

Como testar uma aplicação LLM antes do lançamento?

Trate como uma suíte de regressão que roda a cada mudança no prompt, no modelo, nas ferramentas ou nas fontes de recuperação.

• Monte um conjunto de payloads por risco, usando a tabela acima como roteiro: instruções injetadas em cada tipo de conteúdo que você ingere, consultas entre tenants, tentativas de extrair o prompt de sistema, entradas gigantes, saída que executaria no seu renderizador. Comece com poucos casos por risco, desde que sigam os caminhos da sua própria aplicação.
• Use ferramentas abertas para cobertura: o garak da NVIDIA se descreve como um scanner de vulnerabilidades de LLM. O PyRIT da Microsoft é um framework aberto para encontrar riscos em sistemas de IA generativa. O promptfoo roda red team e varreduras de vulnerabilidade a partir de configurações declarativas e se encaixa no CI. A entrada da OWASP 2026 cita AgentDojo e JailbreakBench como referências. A Web Security Academy da PortSwigger tem laboratórios práticos de ataques a LLMs na web, se o seu time nunca rodou um.
• Depois teste de forma adaptativa: dê a um red teamer a descrição completa das suas defesas e deixe que ele itere. A OWASP diz para rejeitar números de sucesso de ataque que vêm só de testes estáticos.
• Teste o raio de impacto além da injeção: para cada ferramenta, pergunte o que acontece quando o modelo a chama com os piores argumentos válidos. Se a resposta for inaceitável, a correção está nas permissões ou na aprovação, e nenhuma mudança de prompt vai segurar.
• Bloqueie o lançamento: um caso que falha trava o deploy do mesmo jeito que um teste unitário que falha. Rode tudo de novo depois de cada atualização de modelo: uma nova versão de modelo é uma nova dependência.

Se o seu produto também expõe páginas ou ações a agentes de IA externos, SaaS pronto para agentes de navegador cobre a superfície de consentimento e auditoria que esses agentes esperam de você.

O que o AI Act da UE exige em segurança de LLM?

Para sistemas de IA de alto risco, o Artigo 15(5) do AI Act exige resiliência contra tentativas de alterar o uso, as saídas ou o desempenho do sistema, com medidas contra envenenamento de dados, envenenamento de modelo, exemplos adversariais, ataques à confidencialidade e falhas do modelo. Isso corresponde a LLM05 (envenenamento), LLM02 (confidencialidade) e LLM01 (entradas criadas para fazer o modelo errar).

As datas mudaram em 2026. O Regulamento (UE) 2026/1744, o Digital Omnibus sobre IA, fixa a aplicação dos requisitos de alto risco a partir de 2 de dezembro de 2027 para os sistemas listados no Anexo III (emprego, educação, crédito e usos parecidos) e a partir de 2 de agosto de 2028 para IA embutida em produtos cobertos pelas leis de segurança do Anexo I. Descumprir obrigações de fornecedor pode gerar multa de até 15 milhões de euros ou 3% do faturamento anual mundial, o que for maior. A faixa de 7% vale para práticas proibidas, não para falhas de segurança. Os dois textos foram lidos no EUR-Lex em 07/10/2026.

Um assistente de atendimento ao cliente ou uma ferramenta de busca interna em geral não é de alto risco pelo Anexo III. Os controles da OWASP continuam valendo a pena, e se você passar depois para um uso de alto risco, os relatórios de teste viram a sua evidência.

Por onde um time pequeno deve começar?

Se você está lançando o seu primeiro recurso com LLM, ou herdou um que foi construído às pressas, esta ordem dá a maior redução com o menor trabalho:

Depois mantenha rodando: execute a suíte de novo a cada mudança de modelo, prompt ou ferramenta, e revise a lista de riscos quando a OWASP a atualizar. Se ninguém no time é dono do sistema depois do lançamento, essa é a lacuna que o Care cobre: alguém assume o sistema feito em casa, estabiliza e continua de olho nele.