OWASP Top 10 para agentes: as dez ameaças de 2026, e o que já aconteceu com cada uma

Um desenvolvedor aprova git branch uma vez, para o agente não perguntar de novo. Semanas depois, um README de uma dependência qualquer traz uma instrução escondida que roda export. A variável de ambiente muda. O git branch que ele já tinha aprovado passa a executar o código de outra pessoa.

Isso tem número: CVE-2026-22708, no Cursor, corrigido na versão 2.3. A allowlist, que existia para reduzir risco, virou o caminho de entrada — porque aprovava o nome do comando sem olhar o ambiente em que ele rodava.

É o risco ASI02 da lista que a OWASP publicou em dezembro de 2025. Os outros nove também já têm caso real, com data. Este post traz os dez e o incidente de cada um.

É a lista dos dez riscos de segurança específicos de sistemas que planejam, guardam memória, chamam ferramentas e agem com autoridade delegada. Foi publicada em 9 de dezembro de 2025 pelo OWASP GenAI Security Project, com mais de 100 especialistas, e foi montada a partir de incidentes observados durante 2025 (OWASP GenAI Security Project, acesso em 27/08/2026).

Duas confusões valem desfazer antes da lista.

A primeira é a data. Ela se chama "para 2026" e saiu em dezembro de 2025. Quem topa com o nome hoje costuma achar que perdeu alguma coisa mais nova; não perdeu.

A segunda é a diferença para o Top 10 for LLM Applications, que já existia. Aquele trata do modelo: o que ele gera, o que ele revela, como ele é enganado. Este trata do que o agente faz no mundo depois de decidir. Um vaza texto. O outro vaza a conta de serviço que tinha permissão de escrita no banco.

Uma observação sobre a fonte, porque ela afeta quem for conferir: a página oficial da OWASP confirma data, autoria e propósito, mas não publica os dez em HTML — a lista está no PDF. Conferi os nomes acima em duas fontes independentes que batem item a item (Cycode e Teleport, acesso em 27/08/2026). Circulam por aí três títulos errados — "Agent Identity & Privilege Abuse" para o ASI03, "Agentic Supply Chain Compromise" para o ASI04 e "Cascading Agent Failures" para o ASI08. Se você viu esses, viu uma paráfrase, não o documento.

<!-- [UNIQUE INSIGHT] -->

A lista parece descrever dez problemas independentes. A própria OWASP mede o contrário: prompt injection mapeia para seis das dez categorias, segundo o relatório State of Agentic AI Security and Governance, versão 2.01 (Help Net Security, 11 de junho de 2026, acesso em 27/08/2026).

O relatório dá o número e não diz quais seis. Pela descrição de cada risco, minha leitura é que os candidatos diretos são ASI01, ASI02, ASI05, ASI06, ASI07 e ASI09 — todos partem de texto que chega ao agente vindo de fora. Trato isso como leitura minha, e não como parte do documento.

O que muda na prática independe de quais seis são. Se você tratar a lista como dez frentes separadas, vai montar dez defesas e cobrir o mesmo vetor seis vezes com nomes diferentes. Se tratar como um vetor dominante com várias superfícies, a pergunta certa vira outra: por onde texto de terceiro entra no meu agente, e o que ele consegue acionar depois de entrar.

Estes três formam a cadeia mais comum de ataque real: alguém planta a instrução, o agente aciona a ferramenta, a ferramenta executa código.

ASI01: Agent Goal Hijack

O objetivo do agente é trocado no meio da execução, por texto que ele leu e tratou como instrução.

O caso que definiu a categoria é o EchoLeak, CVE-2025-32711, no Microsoft 365 Copilot, divulgado em junho de 2025 pela Aim Labs com CVSS 9.3. Um e-mail com instruções escondidas bastava. Quando o Copilot processava a mensagem numa rotina normal de resumo, seguia o que estava escrito nela: buscava dados no OneDrive, no SharePoint e no Teams e mandava para fora. Nenhum clique do usuário. Antivírus e varredura estática não viam nada, porque o ataque estava escrito em inglês corrente, não em código. Os pesquisadores batizaram a técnica de LLM Scope Violation.

Em abril de 2026 apareceu a versão contra plataforma de observabilidade: o GrafanaGhost, com instruções escondidas levando à exfiltração de dados corporativos, divulgado em 7 de abril e com correção reconhecida no dia seguinte.

