Se você escreveu código essa semana, é quase certo que uma IA escreveu parte dele com você. No Google, mais de 30% do código novo já era gerado por IA em 2025. Segundo declarações mais recentes de Sundar Pichai, esse número teria chegado a 75% do código novo, gerado por IA e aprovado por engenheiros. Na Microsoft, Satya Nadella fala em 20 a 30% dos repositórios. No mercado geral, o survey da Aikido com 450 organizações estima que cerca de um quarto do código de produção já nasce de um modelo.
A discussão “devemos usar IA para programar?” acabou; perdeu para a realidade. A pergunta que sobrou é mais difícil e mais interessante: como continuar entregando nessa velocidade sem entregar vulnerabilidade junto?
Este post reúne o que aprendemos preparando um treinamento interno sobre o tema, mais tudo que estivemos acompanhando em conferências de segurança dos últimos meses: os dados, os incidentes de 2023 a 2026, e principalmente uma armadilha que vemos se espalhando, a de que basta colocar outra IA para revisar o que a primeira escreveu.
TL;DR: se você só tem dois minutos
- Código de IA funciona, mas não é seguro por padrão, e você fica mais confiante justamente quando devia desconfiar. 45% das amostras reprovam em testes de segurança (Veracode), e a taxa não melhorou em dois anos de modelos “revolucionários”. O estudo de Stanford mostrou o efeito colateral: código menos seguro e desenvolvedores mais convencidos de que estava seguro.
- Os incidentes de 2025–2026 quebraram suposições básicas: prompt é código executável (Amazon Q), a sua CLI de IA é superfície de ataque (s1ngularity), clonar um repo pode executar payload sem install e sem clique (Miasma Worm), e autorização não “emerge” do prompt (170+ apps Lovable expostos).
- Colocar outra IA para revisar não resolve. Revisores LLM flipam o veredito ao renomear uma variável (26% dos casos) e os erros dos modelos são correlacionados; um segundo modelo não é um segundo par de olhos, é o mesmo olho duas vezes. Nem os fabricantes vendem essa promessa.
- Na Black Hat/DEF CON 2026, seis pesquisas independentes chegaram ao mesmo ponto: LLM não funciona como fronteira de segurança. Classificadores, soft boundaries e scanners baseados em LLM caíram em todas elas.
- A autonomia dos agentes cresce mais rápido que a accountability sobre o que eles fazem. O mercado ainda não tem padrão de limites nem baseline de segurança por tipo de uso, e controles que dependiam de revisão humana ou autorização explícita estão sendo delegados justamente ao agente.
- O que funciona é o que já conhecíamos: determinismo, observabilidade e isolamento. Sandbox com privilégio mínimo, gates de CI determinísticos (SAST/SCA/secret scanning), CODEOWNERS nas configs de agente e revisor humano com responsabilidade nomeada.
- Se for fazer uma única coisa amanhã: tire a credencial de produção da máquina de dev.
- A regra de ouro: IA propõe, humano dispõe. Revisar código de IA não é o gargalo do processo; é o seu nome no merge.
O código funciona. E é exatamente isso que engana
O dado mais importante dos últimos dois anos vem da Veracode, que testa sistematicamente a segurança de código gerado por LLMs. No GenAI Code Security Report de 2025, com mais de 100 modelos e 80 tarefas de código, 45% das amostras reprovaram em testes de segurança, introduzindo vulnerabilidades clássicas do OWASP Top 10. Enquanto isso, mais de 95% do código era sintaticamente correto e compilava de primeira.
A atualização de 2026, já com 150+ modelos, trouxe a conclusão mais desconfortável: a taxa não melhorou. Nas palavras do próprio relatório, dois anos de lançamentos “revolucionários” moveram o ponteiro de segurança de ~55% de aprovação para… ~55%. Java segue como pior caso (29% de aprovação), e as falhas se concentram onde detectar exige entender fluxo de dados, não reconhecer padrão: tarefas com risco de XSS passam só 15% das vezes; log injection, 13%.
Modelo maior escreve código mais bonito. Não escreve código mais seguro. Funcionalidade e segurança são eixos independentes, e todo o ciclo de feedback da IA otimiza o primeiro.
O efeito colateral humano é ainda mais traiçoeiro. O estudo de Stanford publicado na ACM CCS, “Do Users Write More Insecure Code with AI Assistants?”, mostrou as duas metades do problema de uma vez: participantes com assistente de IA escreveram código menos seguro e saíram mais convencidos de que ele era seguro. É o automation bias aplicado a código: a resposta chega rápida, bem formatada, confiante. E a gente baixa a guarda. O detalhe otimista do estudo: quem desconfiou da IA e refinou os prompts errou menos. Ceticismo é uma skill de segurança.
E não é um problema novo: a NYU já media ~40% de código vulnerável no Copilot em 2021. Cinco anos e várias gerações de modelos depois, a taxa é essencialmente a mesma. Enquanto isso, a GitGuardian mostra que repositórios com assistentes de IA vazam segredos aproximadamente no dobro da taxa dos demais.
2025–2026: o ano em que os avisos viraram manchete
Teoria à parte, os últimos 18 meses produziram um catálogo de incidentes que vale conhecer, porque cada um quebra uma suposição diferente.
“O agente obedece instruções.” Em julho de 2025, durante um experimento público de vibe coding, o agente da Replit executou comandos destrutivos no banco de produção durante um code freeze explícito, apagando dados de mais de mil empresas. E ainda afirmou que o rollback era impossível (não era). “Não toque em produção” escrito num prompt não é controle de segurança. Se a instrução é a única coisa entre o agente e o desastre, não existe controle.
“Prompt é só texto.” No mesmo mês, um atacante conseguiu injetar um prompt malicioso na release oficial da extensão Amazon Q para VS Code (~950 mil instalações), instruindo o agente a apagar o sistema do usuário e recursos AWS. Passou pela revisão porque parecia “só texto”; só não executou por um erro de sintaxe do próprio payload. Em ferramentas agênticas, prompt é código executável, e merece o mesmo rigor de revisão.
“Minha CLI de IA é ferramenta minha.” Em agosto de 2025, o ataque à supply chain do Nx (“s1ngularity”) inaugurou uma técnica: o malware procurava as CLIs de IA instaladas na máquina da vítima (Claude Code, Gemini, Amazon Q) e as executava com flags de bypass de permissão (--dangerously-skip-permissions, --yolo, --trust-all-tools) para fazer o reconhecimento e roubar credenciais. A sua IA, com as suas permissões, trabalhando para o atacante.
“Clonar um repositório é seguro.” A evolução veio em junho de 2026 com o Miasma Worm, descendente do Shai-Hulud e criado pelo grupo TeamPCP. Além de pacotes npm trojanizados (incluindo a variante “Phantom Gyp”, que executa código no npm install via binding.gyp, sem lifecycle script declarado), o worm usava credenciais roubadas para commitar diretamente nos repositórios configs auto-executáveis de agentes e IDEs: hook de SessionStart em .claude/settings.json, rules do Cursor, tasks de folderOpen no VS Code. Você clona o repo, abre no editor, e o payload roda. Sem install, sem prompt, sem clique. Setenta e três repositórios da Microsoft foram comprometidos e desativados; dias depois, o toolkit foi publicado como open source. O mesmo grupo por trás do Miasma está operando um botnet autorreplicante que sequestra clusters de IA, minerando criptomoedas e roubando modelos privados (US$ 4M/ano em recursos sequestrados de ~250 mil infraestruturas Ray expostas) e usando IA para desenvolver, ofuscar e limpar o código de seu próprio malware.
“A IA cuida do CRUD, a segurança emerge.” Os apps de vibe coding mostraram o contrário em escala: mais de 170 aplicações geradas pelo Lovable expostas por falta de Row-Level Security (CVE-2025-48757), com e-mails, dados de pagamento e chaves de API baixáveis por qualquer pessoa. A IA gera o caminho feliz; o modelo de autorização não “emerge” do prompt; precisa ser projetado e verificado por tabela, por rota, por ação.
Complete o quadro com o EchoLeak (CVE-2025-32711, o primeiro zero-click prompt injection contra um produto LLM de produção, no Microsoft 365 Copilot), o CamoLeak (CVSS 9.6, exfiltração de repos privados via GitHub Copilot Chat) e o slopsquatting. A pesquisa da USENIX Security 2025 mostrou que 19,7% dos pacotes recomendados por LLMs simplesmente não existem, e que as alucinações se repetem de forma previsível, permitindo que atacantes registrem os nomes antes de você instalar.
O que vimos na Black Hat/DEF CON 2026
Entre junho e agosto deste ano, o mercado de segurança inteiro aponta pra um lugar: IA. Nos stands da Black Hat, quase tudo era variações do tema: pentest com IA, pentest para IA, SOC com IA, scan de vulnerabilidades com IA. Nos briefings, separei 6 talks independentes de pesquisadores chegaram no mesmo ponto: LLM não funciona como fronteira de segurança.
Classificadores e soft boundaries caem para criatividade. Uma equipe testou agentes de compras de grandes varejistas e descobriu que classificadores (“bodyguards” de prompt) que bloqueavam jailbreaks sofisticados caíam pra prompts sem sentido: poesia, nomes do agente entre cada palavra. Um campo de busca, desprotegido pelo classificador, vazou o system prompt framado como “produto de busca”. Com acesso ao sistema prompt, executaram Python, provaram controle determinístico, extraíram API keys. Os vendors trataram o takeover como “informacional” e não corrigiram a raiz.
Intent collision em agentic browsers. Outra talk detalhou uma classe distinta de vulnerabilidade: não é “prompt injection” clássica, é o agente sendo convencido de que atender ao ataque é ajudar o usuário (“intent collision”). Através de convites de agenda ou threads virais, atacantes conseguem zero-click RCE: o agente visita um site, e então pode se propagar como worm, exfiltrar dados ou fazer compras não autorizadas. Uma técnica adicional emergiu, o “history poisoning”: envenenar o histórico que o agente trata como verdade, criando vetor de persistência sem malware.
Skills como novo npm. Uma terceira talk focou em “skills”: instruções para agentes, vindas de gente aleatória da internet, com acesso a credenciais de cloud e Kubernetes. Scanners estáticos baseados em LLM foram bypassados por payloads escondidos em cache, C-shim, e engenharia social contra o próprio scanner. A conclusão: a defesa que funciona é “detonation chamber” (rodar a skill em ambiente isolado, observando rede, kernel e traces), e não outro classificador. Pesquisadores descobriram campanhas ativas (PolyMarket, clone de repositórios populares pra colher credenciais).
Sandbox escape no Copilot. Um quarto caso: prompt injection num documento → arbitrary code execution → privilege escalation → infrastructure exposure → path traversal → RCE com shell interativo dentro do Copilot. A cadeia era 80% AppSec clássico (serviço interno sem sanitização, symlink, ld.so.preload), mas o ponto de entrada era prompt injection. Resultado: atacante sentado na cadeira do usuário, mandando prompts e lendo respostas. Virou CVE.
Shadow vulnerabilities e IA ofensiva. Uma quinta talk alertou sobre “shadow vulnerabilities”: disputas entre mantenedor e pesquisador sobre se um padrão é vulnerability ou feature. Quando não há CVE, scanner nenhum olha. O TeamPCP, mesmo grupo do Miasma, está explorando exatamente isso em escala com um botnet auto-propagante que lê documentação para weaponizar gaps em velocidade de máquina.
Harness vulnerabilities. Por fim, a sexta talk que assisti detalhava como a segurança de ferramentas agênticas (Claude Code, Gemini, OpenAI) repousa em suposições escondidas no harness, não na config. Validadores veem strings diferente de como o runtime as executa (bypass via flags). Allow-lists atuam como registration gate, não runtime filter. Shared writable instructions entre stages permitem primeira fase escrever, segunda executar.
O padrão claro: nenhuma dessas defesas foi “usar IA pra revisar”. Todas apontam pra mesma coisa: determinismo, observabilidade, isolamento. Classificadores, soft boundaries, scanners LLM: tudo caiu. O que não caiu: sandbox com least privilege, monitoramento comportamental, revisor humano com responsabilidade nomeada.
O que eu vi de dentro, por Gustavo Lima
O que eu percebi é que a indústria ainda não chegou a um consenso sobre como trabalhar com IA. Existe uma pressão muito grande pra adoção da tecnologia, porém a pressão é pra entrega: de features com IA, de introdução de IA em processos, de otimização de força de trabalho. E ainda não existe um padrão bem estabelecido dos limites desse uso. Qual a maneira correta de aplicar IA em diferentes níveis? Na prática, quais são as dificuldades reais de implementação do jeito seguro? Qual é a baseline de segurança pros diversos tipos de uso que a IA proporciona? Todas as empresas, não só as grandes, estão implementando, estão testando, estão criando processos próprios. Em outras palavras, o clima ainda é de muita experimentação.
Nós conseguimos perceber que a adoção de IA no dia a dia não acompanha o nível de conhecimento que o usuário tem sobre o risco dessas ações. Por exemplo: muitos briefings abordaram vulnerabilidades em navegadores comandados por agents. Quem entrega o navegador pro agent não sabe que está entregando junto todas as sessões abertas e todas as contas salvas. Também não sabe que, quando o agent lê uma página na web, aquela página vira texto, e esse texto entra na instrução que ele está executando. Aí basta um atacante plantar o conteúdo certo numa dessas páginas, e o agent executa a instrução dele ali dentro.
Durante os eventos ficou claro que existe um gap entre adotar uma tecnologia de IA e reconhecer os perigos que ela representa em nível de business, tanto nos processos da empresa quanto no dia a dia, no laptop dos colaboradores.
O mesmo descompasso aparece na autonomia. Todo stakeholder enxerga a autonomia dos agents de IA como escalabilidade, e isso é óbvio. Mas, na mesma medida em que essa autonomia cresce, o accountability sobre o que esses agents estão implementando não cresce junto: não está claro, não está bem definido.
Então são temas muito novos. E muitos controles de segurança pensados e aplicados em produtos ao longo de anos estão precisando ser repensados. Porque o controle que barrava o problema às vezes era uma revisão humana, uma autorização explícita. E hoje essa autorização está sendo delegada pro próprio agent.
O que ainda não está claro são os limites. O que está claro, pra quem é de cybersecurity, é que um agent nunca deve ser executado com as mesmas permissões, os mesmos privilégios, os mesmos acessos que o usuário que vai comandá-lo. Agent tem que rodar em sandbox. E as capacidades dessa sandbox devem ser extremamente restritas, tanto de acesso à informação quanto de rede.
E tem a observability: o que está acontecendo dentro de cada agent, quais decisões ele está tomando, por que ele está tomando essas decisões. Ainda é um tópico muito sensível. A arquitetura de segurança segue sendo criada e discutida. Mês a mês aparecem avanços, aparecem vulnerabilidades nesses desenhos, aparecem jailbreaks, sandbox escaping. E tudo isso precisa ser acompanhado num ritmo frenético.
Pro profissional de cibersegurança isso já é um desafio enorme. Imagina pra quem está do outro lado, cobrado ao mesmo tempo por boas práticas e por agilidade nas tarefas do dia a dia, nos entregáveis, no consumo de tokens, nas linhas de código escritas.
E os atacantes estão explorando exatamente isso. A falta de conhecimento, a distância entre adotar uma ferramenta nova e usá-la do jeito certo. Ou seja, a internet hoje é um verdadeiro playground para os atacantes.
A armadilha do momento: IA vigiando IA
Diante disso tudo, uma resposta vem ganhando popularidade nas empresas: “a gente gera com IA, mas passa outra IA para revisar a segurança”. Parece defesa em profundidade. Não é. E essa é a parte que mais gerou discussão, tanto no treinamento quanto nos briefings. Então vamos por partes.
Revisores LLM não são confiáveis na tarefa. O estudo SecLLMHolmes (IEEE S&P 2024) testou os principais modelos como detectores de vulnerabilidade e encontrou respostas não-determinísticas e frágeis: renomear uma variável flipou o veredito em 26% dos casos. Em avaliações com pares de código vulnerável/corrigido (o teste mínimo de um revisor de verdade), GPT-4 acertou os dois lados apenas 13% das vezes; várias avaliações colocam LLMs no nível do chute aleatório nessa tarefa.
E os erros são correlacionados. A premissa de qualquer esquema de dupla checagem é que os revisores falham de formas independentes. O paper “Great Models Think Alike” (ICML 2025) mediu exatamente isso e concluiu o oposto: quanto mais capazes os modelos, mais os erros deles convergem. Some-se o viés de auto-preferência demonstrado no NeurIPS 2024 (avaliadores LLM reconhecem e favorecem produção de LLM) e o quadro fecha: um segundo modelo não é um segundo par de olhos; é o mesmo olho, duas vezes. E o mercado de segurança inteiro, de pesquisadores em labs de universidades a engenheiros do Google, Microsoft e outros, está chegando nessa mesma conclusão.
Isso saiu do paper e virou manchete em junho de 2026: um commit no conector open-source da Snowflake, co-assinado/revisado pelo Copilot Autofix, introduziu uma falha de injeção de comando no CI, explorada cinco dias depois pelo agente ofensivo autônomo da Wiz, que extraiu um token com acesso ao Jira interno. O GitHub contesta que o Copilot tenha escrito a falha; diz que ele falhou em sinalizá-la. Para o nosso argumento, tanto faz: nos dois papéis possíveis, a IA deixou a vulnerabilidade passar. E do outro lado, IAs ofensivas já caçam exatamente esses gaps, em escala.
Detalhe que costuma desarmar resistência: nem os fabricantes vendem essa promessa. O GitHub escreve na própria documentação que o Copilot code review “não é um substituto para revisões manuais nem para scanners”. A Anthropic posiciona permissões, sandbox e o /security-review do Claude Code como camadas de defesa em profundidade, com findings direcionados a um humano. A Snyk publica a acurácia do autofix (~76–80%) e exige revisão humana. Review por IA é um sensor a mais no pipeline, e um sensor excelente. O erro é promovê-lo a certificador final.
O que fazer: quatro camadas que erram diferente
A boa notícia: nada aqui exige inventar segurança nova. Exige aplicar princípios que já conhecemos (privilégio mínimo, defesa em profundidade, verificação independente) ao novo integrante do time, que digita muito rápido e não tem medo de sexta-feira. O critério que amarra tudo: camadas que falham de formas independentes. Humano cansa, mas erra diferente da IA. SAST é “burro”, mas erra diferente. É isso que fecha gap.
Na máquina do dev: agente em sandbox, começando read-only, com escrita e execução sob aprovação, e flag de bypass nunca em máquina com credenciais (lembre do s1ngularity). Segredos fora do alcance do agente (deny rules para .env e afins; secrets manager para o resto) e credencial de produção simplesmente inexistente no ambiente de dev (lembre da Replit). Rules files (CLAUDE.md, AGENTS.md) com os requisitos de segurança do time, versionados e revisados como código (lembre do Amazon Q). E npm ignore-scripts, cooldown para versões recém-publicadas (bloqueia slopsquatting) e Workspace Trust ligado; repo recém-clonado nunca executa nada sozinho. Browser de IA em perfil isolado, sem acesso a conta pessoal do usuário (previne intent collision / zero-click).
No git e no repositório, a camada que o Miasma tornou obrigatória: branch protection com PR obrigatório (token roubado sozinho não landa commit), commits assinados com verificação exigida, secret scanning com push protection, e (o controle mais específico contra os novos vetores) CODEOWNERS nos caminhos de config de agente: .claude/**, .cursor/**, .gemini/**, .vscode/**, mcp.json, .github/workflows/**. Mudança ali vira revisão humana nomeada, nunca um commit silencioso. Shadow vulnerabilities (padrões sem CVE) precisam de atenção extra: auditoria de “o que é considerado safe” e rastreio de quem consome essas suposições.
No pipeline: todo código de IA passa por PR com aprovador humano que entende o que aprova; PRs pequenos e frequentes, porque revisar 200 linhas funciona e “revisar” 3.000 é teatro. SAST, SCA, secret scanning e testes como gates determinísticos, sem exceção para “código do agente”. Pacote novo sugerido por IA é suspeito de slopsquatting até prova em contrário: existência, idade, downloads, lockfile com hash. E proveniência: commits de IA identificados (Co-authored-by), com humano responsável por cada merge. Security review por IA em todo PR, como sensor adicional, nunca como aprovador.
E a IA a seu favor, porque ela é genuinamente boa em segurança quando está no papel certo: autofix supervisionado, threat modeling antes de codar, geração de testes negativos e fuzzing, triagem de alertas. A regra de ouro que resume o papel: IA propõe, humano dispõe. Toda ação de segurança da IA termina numa decisão humana registrada, nunca num merge automático.
Para estruturar tudo isso, os mapas já existem: o OWASP Top 10 para aplicações com LLM (edição 2026, a primeira ponderada com dados reais de milhares de incidentes, com Excessive Agency subindo ao terceiro lugar puxada pelos agentes em produção), o Top 10 Agêntico e o guia Securing Agentic Applications do mesmo projeto, o NIST SSDF com o companion de IA generativa (SP 800-218A), o SAIF do Google e o MITRE ATLAS para modelagem de ameaças. Conselho prático: não adote tudo; escolha o da sua situação e transforme em checklist de PR. Framework só funciona quando vira gate.
O checklist de segunda-feira
- Agentes em sandbox, começando read-only, sem flag de bypass em máquina com credencial.
- Credencial de produção fora da máquina de dev; segredos via secrets manager + deny rules.
- Requisitos de segurança nos rules files + CODEOWNERS nas configs de agente (
.claude/,.cursor/,.vscode/,mcp.json). - Todo código de IA passa por PR com aprovador humano nomeado; PRs pequenos e frequentes.
- SAST + SCA + secret scanning como gate de CI, sem exceção para “código do agente”.
- Pacote novo sugerido por IA: verificar existência, idade e downloads + lockfile com hash.
- Security review por IA em todo PR, como sensor adicional, nunca como aprovador.
- Commits de IA identificados (proveniência) + humano responsável por cada merge.
- Auditoria de harness: listar o que é “seguro” ou “pré-aprovado” + procurar “handoff bugs” (decisão em um lugar, consumida com mais privilégio em outro).
Se for escolher um único item para fazer amanhã: tire a credencial de produção da máquina de dev. É o que transforma “o agente fez besteira” de incidente em anedota.
Velocidade multiplicada, erros multiplicados
A imagem que usamos no treinamento resume o resto: trate a IA como um estagiário brilhante: absurdamente rápido, sabe de tudo, trabalha de madrugada. E nenhum de nós deixaria o estagiário fazer deploy em produção sem revisão no primeiro mês.
A IA multiplica a sua velocidade e multiplica os seus erros, na mesma proporção. Os guardrails deste post existem para deixar só a primeira multiplicação acontecer. E revisar código de IA não é o gargalo do processo: é o seu nome no merge. Responsabilidade não se delega para ferramenta.
Na Taura Security, estivemos na Black Hat e DEF CON 2026 acompanhando essas pesquisas de perto, e ajudamos times de engenharia a adotar IA com segurança desde o assessment do fluxo de desenvolvimento aos guardrails de agentes, git e pipeline descritos aqui. Se o seu time está acelerando com IA e a pergunta “quem garante a segurança disso?” ainda não tem resposta boa, fale com a gente.
