O teu modelo ficou mais inteligente. O teu código não ficou mais seguro.

A capacidade acumula-se. A segurança estagna.

Comecemos pelo que é genuinamente impressionante, porque o argumento não se aguenta se fingirmos que os modelos são fracos.

No FrontierBench v0.1, o Claude Opus 5 faz 43,3 % em esforço máximo, contra 18,7 % do Opus 4.8, 33,7 % do Fable 5 e 37,5 % do GPT-5.6 Sol. Entre duas versões do Opus, a pontuação mais do que duplicou. No SWE-bench Verified, o Fable 5 ronda os 95 %, e os 80 % no SWE-bench Pro, o conjunto difícil. O que um agente não sabia fazer há dezoito meses, hoje provavelmente faz.

Agora põe a curva de segurança no mesmo eixo. Várias medições independentes, académicas e industriais, desenham a mesma forma: correção sintática acima de 95 %, sucesso nas tarefas nos oitenta e noventa, e a fração de código gerado que passa um controlo de segurança encalhada a meio da escala, mais ou menos onde estava há dois anos. As duas linhas afastam-se.

“

Cada geração de modelo compra-te capacidade. Nenhuma geração de modelo te comprou segurança.

A razão não tem mistério assim que olhamos para a forma como estes modelos são treinados. A correção funcional tem um sinal limpo: os testes passam ou não passam, o benchmark sobe ou não sobe. Isso otimiza-se, com descida de gradiente e uma tabela pública. A segurança não tem equivalente. É uma propriedade não funcional, caríssima de anotar, em que a ausência de vulnerabilidade é indistinguível da ausência de verificação, e cuja falha só aparece meses depois, num incidente que ninguém liga ao treino. Seja qual for a pressão de otimização, não aponta para ali.

Há uma segunda razão, mais discreta, visível nos dados de treino. Algumas classes de vulnerabilidade arrastam décadas de correções documentadas e repetidas à exaustão em código público: injeção SQL, criptografia fraca, path traversal. Os modelos lidam com elas comparativamente bem, porque o padrão seguro é também o padrão estatisticamente dominante. As classes que exigem conhecer o runtime, o sistema operativo, o modelo de inquilinos ou a regra de negócio não têm corpus nenhum desse género. Não estão sub-representadas nos dados: estão ausentes.

O estado geral do problema tratámo-lo em o código gerado por IA é seguro?. Este artigo vai à pergunta mais estreita e mais acionável: dado esse estado, trocar o modelo ou trocar o prompt faz alguma coisa?

Por que razão trocar de modelo não é um controlo de segurança

Um modelo mais recente ajuda um pouco, e não onde as pessoas imaginam.

O que melhora com uma subida de versão é a capacidade de produzir código que funciona, e a capacidade de raciocinar sobre segurança quando se pergunta diretamente. Vale a pena parar neste segundo ponto, porque é aqui que o mecanismo da falha fica visível. Os modelos identificam com frequência a medida defensiva certa quando a colocas como pergunta. Depois escrevem o código final e omitem-na. A diferença não é de conhecimento, é de execução. O modelo não está em dúvida sobre se uma query deve ser parametrizada; está a otimizar, no momento da geração, para aquilo que se parece com uma tarefa terminada.

Esta distinção tem consequências comerciais diretas, porque prevê que compras te vão desiludir. Comprar um modelo mais inteligente para reduzir a densidade de vulnerabilidades é apostar na variável errada. Vais obter mais código funcional por hora, ou seja mais código por hora, ou seja mais daquilo que a tua taxa de vulnerabilidade for por hora. Se a taxa é plana e o volume triplica, a tua exposição absoluta triplica. Capacidade sem um controlo correspondente é caudal, e caudal não é segurança.

A escolha do modelo tem, sim, um efeito real, num único eixo: quanta carga de verificação te sobra. Um modelo que acerta nas classes de injeção na maioria das vezes deixa-te menos para apanhar. É um ganho de eficiência genuíno. Não é um controlo, porque é probabilístico, não auditado, e muda em silêncio cada vez que o fornecedor publica um novo checkpoint.

Por que razão dizer ao modelo para ser seguro também não é um controlo