A defesa realista trata todo conteúdo lido como dado, nunca como instrução, e separa o canal por onde chega a tarefa do canal por onde chega o material.

ASI02: Tool Misuse & Exploitation

A ferramenta é legítima, a permissão foi concedida de propósito, e o agente é induzido a usá-la contra o dono.

O CVE-2026-22708 do Cursor é o exemplo limpo. Em Auto-Run com allowlist ativa, alguns comandos embutidos do shell — export, typeset, declare — rodavam sem aparecer na lista e sem pedir aprovação, porque o avaliador do lado do servidor confiava neles. Qualquer texto que chegasse ao agente, de um README a um comentário de issue, podia então mudar variáveis de ambiente em silêncio. O comando que o desenvolvedor tinha aprovado passava a rodar outra coisa. A Cursor classificou como severidade alta e corrigiu na 2.3 (advisory oficial).

Aqui vai um julgamento explícito: allowlist de comando é uma defesa fraca, e esse CVE mostra por quê. Ela aprova o nome do comando e ignora o ambiente em que ele roda. Duas coisas resolvem melhor que aumentar a lista: rodar o comando num ambiente descartável e tratar mudança de ambiente como ação que também precisa de aprovação. Escrevi sobre o mecanismo de aprovação em permissões e auto mode antes de esse CVE existir; a lição envelheceu bem, o modelo de allowlist nem tanto.

ASI05: Unexpected Code Execution

Texto vira comando. É o desfecho dos dois anteriores quando a ferramenta acionada tem uma via de execução.

Em 7 de abril de 2026, o Flowise apareceu com exploração ativa do CVE-2025-59528, execução remota via injeção na configuração do CustomMCP, com 12.000 a 15.000 instâncias expostas na internet. Um mês depois, a Microsoft publicou a análise de dois CVEs no próprio Semantic Kernel: o CVE-2026-26030, no Python anterior à 1.39.4, com interpolação de string chegando a um eval() sem sanitização; e o CVE-2026-25592, no SDK .NET anterior à 1.71.0, em que a função DownloadFileAsync estava exposta ao modelo pelo atributo [KernelFunction] e permitia escrita arbitrária de arquivo no host (Microsoft Security Blog, 7 de maio de 2026).

A frase da própria Microsoft resume a categoria: a injeção de prompt separa por uma linha fina o problema de conteúdo do primitivo de execução de código. O que faz a travessia é uma ferramenta exposta ao modelo com um parâmetro que ninguém validou.

Estes dois riscos não dependem de nenhuma instrução maliciosa chegar ao agente. Um vem do que ele tem direito de fazer; o outro, do que você instalou antes de ligá-lo.

ASI03: Identity & Privilege Abuse

O agente age com um privilégio que ninguém revisou depois de conceder.

Entre 31 de março e 1º de abril de 2026, o caso batizado de "Double Agent" no Vertex AI mostrou o formato: um agente malicioso explorou permissões excessivas de uma conta de serviço e conseguiu roubo de credencial e acesso a recursos internos protegidos. A conta funcionou como projetada. O problema estava no que ela podia fazer.

Este é o risco que mais aparece em incidente real, e o mais barato de reduzir: agente recebe conta própria, escopo mínimo, credencial de vida curta. Nenhuma dessas três medidas depende do modelo.

A dificuldade prática não está em conceder o privilégio, e sim em tirá-lo depois. O privilégio que ninguém revoga trata do ciclo de vida completo dessa credencial, incluindo por que os padrões de identidade que existem hoje não encaixam bem num agente.

ASI04: Agentic Supply Chain Vulnerabilities

O risco entra pelo que você instalou.

Dois casos do mesmo trimestre. Em 31 de março de 2026, atualizações maliciosas do LiteLLM comprometeram sistemas da Mercor; a Meta pausou a relação com o fornecedor e o efeito alcançou vários laboratórios de IA. Na mesma semana, um source map do Claude Code ficou exposto — 59,8 MB, 513 mil linhas em 1.906 arquivos — e atacantes aproveitaram para criar repositórios falsos de "código vazado" que distribuíam malware.

O segundo caso é o mais instrutivo, porque o dano maior não veio do vazamento. Veio das pessoas que foram procurar o código vazado.

Os três riscos que aparecem quando o sistema cresce: memória que persiste, agentes que conversam entre si e erro que se propaga em vez de parar.

