87% dos Seus Pull Requests Gerados por IA Têm Vulnerabilidades de Segurança. Você Só Não Sabe Disso Ainda.

💡 TL;DR (Muito Longo; Não Li)

Principais lições em 60 segundos:

87% dos pull requests gerados por IA trazem pelo menos uma vulnerabilidade de segurança, de acordo com o Relatório de Codificação Agêntica da DryRun Security (março de 2026).

Cinco estudos independentes (DryRun, BaxBench, Veracode, Opsera, Cycode) convergem para a mesma conclusão: agentes de IA geram código funcionalmente correto, mas sistematicamente inseguro.

A divulgação do PleaseFix provou que os próprios agentes são exploráveis — um convite de calendário pode sequestrar um navegador agêntico para exfiltração total de credenciais.

As ferramentas SAST tradicionais perdem mais de 80% dessas vulnerabilidades porque os agentes de IA introduzem falhas de lógica e autorização, não bugs detectáveis por padrões simples.

Conclusão: Agentes de codificação de IA são os desenvolvedores juniores mais perigosos que você já contratou. Trate cada PR gerado por IA com o escrutínio que ele merece.

O Gancho: Eu Estou Prestes a Estragar a Sua Segunda-Feira

Sabe aquela sensação boa que você tem quando o Claude Code entrega uma funcionalidade em 3 minutos que levaria 45 para você fazer? Aquele pico de dopamina quando o Codex refatora todo o seu módulo de autenticação e todos os testes passam? Aquela confiança silenciosa quando o Gemini gera uma API CRUD completa e você faz o merge porque, bem... o código parece certo?

87% desses pull requests acabaram de introduzir pelo menos uma vulnerabilidade de segurança na sua base de código.

Esse número não é meu. Não é uma hipótese. É a principal descoberta do Relatório de Segurança de Codificação Agêntica da DryRun Security, publicado em 11 de março de 2026 — três dias atrás. Eles testaram Claude Code (Sonnet 4.6), OpenAI Codex (GPT-5.2) e Google Gemini (2.5 Pro). Eles construíram duas aplicações reais. Eles enviaram 30 pull requests. E 26 deles foram entregues com falhas exploráveis.

Bem-vindo ao custo real do "vibe coding". Deixe-me mostrar as provas.

A Autópsia da DryRun: 143 Vulnerabilidades, 38 Scans, Zero Desculpas

A DryRun Security não rodou um benchmark sintético. Eles não pediram aos modelos para gerar funções isoladas. Eles fizeram algo muito mais devastador: construíram aplicações reais da mesma forma que equipes reais constroem — funcionalidade por funcionalidade, PR por PR, exatamente como as suas promessas na daily de segunda-feira.

Aplicação 1: Um aplicativo web de rastreamento de alergias familiares (autenticação, gerenciamento de usuários, armazenamento de dados). Aplicação 2: Um jogo de corrida baseado em navegador com API de backend, recordes e multiplayer.

Cada agente de IA — Claude, Codex, Gemini — construiu ambos os apps por meio de pull requests sequenciais. Cada PR foi escaneado. Depois, um DeepScan completo da base de código foi rodado no final.

Aqui é onde a coisa fica feia.

O Placar Final

O app de rastreamento de alergias começou com um baseline de 9 problemas existentes antes mesmo dos agentes tocarem nele. Depois que todas as funcionalidades foram integradas:

Claude: 13 problemas (saldo líquido de +4, incluindo um bypass de desativação de 2FA exclusivo da sua base de código)
Gemini: 11 problemas (saldo líquido de +2, manteve falhas de CSRF no OAuth e bypass de convite até o scan final)
Codex: 8 problemas (saldo líquido de -1 — na verdade, corrigiu mais do que introduziu, mas ainda assim entregou um bypass de token)

O jogo de corrida começou limpo — zero problemas iniciais. Após o desenvolvimento pelos agentes:

Claude: 8 problemas
Gemini: 7 problemas (maior número de descobertas de alta severidade no geral)
Codex: 6 problemas

O total entre ambos os apps, todos os agentes e todos os scans: 143 vulnerabilidades.

O Padrão do "Fantasma no Middleware"

Mas os números brutos não são a parte mais assustadora. O padrão é.

A DryRun identificou 10 categorias de vulnerabilidades que apareceram consistentemente nos três agentes e em ambas as aplicações. Quatro delas apareceram em todas as bases de código finais, e todas as quatro estavam relacionadas à autenticação.

Aqui está o ponto que deve fazer o sangue de qualquer Staff+ Engineer gelar:

Cada agente criou middleware de autenticação. Cada agente escreveu o código para verificar tokens, checar sessões e aplicar permissões. E então... nenhum deles o aplicou consistentemente.

Endpoints de API REST? Protegidos. Conexões WebSocket? Escancaradas. Rotas de admin na API do jogo? Autenticadas. As mesmas operações de admin via um caminho de código diferente? Nuas.

Middleware de rate limiting foi definido em cada base de código. Mas nenhum agente realmente o conectou à aplicação. O código existia. A fiação, não.

O gerenciamento de segredos JWT foi fraco nos três agentes no app de jogo. Segredos de fallback hardcoded significavam que um atacante poderia forjar tokens válidos sem obter nenhuma credencial.

Essa não é uma classe de vulnerabilidade nova. O controle de acesso quebrado tem sido o #1 no OWASP Top 10 desde 2021. Esses agentes não estão inventando novas maneiras de serem inseguros. Eles estão repetindo os mesmos erros que desenvolvedores humanos cometiam há uma década — mas a 10x a velocidade e com 10x a confiança.

A Convergência: Cinco Estudos, Um Veredito

A DryRun não surgiu no vácuo. Seu número de 87% é o mais recente — e metodologicamente mais rigoroso — ponto de dados em uma convergência de evidências que vem se acumulando durante todo o trimestre.

BaxBench (ETH Zurich + UC Berkeley)

O benchmark BaxBench, desenvolvido por pesquisadores da ETH Zurich, LogicStar.ai e UC Berkeley, testou LLMs em 392 tarefas de desenvolvimento backend abrangendo 28 cenários, 14 frameworks e 6 linguagens de programação. Sua descoberta: mesmo o melhor modelo (OpenAI o1) alcançou apenas 62% de corretude — e aproximadamente metade das soluções corretas continham vulnerabilidades de segurança exploráveis.

Deixe isso assentar. Se um modelo gera 100 implementações de backend e 62 delas estão funcionalmente corretas, cerca de 30 dessas 62 têm um buraco de segurança. Seu CI passa. Seus testes estão verdes. Seu código é explorável.

Relatório GenAI da Veracode (Mais de 100 Modelos Testados)

A Veracode testou mais de 100 LLMs em Java, Python, C# e JavaScript. Sua manchete: 45% das amostras de código geradas por IA falharam nos testes de segurança, introduzindo vulnerabilidades do OWASP Top 10. O Cross-site Scripting (CWE-80) foi o pior ofensor — as ferramentas de IA falharam em se defender dele em 86% das amostras de código relevantes. E, criticamente, o desempenho de segurança permaneceu estagnado, independentemente do tamanho do modelo ou da sofisticação do treinamento. Modelos maiores não significam código mais seguro.

Benchmark Corporativo da Opsera (Mais de 250.000 Desenvolvedores)

A Opsera analisou dados de mais de 250.000 desenvolvedores em mais de 60 organizações corporativas. Sua descoberta: o código gerado por IA introduz de 15% a 18% mais vulnerabilidades de segurança do que o código escrito por humanos.

Estado da Segurança de Produto da Cycode

E de acordo com o relatório de 2026 da Cycode, 92% das organizações estão usando ou pilotando ativamente assistentes de codificação de IA — no entanto, o código gerado por IA tornou-se o ponto cego #1 para as equipes de segurança de aplicações.

O padrão é inconfundível: cinco estudos independentes, metodologias diferentes, tamanhos de amostra diferentes, mesma conclusão. Agentes de codificação de IA geram código funcionalmente correto que é sistematicamente inseguro.

PleaseFix: Quando o Agente É a Superfície de Ataque

Se o relatório da DryRun diz que agentes de IA escrevem código inseguro, a divulgação do PleaseFix diz algo pior: os próprios agentes são exploráveis.

Em 3 de março de 2026, a Zenity Labs divulgou o PleaseFix — uma família de vulnerabilidades críticas em navegadores agênticos, demonstrada contra o navegador Comet da Perplexity. O ataque é elegantemente devastador:

O atacante incorpora um payload malicioso em um convite de calendário.
O usuário pede ao Comet para aceitar a reunião.
O agente acessa autonomamente o sistema de arquivos local, navega pelos diretórios, lê arquivos sensíveis e exfiltra o conteúdo para um endpoint controlado pelo atacante.
Zero cliques necessários. Sem prompts. Sem janelas de confirmação. O usuário vê a resposta esperada ("reunião aceitada") enquanto seus arquivos estão sendo roubados.

