Cada iteração torna seu código menos seguro

Após dez rodadas de refinamento de código conduzido por LLM, 43,7% das cadeias de iteração continham mais vulnerabilidades que o código base do qual partiram.¹ O agente melhorou a funcionalidade. O agente passou nos testes. O código também ficou menos seguro a cada iteração — um padrão que os pesquisadores chamam de “desvio de especificação.” Ninguém percebeu porque o código melhorava em todas as métricas, exceto segurança.

Resumo

Um estudo de refinamento iterativo de código por LLM envolvendo três modelos (GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3) e 2.880 etapas de iteração revela um paradoxo: agentes otimizam para correção funcional enquanto degradam silenciosamente a segurança. Mitigações padrão falham. Adicionar ferramentas de análise estática de segurança (gates SAST) ao loop aumentou a degradação latente de 12,5% para 20,8%. O framework SCAFFOLD-CEGIS abordou o problema com quatro camadas de verificação, alcançando uma taxa de degradação latente de 2,1% com 100% de monotonicidade de segurança, ao custo de uma taxa de conclusão de tarefas de 77%. A descoberta importa para qualquer pessoa executando loops autônomos de agentes.

O paradoxo

Os pesquisadores testaram três LLMs (GPT-5-Nano, Claude Sonnet 4.5, DeepSeek-V3) em 24 tarefas de programação distribuídas em seis categorias de segurança (banco de dados, tratamento de entrada, autenticação, gerenciamento de recursos, criptografia, manipulação de caminhos), produzindo 288 cadeias de iteração e 2.880 etapas totais.¹ A descoberta: o desvio de especificação durante a otimização multiobjetivo causa degradação gradual da segurança ao longo das iterações sucessivas.

O mecanismo: quando um agente otimiza código ao longo de múltiplas rodadas, cada rodada foca em melhorias funcionais (correção de bugs, adição de recursos, aprovação de testes, melhoria de desempenho). As restrições de segurança competem com os objetivos funcionais pela atenção do agente. Ao longo de dez rodadas, o agente aprende (implicitamente, por acumulação de contexto) que mudanças funcionais produzem feedback positivo, enquanto restrições de segurança não produzem feedback algum. A lógica defensiva que não contribui para funcionalidade visível é simplificada, refatorada ou substituída por alternativas mais fracas.

A taxa de degradação de 43,7% vem de um estudo observacional separado que rastreou o GPT-4o ao longo de dez rodadas de iteração. O experimento principal comparou o SCAFFOLD-CEGIS com cinco abordagens de defesa existentes: segurança baseada em prompt, auto-refinamento, SAST pós-hoc, guarda por testes e guarda híbrida.¹ A comunidade de pesquisa já havia identificado a degradação iterativa como uma preocupação. Nenhuma das cinco alternativas resolveu o problema.

Um estudo independente de Shukla, Joshi e Syed, revisado por pares e aceito no IEEE-ISTAS 2025, corrobora o padrão.⁴ Os pesquisadores pegaram dez amostras de código em C e Java verificadas quanto à segurança, aplicaram quatro estratégias distintas de prompting ao longo de dez iterações cada (400 amostras no total) e mediram um aumento de 37,6% em vulnerabilidades críticas após apenas cinco iterações. A taxonomia de vulnerabilidades cobriu 12 categorias, incluindo segurança de memória, validação de entrada, implementação criptográfica e falhas de injeção. A consistência entre diferentes equipes de pesquisa, linguagens e metodologias de avaliação confirma que a degradação iterativa é uma propriedade da abordagem, não um artefato de uma única configuração experimental.

Por que gates SAST pioram o problema

A descoberta mais contraintuitiva: adicionar ferramentas de análise estática de segurança como gates entre iterações aumentou a degradação latente de 12,5% para 20,8%.¹

O artigo atribui a causa ao desvio de especificação durante a otimização multiobjetivo. Uma explicação complementar mapeia para um padrão conhecido no desenvolvimento de software humano: quando desenvolvedores dependem de linters e analisadores estáticos, eles escrevem código menos defensivo porque as ferramentas vão “pegar” os problemas. A mesma dinâmica provavelmente se aplica a agentes LLM. Quando o agente recebe feedback SAST entre iterações, duas coisas acontecem:

1. O agente otimiza para passar no scanner, não para escrever código seguro. Ferramentas SAST verificam padrões de vulnerabilidade conhecidos (SQL injection, XSS, buffer overflows). O agente aprende a evitar esses padrões específicos enquanto introduz fraquezas de segurança inéditas que o scanner não detecta.

2. O agente remove defesas “redundantes.” Se o scanner reporta que a validação de entrada na camada A é suficiente, o agente remove a validação na camada B durante a próxima iteração. A validação na camada B era defesa em profundidade, não redundância. O scanner não consegue distinguir entre as duas.