Esta é a parte que a maioria do conteúdo de fabricantes ignora, incluindo, sejamos honestos, a versão preguiçosa do nosso próprio discurso. Se leste por aí que basta pôr instruções de segurança no contexto, os dados não sustentam isso.

A medição mais nítida até hoje chama-se "An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods", de Mohammed Kharma, Ahmed Sabbah, Mohammad Alkhanafseh, Mohammad Hammoudeh e David Mohaisen, submetida ao arXiv a 22 de maio de 2026. Cinco LLM, quatro linguagens (Java, C++, C e Python), vários métodos de engenharia de prompt, incluindo um construído de propósito para favorecer a tese da segurança: uma cadeia de raciocínio zero-shot atenta às fraquezas, que enriquece o prompt com contexto de segurança a partir de mapeamentos CWE para orientar o raciocínio do modelo.

O resultado, sustentado por testes de chi-quadrado, cabe numa frase do resumo: nenhuma redução estatisticamente significativa na frequência nem na densidade das vulnerabilidades, com nenhum método de prompt. O que essas estratégias mudam é a composição das categorias de CWE, com um efeito que varia com a linguagem. Ou seja, o prompt atento à segurança volta a dar as cartas das fraquezas que recebes. Não reduz quantas recebes.

O achado gémeo é provavelmente ainda pior para a teoria do prompt como controlo. "Minimal Prompt Perturbations Lead to Code Vulnerabilities: Prompt Fragility and Hidden-State Signals in Coding LLMs", arXiv, 29 de maio de 2026, mostra que alterações mínimas e perfeitamente inócuas de um prompt, acrescentar um comentário, reformular uma instrução, inserir texto inofensivo, empurram de forma fiável os modelos de código de volta para geração vulnerável. Não são jailbreaks adversariais. São retoques correntes, do género que acontece cem vezes por dia numa sessão real.

Lidas em conjunto, estas duas medições impõem uma restrição de desenho. Não podes pôr a tua postura de segurança no mesmo canal daquilo que estás a tentar restringir. Se a política vive no prompt, compete com a tarefa, com as convenções do repositório, com o ficheiro que o agente acabou de ler e com o que um contribuidor escreveu num ficheiro Markdown. Se a política vive numa barreira que avalia a ação, não compete com nada.

O que os benchmarks medem e o que não conseguem medir

Antes de tirar conclusões de números de benchmark, vale a pena saber de que são feitos, porque a leitura honesta é mais estreita do que os títulos.

Os benchmarks académicos sérios são bons e estão a melhorar. O CWEval oferece um benchmark de código multilingue e crítico em segurança que cobre 31 tipos de CWE em cinco linguagens, e o seu contributo é a avaliação orientada a resultados: julga funcionalidade e segurança em conjunto em vez de fazer correspondência de padrões. O RealSec-bench é construído a partir de repositórios Java reais de alto risco, 105 instâncias em 19 tipos de CWE, um afastamento deliberado dos fragmentos sintéticos. O SecureAgentBench vai mais longe e avalia a geração de código seguro em cenários de vulnerabilidade realistas em vez de prompts isolados.

Todos partilham três limites estruturais que nenhuma cobertura extra de CWE resolve.

Nada disto é um argumento contra os benchmarks. É um argumento contra tomar uma taxa de aprovação por um modelo de risco. Um modelo pode liderar todas as tabelas da secção anterior e continuar a ser a causa imediata do teu próximo incidente, porque o teu próximo incidente estará provavelmente na terceira coluna daquela grelha.

As três falhas que uma subida de versão não toca

Concretamente, é isto que continua exatamente igual de estragado depois de passares para o modelo mais recente e melhor pontuado que existe.

A lógica de negócio, que não tem benchmark nem assinatura

As classes de vulnerabilidade ricas em correções públicas são as que os modelos tratam melhor. As tuas regras de negócio, por outro lado, não têm uma única correção pública, porque existem só na tua base de código e, muitas vezes, só na cabeça de quem as especificou. Um agente capaz de escrever uma query parametrizada irrepreensível deixará de bom grado uma quantidade ficar negativa se nada no repositório lhe disse que as quantidades são positivas. É a falha que consideramos estruturalmente fora do alcance dos melhores modelos, e documentámo-la em falhas de lógica de negócio no código gerado por IA.

