Você confia no seu assistente de IA para programar. Ele escreve funções limpas, trata edge cases, coloca comentários úteis. O código compila, os testes passam, o pull request — a proposta de merge do código novo no projeto principal — recebe o joinha. Três meses depois, um pentester encontra uma brecha numa função que o seu agente escreveu às 2 da manhã. Ninguém questionou porque "parecia ok."

Isso não é um experimento mental. Isso é terça-feira.

O abismo entre confiança e competência

Código gerado por IA já responde por cerca de 46% do código novo em muitas empresas. Não tem como fugir. Mas em algum lugar entre "a IA escreveu" e "fizemos deploy", surgiu uma suposição perigosa: que a máquina sabe o que está fazendo. Ela não sabe. Ela é uma digitadora muito rápida sem nenhuma noção do que é um atacante.

Você precisa de um manual de campo. Aqui está o seu.

Um em cada quatro trechos tem uma brecha

Em fevereiro de 2026, o grupo de pesquisa em segurança AppSecSanta testou seis LLMs importantes — large language models, os cérebros por trás do ChatGPT, Claude, Gemini e companhia — em 89 prompts focados em segurança. Python e JavaScript. Tarefas reais mapeadas para o OWASP Top 10 — a lista amplamente aceita dos riscos de segurança mais críticos para aplicações web.

O resultado: 25,1% do código gerado continha vulnerabilidades confirmadas. Um em cada quatro trechos. Sua IA produz bugs em escala industrial, e faz isso com a calma confiança de alguém que nunca foi hackeado.

Taxas de vulnerabilidade por modelo:

Modelo Taxa de vuln.
GPT-5.2 19,1% (melhor)
Gemini 2.5 Pro 22,4%
Grok 4 23,7%
Claude Opus 4.6 29,2%
DeepSeek V3 29,2%
Llama 4 Maverick 29,2%

Essa diferença de 10 pontos significa que a escolha do modelo importa. Mas mesmo o melhor modelo entrega uma vulnerabilidade em quase uma a cada cinco saídas. Escolher o GPT-5.2 ao invés do Llama 4 ajuda. Mas não te salva.

Onde os modelos mais falham:

  • SSRF (Server-Side Request Forgery — quando seu servidor é enganado para acessar URLs internas em nome de um atacante): 32 achados. A maior categoria isolada.
  • Injection (SQL injection, command injection — quando input do usuário se infiltra em queries de banco de dados ou comandos do sistema): 30 achados, 33,1% de todos os problemas.
  • Configuração insegura: 25 achados — secrets hardcoded, modo debug ligado em produção.
  • Controle de acesso quebrado (deixar usuários fazerem coisas que não deveriam poder fazer): presente em todos os modelos testados.

Um estudo separado da Help Net Security de março de 2026 testou Claude Code, OpenAI Codex e Google Gemini no modo agente — não apenas autocomplete, mas codificação totalmente autônoma. Os agentes produziram 143 problemas de segurança em 38 scans cobrindo 30 pull requests. 87% dessas PRs continham pelo menos uma vulnerabilidade. Controle de acesso quebrado apareceu na saída de todos os agentes. Todos. Sem. Exceção.

Por que a máquina escreve código inseguro

Os modelos não são maliciosos. São máquinas de probabilidade treinadas no GitHub, e o GitHub está cheio de código inseguro. Respostas do Stack Overflow de 2015 que fazem hardcode de secrets JWT (JWT — JSON Web Token, um passe digital que prova que você está logado). Código de tutorial que pula validação de input porque "isso é só uma demo". Código de produção de empresas que nunca fizeram um audit de segurança.

Três padrões aparecem sempre:

1. Validação server-side ausente. Agentes de IA aceitam valores do lado do cliente — scores, saldos, roles de usuário — sem verificar no servidor. O modelo aprendeu com milhares de tutoriais que "deixaram a validação como exercício para o leitor". O leitor nunca fez o exercício. A IA também não.

2. Defaults inseguros. Tokens JWT sem data de expiração. Implementações OAuth (OAuth — um protocolo que permite "Entrar com Google" ao invés de criar mais uma senha) sem o parâmetro state que previne hijacking. Refresh tokens que não podem ser revogados. Os modelos geram código que funciona mas escolhem o default preguiçoso, não o seguro.

3. SSRF em todo lugar. Quando um modelo escreve código que faz fetch de uma URL, ele quase nunca verifica para onde essa URL aponta. Sem allowlists, sem bloqueio de IPs internos, sem restrição de protocolo. Ele simplesmente chama requests.get(user_input) e manda pra produção. Um atacante alimenta http://169.254.169.254/ e de repente tem as credenciais do seu cloud.

Sua defesa em cinco camadas

Pare de esperar os modelos ficarem mais espertos em segurança. Monte um pipeline — uma sequência automatizada de verificações — que pegue problemas independente de quem ou o quê escreveu o código.

Camada 1: Prompting focado em segurança

A correção mais simples não custa nada. Um estudo da Veracode descobriu que adicionar um lembrete genérico de segurança ao seu prompt melhorou a taxa de código seguro de 56% para 66% no Claude Opus 4.6. Dez por cento de melhoria com uma frase. Não é mágica. Mas é grátis.

Adicione isso ao seu system prompt, às suas regras do Cursor ou ao seu CLAUDE.md:

Ao escrever código: valide todas as entradas no server-side. Nunca confie
em dados do cliente. Use queries parametrizadas. Defina defaults seguros
para tokens de auth (expiração, rotação). Bloqueie SSRF validando URLs
contra allowlists. Nunca faça hardcode de secrets.

Para agentes de IA como Claude Code, Codex ou Copilot em modo agente, coloque essas instruções nos arquivos de configuração do seu projeto. O agente lê em toda tarefa.