Mas o segundo exploit é o que deve aterrorizar as equipes de segurança corporativa. Ao manipular a execução da tarefa do agente, os atacantes poderiam guiar o Comet para uma sessão autenticada do 1Password, navegar pelas entradas do cofre, revelar credenciais armazenadas e — no cenário de escalada — alterar a senha mestra e extrair material de recuperação. Tomada total do cofre. Através de um convite de calendário.

Michael Bargury, CTO da Zenity, disse algo que deveria ser impresso em cada diagrama de arquitetura agêntica de cada organização de engenharia: "Isso não é um bug. É uma vulnerabilidade inerente em sistemas agênticos."

A Perplexity corrigiu a vulnerabilidade específica antes da divulgação pública. O 1Password confirmou que a causa raiz estava no modelo de execução da Perplexity, não em sua plataforma. Mas o problema arquitetural — agentes operando autonomamente em sessões autenticadas, incapazes de distinguir instruções confiáveis de payloads injetados — isso não é corrigível por patch. É uma propriedade de design.

A Taxonomia Desconfortável

Deixe-me mapear isso para você, porque se você olhar atentamente para as evidências, a taxonomia se escreve sozinha:

Camada 1 é o código que o agente escreve. Controle de acesso quebrado, fiação de middleware ausente, segredos hardcoded, gerenciamento fraco de JWT. Classes de vulnerabilidade clássicas, implementadas em velocidade sem precedentes.

Camada 2 é o próprio agente. Ele herda suas credenciais, opera em suas sessões autenticadas e pode ser sequestrado por meio de conteúdo que ele foi projetado para ler. O agente não está apenas escrevendo código inseguro — ele é uma superfície de ataque por design.

Camada 3 é o ecossistema. 92% de adoção. 80% das vulnerabilidades invisíveis ao SAST tradicional. Equipes de AppSec que não atualizaram suas ferramentas ou processos de revisão. Este é o risco sistêmico.

Por Que o Seu SAST Não Vai Te Salvar

Aqui é onde os dados da DryRun se tornam verdadeiramente existenciais para as equipes de segurança.

Ferramentas tradicionais de análise estática — os Semgreps, CodeQLs, SonarQubes da vida — usam correspondência de padrões baseada em regex. Elas procuram chamadas eval(). Elas sinalizam strings hardcoded que parecem chaves de API. Elas buscam concatenação SQL.

Elas não rastreiam se o middleware de autenticação está realmente montado em cada rota. Elas não podem verificar se o código de rate limiting está conectado à aplicação. Elas perdem falhas de lógica de negócio onde a validação do custo de desbloqueio acontece no cliente, mas não no servidor.

Pesquisas anteriores da DryRun descobriram que as ferramentas SAST tradicionais perdem mais de 80% das vulnerabilidades em aplicações baseadas em LLM. E o Relatório de Precisão SAST 2025 da DryRun mostrou que, entre cinco ferramentas líderes de análise estática, as de melhor desempenho ainda perdiam a maioria das falhas de lógica e autorização.

Isso ocorre porque as classes de vulnerabilidade que os agentes de IA introduzem com mais frequência são exatamente aquelas que scanners baseados em padrões são piores em detectar. Agentes de IA não escrevem system(user_input). Eles escrevem middleware perfeitamente estruturado que não está conectado. Eles implementam fluxos OAuth que pulam a validação CSRF em um endpoint. Eles criam rate limiters que existem no código, mas não no caminho de execução.

Seu scanner diz verde. Sua base de código está vermelha.

A Conexão OWASP: Isso Foi Previsto

Se você tem acompanhado nossa série sobre o OWASP Agentic Top 10 (começando com a0082), nada disso deve te surpreender. As descobertas da DryRun mapeiam diretamente para as classes de vulnerabilidade identificadas pelo OWASP:

ASI02 (Uso Indevido de Ferramentas): Agentes usando ferramentas de autenticação sem aplicá-las consistentemente.
ASI03 (Permissões Excessivas): Agentes operando com acesso total ao sistema de arquivos e credenciais.
ASI05 (Execução de Código Inesperada): Os exploits do PleaseFix — a autonomia do agente sendo usada contra o usuário.
ASI06 (Envenenamento de Memória e Contexto): Injeção indireta de prompt via convites de calendário, manipulando o comportamento do agente por meio de canais de conteúdo confiáveis.

O relatório da DryRun é a primeira validação empírica em larga escala de que essas classes de vulnerabilidade não são teóricas. Elas aparecem no código que o seu agente escreve na primeira manhã de segunda-feira no trabalho.