As ações do agente, que são uma superfície de ataque à parte

No momento em que o agente pode executar comandos, a pergunta de segurança deixa de ser só "este código está correto?" e passa a ser "de quem são as instruções que ele está a seguir?". Ficheiros do repositório como AGENTS.md e CLAUDE.md são carregados como política de projeto de confiança, o que os torna um canal de condução para quem consiga fazer commit. Descrevemos esse mecanismo e os incidentes com nome de 2026 em injeção por ficheiro de instruções. Um modelo mais capaz agrava isto em vez de melhorar, porque executa o plano hostil com mais competência.

As dependências que ele escolhe

Os modelos continuam a inventar nomes de pacotes e os atacantes continuam a pré-registá-los. Um modelo melhor alucina menos vezes, o que reduz a frequência sem mudar a forma do risco, e basta uma alucinação aceite. Ver o que é o slopsquatting.

Há um quarto ponto a acrescentar, mesmo que não seja uma questão de qualidade de código, porque é a prova mais clara de que a capacidade corta dos dois lados. A própria safety card da Anthropic para o Opus 5 relata que o modelo comprometeu com sucesso redes empresariais em oito de dez testes governamentais. Em torno do Fable 5, investigadores da Amazon encontraram forma de o levar a produzir código de demonstração de exploração para uma vulnerabilidade de software, o que levou a Anthropic a voltar a implantar o modelo com medidas de segurança reforçadas a 30 de junho de 2026, e o Fable 5 público encaminha agora para outro modelo as deteções de uso indevido ciber, biológico, químico e de destilação. Em separado, relatos da comunidade descrevem o classificador de segurança contornado no Claude Code ao enquadrar um pedido restrito como uma pergunta lateral /btw, explorando o intervalo entre a lógica de encaminhamento e o contexto principal da sessão.

Cada um destes pontos defende a mesma coisa: a fronteira avança dos dois lados da cerca ao mesmo tempo. Nenhum defende ficar num modelo antigo. Todos defendem que a barreira esteja fora do modelo.

Subida de versão contra aplicação, lado a lado

A linha que mais pesa numa decisão de compra é a segunda. Plano é mau, mas instável é pior, porque instável significa que nem consegues medir a tua própria postura. Se um retoque inócuo num prompt muda as propriedades de segurança do resultado, qualquer número que produzas sobre a qualidade do teu código gerado é a fotografia de um sistema que amanhã será diferente por razões que ninguém registou.

O que funciona de facto: aplicar em vez de instruir

Aceita os dois resultados de investigação e o desenho sai quase por si. Se a instrução não é fiável nem estável, o controlo tem de ser algo que age, no momento da ação, e que pode recusar. Na prática são três componentes, e vale a pena ser preciso sobre o papel de cada um, porque a tentação é afirmar que o primeiro faz tudo.

As regras no contexto sobem o chão. Não o fixam. Meter as regras da tua organização e o estado real do repositório no contexto do modelo melhora genuinamente o primeiro rascunho, e coloca a tua política à frente daquilo que o repositório afirma. Mas pelos dados acima, o contexto sozinho é uma melhoria probabilística, não uma garantia. Quem te disser o contrário está a vender além do que a investigação diz.

Os hooks são a parte determinista. Um hook avalia uma chamada a ferramenta antes de ela executar. Ler um ficheiro de credenciais, mandar um dump do ambiente para o curl, correr uma migração destrutiva, invocar uma ferramenta cuja descrição mudou desde ontem: são eventos discretos e inspecionáveis, e uma barreira sobre eles dispara ou não dispara. Não se convence com um prompt reformulado. É toda a razão da sua presença no desenho.

Os findings no ciclo eliminam a adivinha. O agente tem acesso em direto ao que os scanners encontraram no código, nas dependências, nos segredos, na infraestrutura e nos pipelines, pelo que uma alteração proposta é raciocinada contra o estado real do repositório e não contra um palpite. É também isso que lhe permite notar problemas de segunda ordem, por exemplo que o pipeline que lhe acabaram de pedir para alterar corre em eventos de fork com permissões de escrita.