O resultado: a iteração com gate SAST produz código que passa nos scans de segurança, porém contém mais vulnerabilidades latentes do que a iteração sem gate. O ferramental cria uma falsa sensação de segurança que faz o agente ser menos cauteloso, não mais.

Qualquer pessoa executando um loop autônomo de codificação com gates SAST entre iterações deveria prestar atenção. Os gates não estão protegendo você. Os gates estão treinando seu agente a contornar a proteção.

O que o SCAFFOLD-CEGIS faz diferente

O framework SCAFFOLD-CEGIS adota uma abordagem diferente.¹ Em vez de verificar padrões de vulnerabilidade conhecidos, o framework impõe monotonicidade de segurança: nenhuma iteração pode tornar o código menos seguro que a iteração anterior.

Os resultados das três abordagens:

A arquitetura usa quatro camadas de verificação sequenciais, cada uma verificando uma propriedade diferente:¹

O framework adota o princípio CEGIS (counterexample-guided inductive synthesis): um loop fechado de geração de candidatos, verificação, feedback e regeneração. Em vez de usar verificadores formais, o sistema usa análise estática e verificação de âncoras semânticas, representando contraexemplos como relatórios estruturados de falha.¹ Se qualquer camada rejeitar uma iteração, o sistema reverte para a versão anterior em vez de tentar corrigir a regressão.

O trade-off é real: SCAFFOLD-CEGIS alcançou uma taxa de conclusão de tarefas de 77,14%, comparado a taxas de conclusão mais altas para abordagens menos seguras.¹ A monotonicidade de segurança custa produtividade. O framework rejeita iterações que um sistema menos rigoroso aceitaria e aprimoraria. Se o trade-off vale a pena depende de você valorizar mais garantias de segurança ou throughput.

O insight principal: reverter em caso de falha em vez de iterar sobre a falha. Loops com gate SAST padrão detectam um problema e pedem ao agente para corrigi-lo, produzindo outra iteração que pode introduzir novos problemas. O SCAFFOLD-CEGIS detecta um problema e descarta a iteração inteiramente. A garantia de monotonicidade vem de nunca aceitar uma regressão, não de detectar e corrigir regressões.

Conexão com o design de harnesses de agentes

A descoberta se conecta diretamente a como profissionais constroem camadas de orquestração em torno de CLIs de agentes.² Os sete modos de falha que documentei a partir de mais de 500 sessões autônomas incluem vários que o paradoxo do refinamento iterativo explica: agentes que passam nos testes enquanto degradam a qualidade do código, agentes que otimizam para a métrica errada, agentes que removem restrições de segurança durante refatoração.

Os hooks de julgamento que descrevi em “Anatomy of a Claw” abordam o problema de degradação por um mecanismo diferente. quality-gate.sh bloqueia relatórios de conclusão que não possuem evidências. filter-sensitive.sh captura exposição de credenciais antes que cheguem ao disco. recursion-guard.sh limita a profundidade de criação de agentes. Cada hook impõe uma propriedade de monotonicidade: o sistema não deve piorar em uma dimensão específica conforme o agente itera. O padrão de constituição em tempo de execução estende a mesma ideia: regras de governança embutidas que o agente não pode sobrescrever durante a execução.

O sistema autoresearch de Karpathy usa o mesmo padrão.³ O harness de avaliação mantém melhorias e descarta regressões via gerenciamento de branches Git. A métrica de treinamento (bits de validação por byte) serve como a restrição de monotonicidade. Nenhum resultado de experimento que degrada a métrica sobrevive.

Três sistemas independentes (pesquisa em verificação formal, infraestrutura de pesquisa em ML, harnesses de agentes em produção) convergem para o mesmo princípio de design: nunca itere sobre uma falha; sempre reverta em caso de falha. Dar ao agente uma segunda chance de corrigir uma regressão produz resultados piores do que descartar a regressão e tentar uma abordagem nova.

O que profissionais devem fazer

Três ações concretas baseadas nas descobertas:

Audite seus loops de iteração quanto à monotonicidade de segurança. Se seu agente executa múltiplas rodadas de modificação de código, compare a postura de segurança em cada rodada contra o baseline original, não apenas contra a rodada anterior. O desvio cumulativo é invisível quando você compara apenas iterações adjacentes.

Não dependa apenas de gates SAST. Os resultados com gate SAST (20,8% de degradação, pior que sem gate) devem mudar como você projeta loops de feedback. Ferramentas SAST são valiosas para detectar padrões conhecidos em código escrito por humanos. Em loops de iteração de agentes, as ferramentas se tornam alvos de otimização que o agente contorna. Use SAST como um sinal entre vários, não como um gate.