Camada 2: SAST no seu editor

SAST — Static Application Security Testing — escaneia seu código em busca de vulnerabilidades sem executá-lo, como um corretor ortográfico mas para brechas de segurança. O achado-chave do AppSecSanta: apenas uma ferramenta SAST pegou 78% das vulnerabilidades geradas por IA. Rodar múltiplos scanners melhora dramaticamente a cobertura.

Setup recomendado:

  • Semgrep — grátis, rápido, 3.000+ regras. Roda no VS Code, JetBrains e CI. Pega injection, SSRF, secrets hardcoded.
  • Bandit (Python) — pega problemas de segurança comuns em Python. Zero configuração.
  • ESLint security plugins (JavaScript) — eslint-plugin-security e eslint-plugin-no-unsanitized.

Instale o Semgrep como pre-commit hook — um script que roda automaticamente antes de cada commit, bloqueando código ruim de entrar no repositório:

pip install semgrep
semgrep --config auto --error .

Agora cada commit é escaneado. A IA escreve o código, o Semgrep dá um tapa antes de você dar push.

Camada 3: Scanning no pipeline de CI

Seu pre-commit hook pega o óbvio. Seu pipeline de CI — o sistema automatizado de build e testes que roda quando você faz push — deve rodar análise mais profunda:

# Exemplo GitHub Actions
- name: Semgrep SAST
  uses: semgrep/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/cwe-top-25
      p/python-security
      p/javascript-security

- name: Dependency check
  uses: dependency-check/dependency-check-action@v1

Foque suas regras nas categorias onde a IA mais falha: SSRF (CWE-918), injection (CWE-89, CWE-78), deserialização insegura (CWE-502 — quando dados maliciosos são desempacotados em objetos executáveis) e path traversal (CWE-22 — quando um atacante usa ../../ para escapar de um diretório e ler arquivos que não deveria).

Camada 4: Code review humano com foco em segurança

Code review de código gerado por IA é diferente de review normal. Você não está caçando erros de lógica — a IA lida razoavelmente bem com isso. Você está caçando:

  • Endpoints sem verificação de auth. A IA escreve o route handler mas esquece o middleware — o código porteiro que verifica "você tem permissão pra estar aqui?"
  • Input do usuário fluindo para lugares perigosos. Queries de banco de dados, operações de arquivo, requisições HTTP, comandos shell. Se input do usuário toca qualquer um desses sem sanitização, você tem um problema.
  • Rate limiting ausente. A IA nunca adiciona rate limiting a menos que você peça explicitamente. Todo endpoint público precisa, ou alguém vai martelar com 10.000 requests por segundo.
  • Secrets no código. O modelo às vezes gera API keys placeholder que parecem reais o suficiente para ir pra produção. Aí acabam no GitHub. Aí acabam nas mãos de outra pessoa.

Treine seu time a fazer uma pergunta para cada função gerada por IA: "O que acontece se o input for hostil?"

Camada 5: O arquivo de regras OpenSSF

A OpenSSF — Open Source Security Foundation — publicou um Guia Padronizado de Instruções de Segurança para Assistentes de IA. É um arquivo de regras que você coloca na raiz do seu projeto. Toda ferramenta de IA que suporta instruções a nível de projeto lê automaticamente.

O arquivo cobre validação de input, encoding de output, autenticação, gerenciamento de sessão, criptografia, tratamento de erros e logging. Ao invés de escrever suas próprias regras de segurança do zero, use as deles — mantidas por profissionais de segurança, atualizadas regularmente e gratuitas.

Quanto isso te custa

Tempo. Cada camada adiciona fricção. Pre-commit hooks adicionam 5–15 segundos por commit. Scans de CI adicionam minutos ao seu pipeline. Review humano requer humanos que sabem como um SSRF se parece. O arquivo OpenSSF requer lê-lo uma vez e entender o que ele faz.

Falsos positivos vão te irritar. O Semgrep vai flagar código que na verdade está ok. Você vai gastar tempo investigando não-problemas. Esse é o imposto que você paga para pegar os reais.

E nada disso é à prova de falhas. O estudo da AppSecSanta descobriu que 22% das vulnerabilidades passaram por todas as ferramentas SAST testadas. Algumas brechas requerem testes dinâmicos — realmente executar o código e atacá-lo — para serem encontradas. Análise estática é necessária, mas não suficiente.

O que fazer na segunda-feira de manhã

Você não precisa implementar as cinco camadas até semana que vem. Comece com duas:

  1. Adicione instruções de segurança à configuração da sua IA. Copie o bloco de prompt da Camada 1. Cole no seu projeto. Cinco minutos.
  2. Instale o Semgrep como pre-commit hook. Dois comandos. Pronto antes do seu café esfriar.

Só isso já te coloca à frente da maioria dos times que estão fazendo deploy de código gerado por IA hoje. Adicione scanning de CI quando tiver uma sprint com fôlego. Adicione o arquivo OpenSSF quando alguém do time lê-lo e entendê-lo. Treine reviewers ao longo do tempo.

O novo normal

A taxa de vulnerabilidade em código gerado por IA caiu de aproximadamente 40% em 2024 para 25% em 2026. Progresso, claro. Nesse ritmo, chegamos em "aceitável" por volta de 2030. Você não pode esperar quatro anos.

Trate código gerado por IA como output de um dev júnior que digita a 500 palavras por minuto, transborda confiança e nunca ouviu falar de OWASP. Revise. Escaneie. Teste. Aí sim faça deploy.

A IA escreve código 10x mais rápido. Seu ferramental de segurança precisa acompanhar. As ferramentas existem. A única peça que falta é o hábito de usá-las.