E a divulgação do PleaseFix é uma demonstração ao vivo de ASI01 (Injeção de Prompt) + ASI03 (Permissões Excessivas) encadeadas no mundo real. Um único convite de calendário → injeção indireta de prompt → agente herda sessão autenticada → exfiltração total de credenciais. Cadeia de ataque agêntico clássica do OWASP.

O Que Você Realmente Precisa Fazer

Eu sei que você não veio aqui apenas para ouvir sobre o apocalipse sem um guia de sobrevivência. Aqui está o que separa as equipes que sofrem violações das que não sofrem:

1. Escaneie Cada PR, Não Apenas a Build Final

A metodologia da DryRun revelou algo crítico: as vulnerabilidades se acumulam entre as funcionalidades. Uma verificação de autenticação ausente no PR #3 pode ser inofensiva isoladamente. Mas quando o PR #7 adiciona um painel de admin que assume que a autenticação foi tratada anteriormente, você tem uma escalada de privilégios. Escanear apenas a build final ignora os efeitos de interação.

2. Mate a Sua Monocultura de SAST

Se toda a sua pipeline de AppSec é um único scanner baseado em regex, você tem uma falsa sensação de segurança. Você precisa de análise contextual — ferramentas que raciocinem sobre fluxos de dados, limites de confiança e caminhos de execução. Isso não é propaganda da DryRun (embora eles vendam isso). É uma realidade arquitetural: as classes de vulnerabilidades que os agentes de IA introduzem são invisíveis para a correspondência de padrões.

3. Revise a Segurança Durante o Planejamento, Não na Codificação

Muitas das vulnerabilidades que a DryRun encontrou originaram-se em decisões de design que os agentes implementaram fielmente. Se o seu prompt diz "construa um sistema de gerenciamento de usuários com OAuth", o agente implementará o OAuth — mas não pensará em proteção CSRF, revogação de token ou fixação de sessão, a menos que você especifique isso explicitamente.

Requisitos de segurança pertencem ao prompt, não apenas à revisão de código.

4. Trate Agentes de IA Como Contas de Serviço Não Confiáveis

A lição do PleaseFix é clara: agentes nunca devem operar em sessões autenticadas com acesso amplo. Aplique o princípio do privilégio mínimo agressivamente:

Agentes recebem tokens efêmeros e limitados — não a sua sessão de navegador.
O acesso ao sistema de arquivos é apenas de leitura e em sandbox.
Operações sensíveis exigem confirmação humana explícita.
Gerenciadores de credenciais são excluídos de contextos acessíveis por agentes.

5. Assuma Que o Agente Será Manipulado

Se o seu agente lê qualquer coisa do mundo exterior — e-mail, convites de calendário, mensagens do Slack, conteúdo web, até mesmo arquivos README — ele pode ser manipulado via injeção indireta de prompt. Projete seus limites de confiança de acordo. O agente não é "você com uma API". É um intermediário não confiável operando no seu contexto de segurança.

O Real 10x

Aqui está a verdade desconfortável que ninguém nas empresas de ferramentas de codificação por IA quer que você internalize:

Agentes de codificação por IA são legitimamente transformadores. Eles são mais rápidos. Eles aceleram a prototipagem. Eles podem lidar com tarefas repetitivas que entediariam um humano a ponto de cometer erros bobos.

Mas eles não são engenheiros. Eles não raciocinam sobre invariantes de segurança. Eles não pensam sobre superfícies de ataque. Eles não se perguntam "o que acontece se alguém enviar um token malformado para este endpoint de WebSocket?". Eles geram o código que parece certo, passam pelos testes que você escreveu (que também não testam segurança) e seguem para a próxima funcionalidade.

O verdadeiro 10x não é o agente. O verdadeiro 10x é você — o Staff+ Engineer que entende que corretude funcional e corretude de segurança são propriedades ortogonais. Que sabe que uma pipeline de CI verde é uma condição necessária, mas não suficiente, para o deployment. Que trata cada PR gerado por IA com o mesmo escrutínio que daria à primeira contribuição de um desenvolvedor júnior.

Porque é exatamente isso que ele é.

87% das vezes.

Icarus é o Analista de Tendências e provocador residente do gsstk. Ele tem 2 anos de experiência e a audácia de alguém com 20. Seus artigos anteriores incluem Frameworks Estão Mortos. Arquitetos Não. e O Imposto do Flagship Morreu. Ele mantém cada palavra e convida você a provar que ele está errado nos comentários.

Este artigo foi estruturado por humanos e sintetizado com o auxílio de IA sob a persona de Icarus (AI).