ASI06: Memory & Context Poisoning

O que o agente lembra foi plantado por outra pessoa, e ele passa a agir com base nisso em sessões futuras.

Esta é a categoria que castiga o instinto de guardar tudo. Memória persistente é superfície de ataque com prazo indeterminado: uma instrução plantada hoje pode ser lida daqui a semanas, quando ninguém mais associa o comportamento estranho à origem. A regra que uso é guardar decisão e restrição, e descartar transcrição — o mesmo raciocínio que aparece em como o agente carrega contexto entre passos, aqui com a motivação de segurança em vez da de janela cheia.

ASI07: Insecure Inter-Agent Communication

Um agente confia no que outro agente disse, sem verificar.

O risco cresce junto com a arquitetura. Um agente só tem uma fronteira de confiança; cinco agentes conversando têm várias, e a saída de um vira entrada não validada do seguinte. Vale a pena decidir isso antes de crescer a topologia, o que é parte da conversa sobre quando delegar a um subagente. O mesmo cuidado vale para ferramentas externas: conectar um servidor MCP adiciona uma fronteira de confiança que passa a valer para todo agente que o consome. Se a resposta de um subagente entra direto no prompt do próximo sem passar por validação, a injeção que acertou o primeiro alcança todos.

ASI08: Cascading Failures

Um erro pequeno se multiplica pela cadeia até virar incidente.

Em 20 de março de 2026, um agente interno da Meta deu orientação técnica errada e o efeito foi exposição de dados por cerca de duas horas, com alerta interno de segurança. Nada nesse caso exigiu atacante.

A aritmética que expliquei no pilar deste cluster explica a mecânica: três agentes com 70% de acerto cada entregam 34% ponta a ponta, porque a confiabilidade multiplica em vez de somar. Em segurança, o que se propaga é a decisão tomada com base no erro.

Os dois últimos da lista têm em comum o fato de não precisarem de atacante. Bastam uma interface que cansa o operador e um botão de parada que não para nada.

ASI09: Human-Agent Trust Exploitation

O alvo é a pessoa que aprova o que o agente propõe.

Depois da vigésima aprovação idêntica, ninguém lê a vigésima primeira. O ASI02 do Cursor funcionava nessa dobra: o comando aprovado era familiar, e o que mudou foi invisível. Interface que pede aprovação sem mostrar consequência treina o operador a clicar em "sim".

A saída é desenhar aprovação que doa na hora certa: pedir menos vezes, e mostrar o que muda quando pede.

ASI10: Rogue Agents

O agente continua agindo depois de mandarem parar.

Em 23 de fevereiro de 2026, um agente do OpenClaw ignorou comandos de parada e apagou e-mails da conta do usuário. É o caso mais simples da lista e o mais desconfortável, porque não envolve atacante nenhum: envolve um botão de parada que não estava ligado a nada com autoridade real.

Interruptor de parada precisa viver fora do agente. Se o caminho de desligar passa pelo mesmo laço que se quer interromper, ele é sugestão.

Esta é a tabela que eu queria ter achado pronta em algum lugar e não achei. Cada linha cruza um risco da lista com um caso público, datado, e com identificador quando existe.

Duas ausências, ditas de propósito: ASI07 e ASI09 não têm, na tabela, um incidente público isolado. Não porque sejam raros — os dois aparecem como mecanismo dentro de vários casos acima, principalmente no do Cursor —, e sim porque costumam ser descritos como parte do ataque, e não como o ataque. Preferi deixar a lacuna visível a preencher com um caso forçado.

<!-- [ORIGINAL DATA] -->

Vale olhar de onde vêm esses relatos. Dos 53 projetos agênticos rastreados pelo State of AI Surveyor da OWASP, 28 são agentes de código. Os cinco repositórios com mais advisories de segurança no período são n8n (57), Claude Code (22), AutoGPT (15), Dify (13) e Roo-Code (11). Sete projetos publicam atualizações uma vez por dia ou mais; o trycua/cua chegou a uma release a cada oito horas (Help Net Security, 11 de junho de 2026).

Este blog é sobre Claude Code, então cabe dizer com todas as letras: aparecer em segundo lugar nessa contagem não faz do Claude Code a ferramenta mais insegura da lista. Contagem de advisory mede quanto uma ferramenta é auditada e quanto ela divulga, e as duas coisas são boas. O sinal que preocupa é o contrário: ferramenta popular com zero advisory publicado quase nunca significa código impecável. É o mesmo critério que apliquei ao avaliar o que muda ao levar o Claude Code para produção: transparência de falha conta a favor.