O resumo honesto da nossa posição: o primeiro componente faz o modelo comportar-se melhor na maior parte das vezes, o segundo torna um conjunto concreto de resultados impossível, e o terceiro torna os dois primeiros exatos. Só o segundo é um controlo em sentido estrito. Preferimos dizê-lo com clareza a insinuar que um prompt é uma garantia, porque dois artigos afirmam agora o contrário.

E o corolário para o teu roteiro: este problema não se resolve à espera. Seja qual for a pontuação da próxima versão, conta com uma curva de segurança plana e um volume de código a subir.

Perguntas frequentes

Um modelo mais recente escreve código mais seguro?

Muito pouco, e não o suficiente para mudar os teus controlos. A correção funcional melhora bastante entre gerações enquanto a taxa de aprovação em segurança fica praticamente plana. Um modelo mais recente tende a lidar melhor com as classes bem documentadas como a injeção SQL ou a criptografia fraca, porque o padrão seguro é também o padrão comum nos seus dados de treino, e não melhora nas classes que exigem conhecer o teu runtime ou as tuas regras de negócio. Obténs mais código, com aproximadamente a mesma taxa de defeitos.

Que modelo escreve o código mais seguro?

As comparações publicadas produzem um ranking, e esse ranking muda a cada lançamento, o que é precisamente a razão para não montar um programa de segurança em cima dele. A leitura útil desses estudos é o agregado: a distância entre o melhor modelo e a média é muito menor do que a distância entre qualquer modelo e "seguro o suficiente para entrar em produção sem verificação". Escolhe um modelo por capacidade e custo, e põe um controlo à frente.

Ajuda dizer ao modelo para escrever código seguro?

Não de forma mensurável, pelos dados disponíveis. A avaliação de maio de 2026 de Kharma e coautores testou vários métodos de prompt em cinco LLM e quatro linguagens, incluindo uma cadeia de raciocínio enriquecida com mapeamentos CWE, e não encontrou redução estatisticamente significativa na frequência nem na densidade das vulnerabilidades. O prompt mudou que categorias de CWE apareciam, não quantas vulnerabilidades havia.

Se o prompt não funciona, para que servem as regras no contexto do agente?

Para duas coisas que uma teoria só de prompt subestima. Melhoram o primeiro rascunho, o que é um ganho de eficiência real mesmo sendo probabilístico, e colocam a política da tua organização no contexto do modelo à frente daquilo que um ficheiro do repositório não revisto afirme. O que não conseguem é garantir um resultado. É por isso que o hook existe ao lado delas, e é por isso que não apresentamos o contexto como a resposta inteira.

Podemos confiar nos benchmarks de segurança?

Os académicos são rigorosos e estão a melhorar. O CWEval cobre 31 tipos de CWE em cinco linguagens com avaliação orientada a resultados, o RealSec-bench é construído sobre repositórios Java reais de alto risco, e o SecureAgentBench visa cenários de vulnerabilidade realistas. Os limites são estruturais e não metodológicos: pontuam uma geração única e não sessões longas de agente, só conseguem testar fraquezas com uma classe nomeada, e não dizem nada sobre as ações do agente por oposição ao seu código.

Devemos ficar num modelo antigo por razões de segurança?

Não. Os modelos antigos não são mais seguros, são apenas menos capazes, pelo que obténs a mesma taxa de defeitos com menos produção. Os riscos próprios dos modelos de fronteira, um agente que executa um plano hostil com competência, tratam-se restringindo ações, não limitando a capacidade.

Isto significa que não se pode entregar código gerado por IA em segurança?

Pode, com a condição de a verificação e a aplicação fazerem parte do ciclo e não de uma etapa posterior. A falha não é "a IA escreve código mau", é "a IA escreve código mais depressa do que a revisão que devia verificá-lo". Para a versão ampla desse argumento, ver segurança dos agentes de código de IA.

Que única métrica seguir em vez da pontuação de segurança de um modelo?

Segue a fração de ações inseguras que foram recusadas em vez de revistas. Uma taxa de aprovação fala-te do checkpoint de um fornecedor. Uma taxa de recusa fala-te do teu próprio controlo, mede-se nos teus logs, e ao contrário de uma pontuação de benchmark não volta a zero quando alguém publica um modelo novo.