OWASP Top 10 para aplicações com IA: o que muda para quem desenvolve com agentes

A organização por trás de um dos documentos mais citados da segurança de aplicações web, o OWASP Top 10, tem agora uma frente dedicada exclusivamente à inteligência artificial — e o recorte mais recente é direcionado a quem constrói agentes de IA, sistemas que não apenas respondem perguntas, mas executam ações por conta própria. Entender o que mudou nessas listas ajuda a explicar por que a segurança de aplicações de IA deixou de ser um detalhe técnico e virou pauta de diretoria.

Duas listas, dois tipos de risco

A OWASP GenAI Security Project mantém hoje dois documentos complementares. O primeiro, o OWASP Top 10 for LLM Applications, trata o modelo de linguagem como um componente dentro de uma aplicação — o risco está em como ele recebe entradas e gera saídas. Sua edição de 2026, divulgada em agosto durante a semana da conferência Black Hat, chegou a uma marca simbólica: pela primeira vez, o ranking não se baseou só na opinião de especialistas, mas também em uma análise de milhares de incidentes reais de segurança envolvendo IA, com peso de 25% no resultado final.

O segundo documento, o OWASP Top 10 for Agentic Applications, é mais novo — foi publicado em dezembro de 2025 — e nasceu justamente para cobrir uma lacuna: o que acontece quando o modelo deixa de ser só um gerador de texto e passa a ser um agente, com memória entre sessões, ferramentas que pode acionar e autonomia para encadear ações em vários passos, muitas vezes em nome de uma pessoa ou de uma empresa.

O que mudou na lista de riscos de LLM

Na edição 2026 da lista voltada a aplicações de LLM, os dois primeiros colocados permaneceram os mesmos de anos anteriores: Prompt Injection, quando um texto malicioso consegue se passar por uma instrução legítima para o modelo, continua em primeiro lugar, seguido por vazamento de informação sensível. Mas o que chama atenção são as mudanças abaixo do topo.

O risco de "Excessive Agency" — quando um sistema de IA tem mais permissão do que deveria para executar ações, como modificar arquivos, enviar e-mails ou acionar APIs — saltou da sexta para a terceira posição, o maior salto do ranking. Segundo os organizadores, essa foi também uma das poucas categorias em que a opinião dos especialistas e os dados de incidentes reais concordaram plenamente: é onde o dano de verdade está acontecendo.

Outro salto expressivo foi o do risco de consumo descontrolado de recursos, que subiu da última posição para a sexta colocação, agora reformulado em torno da ideia de custo assimétrico: um ataque pode forçar um sistema de IA a realizar cálculos caríssimos a um custo praticamente nulo para quem ataca, algo amplificado por modelos de raciocínio estendido e por cadeias de ferramentas conectadas via protocolos como o MCP.

Já o risco de desinformação — respostas erradas geradas com total confiança pelo modelo — subiu da nona para a sétima posição depois que os dados de incidentes reais mostraram que ele era mais grave do que os próprios especialistas imaginavam. A explicação está diretamente ligada a agentes: quando a resposta de um modelo aciona automaticamente uma ferramenta, aprova uma ação ou gera código que vai para produção, um erro deixa de ficar só na tela de chat e pode virar uma ação real e prejudicial no sistema.

Quando o modelo age, o risco muda de categoria

É justamente por essa razão que a OWASP decidiu separar, pela primeira vez de forma explícita, o risco de "modelo como componente" do risco de "modelo como agente" — e por isso criou uma lista própria, com identificadores que vão de ASI01 a ASI10.

Entre os riscos listados nessa segunda lista estão o sequestro do comportamento do agente, quando um invasor consegue assumir o controle do processo de decisão de um agente e transformá-lo em ferramenta de ataque; o uso indevido de ferramentas conectadas ao agente; falhas na comunicação entre agentes diferentes, que pode espalhar um erro por um sistema inteiro em cascata; e a exploração da confiança entre humano e agente, quando explicações convincentes, mas erradas, levam uma pessoa a aprovar uma ação que não deveria.

A lista não nasceu de projeções teóricas. Entre os casos reais que ajudaram a embasá-la estão a vulnerabilidade batizada de EchoLeak, que permitiu o vazamento de dados sem qualquer clique da vítima; a invasão de um assistente de programação com quase um milhão de instalações; e um episódio amplamente comentado em que um agente de IA apagou um banco de dados de produção durante um período em que mudanças estavam proibidas.

O que isso muda na prática para quem desenvolve

Para times que já usam ou pretendem usar agentes de IA, a principal mudança de mentalidade é entender que as duas listas se complementam e devem ser consultadas juntas sempre que houver qualquer nível de autonomia envolvido. Alguns pontos práticos se destacam:

Permissões de agentes devem seguir o princípio do menor privilégio possível, evitando que um assistente de IA tenha acesso amplo a sistemas quando só precisaria de um recurso específico.

Ações de maior impacto — como enviar mensagens, publicar conteúdo ou alterar dados de produção — continuam exigindo confirmação humana, e não apenas confiança na "boa vontade" do modelo.

Memória persistente e bases usadas em RAG (recuperação de contexto) precisam de auditoria e controle de integridade, já que um conteúdo malicioso plantado nelas pode influenciar decisões do agente por muito tempo, não só em uma interação isolada.

Informações consideradas "escondidas", como instruções internas do sistema ou esquemas de ferramentas, devem ser tratadas como potencialmente descobríveis, e não como segredo garantido.

Limites de custo e circuit breakers por agente ajudam a evitar que uma única falha ou ataque gere gastos computacionais desproporcionais.

O recado central dos dois documentos, resumido pelos próprios mantenedores do projeto, é que a meta não deve ser construir um modelo impossível de enganar — isso, segundo eles, é praticamente inatingível. O objetivo realista é desenhar o sistema ao redor do modelo de forma que, quando ele for enganado (o que eventualmente vai acontecer), o estrago fique contido.