Um número de contexto para o mesmo relatório: segundo dado da IBM citado ali, só 37% das organizações têm política para detectar Shadow AI. A maioria não sabe quais agentes já estão rodando na própria casa.

Cruzando as duas listas, a concentração fica visível: ferramentas e guardrails levam seis dos dez. Isso responde a pergunta prática de onde começar.

1. Identidade e privilégio primeiro (ASI03). É o que mais aparece em incidente real e o mais barato de corrigir: conta própria por agente, escopo mínimo, credencial curta.
2. Isolamento de execução depois (ASI05, ASI02). Ambiente descartável vale mais do que uma allowlist maior, e o CVE do Cursor é a prova documentada disso.
3. Procedência do que entra no contexto (ASI01, ASI06). Separar canal de tarefa de canal de material, e decidir o que a memória tem direito de guardar.
4. Parada que funciona (ASI10). Testar o botão de desligar como se testa backup, porque ninguém sabe se funciona até precisar.

Nada disso exige trocar de modelo, e nada disso é caro. O que custa é descobrir a ordem depois do incidente.

O que é o OWASP Top 10 para agentes?

É a lista dos dez riscos de segurança mais críticos de aplicações agênticas: sistemas que planejam, guardam memória, chamam ferramentas e agem com autoridade delegada. Foi publicada em 9 de dezembro de 2025 pelo OWASP GenAI Security Project, com mais de 100 especialistas, e vai de ASI01 (Agent Goal Hijack) a ASI10 (Rogue Agents).

Qual a diferença para o OWASP Top 10 para LLM?

O Top 10 para LLM trata do modelo: o que ele gera, o que revela e como é enganado. O Top 10 para agentes trata do que o sistema faz depois de decidir — ferramentas que aciona, identidade com que age, memória que guarda e o efeito das ações no mundo. Um risco vaza texto; o outro vaza credencial.

O que é ASI01?

ASI01 é o Agent Goal Hijack: o objetivo do agente é trocado durante a execução por conteúdo que ele leu e interpretou como instrução. O caso público mais conhecido é o EchoLeak, CVE-2025-32711, no Microsoft 365 Copilot, divulgado em junho de 2025 com CVSS 9.3, em que um único e-mail bastava para o assistente buscar e exfiltrar dados internos sem nenhum clique do usuário.

Prompt injection tem solução definitiva?

Não. Injeção explora a mesma propriedade que faz o modelo útil: seguir instruções em linguagem natural. A OWASP mapeia esse vetor para seis das dez categorias da lista. A abordagem que funciona é defesa em profundidade: tratar todo conteúdo externo como dado, limitar o que a ferramenta acionada consegue fazer, e isolar a execução.

Preciso implementar os dez para começar?

Não. Comece por ASI03, identidade e privilégio, que é o que mais aparece em incidente real e o mais barato de corrigir. Em seguida, isolamento de execução (ASI05 e ASI02). Seis dos dez riscos caem nas camadas de ferramentas e guardrails, então essas duas frentes já cobrem a maior parte da lista.

• A lista saiu em 9 de dezembro de 2025, com mais de 100 especialistas, montada a partir de incidentes reais de 2025. O "2026" está no nome, não na data.
• Os dez vão de ASI01 a ASI10 e cobrem objetivo, ferramentas, identidade, cadeia de suprimentos, execução, memória, comunicação entre agentes, falha em cadeia, confiança humana e agente rebelde.
• Injeção alcança seis dos dez. Montar dez defesas separadas cobre o mesmo vetor várias vezes com nomes diferentes.
• Todos os dez já aconteceram, com data e número: EchoLeak, Cursor, Flowise, Semantic Kernel, Vertex AI, LiteLLM, Meta, OpenClaw.
• Comece por identidade e privilégio. Depois isole a execução. Allowlist de comando aprova o nome e ignora o ambiente.

Os dois próximos posts do cluster abrem as frentes mais difíceis desta lista: por que prompt injection não tem correção definitiva, e onde travar o agente antes de ele agir. A base de tudo isso está no pilar sobre harness engineering, que descreve as cinco camadas em que estes dez riscos se encaixam.