Implemente reverter-em-falha, não corrigir-em-falha. Quando uma iteração introduz uma regressão, descarte a iteração inteiramente. Não peça ao agente para corrigir a regressão em uma iteração subsequente. A tentativa de correção é em si uma iteração sujeita à mesma dinâmica de degradação. Uma implementação mínima usando Git:

#!/bin/bash
# monotonicity-gate.sh — revert on security regression
BASELINE_HASH="$1"  # git hash of the known-good baseline

# Run your security checks against current state
CURRENT_VULNS=$(semgrep --config auto --json . | jq '.results | length')
BASELINE_VULNS=$(git stash && git checkout "$BASELINE_HASH" -q && \
    semgrep --config auto --json . | jq '.results | length' && \
    git checkout - -q && git stash pop -q)

if [ "$CURRENT_VULNS" -gt "$BASELINE_VULNS" ]; then
    echo "Security regression: $BASELINE_VULNS → $CURRENT_VULNS vulnerabilities"
    git checkout "$BASELINE_HASH" -- .
    exit 2  # Block the iteration
fi

O padrão compara contra o baseline original, não contra a iteração anterior. O desvio cumulativo é a ameaça.

Perguntas frequentes

O refinamento iterativo sempre degrada a segurança?

Nem toda cadeia de iteração degrada. O estudo SCAFFOLD-CEGIS descobriu que 43,7% das cadeias continham mais vulnerabilidades após dez rodadas, o que significa que 56,3% mantiveram ou melhoraram a postura de segurança.¹ Um estudo independente do IEEE-ISTAS encontrou um aumento de 37,6% em vulnerabilidades críticas após cinco iterações.⁴ A preocupação é que a degradação é silenciosa: o agente produz código funcionalmente correto que passa nos testes enquanto as propriedades de segurança se deterioram. Sem verificações explícitas de monotonicidade de segurança, a degradação passa despercebida até que uma vulnerabilidade seja explorada.

Por que gates SAST pioram o problema em vez de melhorá-lo?

Ferramentas de análise estática verificam padrões de vulnerabilidade conhecidos. Quando um agente recebe feedback SAST entre iterações, ele otimiza para passar no scanner em vez de escrever código seguro. O agente evita padrões sinalizados enquanto introduz fraquezas inéditas que o scanner não consegue detectar. O agente também remove camadas de defesa em profundidade que o scanner marca como redundantes. O efeito líquido é código que passa nos scans, mas contém mais vulnerabilidades latentes do que código produzido sem gate SAST.

O que é monotonicidade de segurança e como o SCAFFOLD-CEGIS a impõe?

Monotonicidade de segurança significa que nenhuma iteração pode tornar o código menos seguro que a iteração anterior. O SCAFFOLD-CEGIS impõe essa propriedade por meio de quatro camadas de verificação sequenciais: correção (suíte de testes), monotonicidade de segurança (comparação SAST entre iterações), budget de diff (limitação da escala de mudanças) e integridade de âncora (verificação de que elementos de código críticos para segurança sobrevivem). O framework usa o princípio CEGIS (counterexample-guided inductive synthesis), representando contraexemplos como relatórios estruturados de falha em vez de provas formais. Se qualquer camada rejeitar uma iteração, o sistema a descarta inteiramente em vez de passá-la ao agente para correção. O trade-off: taxa de conclusão de tarefas de 77%, menor que abordagens menos rigorosas.

Qual a diferença entre reverter-em-falha e corrigir-em-falha em loops de agentes?

Corrigir-em-falha detecta um problema e pede ao agente para corrigi-lo na próxima iteração. A tentativa de correção está sujeita ao mesmo desvio de especificação que causou a regressão original, frequentemente introduzindo novos problemas. Reverter-em-falha descarta a iteração inteira e retorna ao último estado conhecido como bom. O agente recomeça do zero com um baseline limpo em vez de acumular patches corretivos. O gerenciamento de branches Git torna a reversão trivial na prática.

Posso aplicar essas descobertas ao meu workflow existente de Claude Code ou Codex?

Sim. As três ações na seção para profissionais se aplicam a qualquer loop de agente que modifica código ao longo de múltiplas rodadas. Audite seus loops de iteração comparando a postura de segurança contra o baseline original (não apenas contra a iteração anterior). Trate a saída do SAST como um sinal entre vários, em vez de um gate. Quando uma iteração introduzir uma regressão, use git checkout ou git revert para descartar a mudança inteiramente em vez de pedir ao agente para corrigi-la. O padrão de harness baseado em hooks fornece um modelo concreto de implementação para codificar essas verificações como gates automatizados.

Fontes