Estudo mostra que modelos Claude só aplicam controles de segurança SOC 2 por padrão quando o padrão é citado explicitamente

O estudo parte de uma pergunta direta e prática: quando ninguém pede explicitamente por segurança, um modelo de linguagem aplica por conta própria os controles que um programa de conformidade SOC 2 exigiria — criptografia, acesso restrito, logging, retenção de dados? Os autores testaram três gerações de modelos Claude (Fable 5, Opus 4.8 e Opus 5) em quatro cenários realistas de infraestrutura: um CLI para S3, um serviço de autenticação, um módulo Terraform para RDS e um handler de upload de arquivos com dados pessoais, cada um gerado uma vez com um prompt neutro e outra vez com uma única frase mencionando SOC 2.

O resultado mais preocupante não é a taxa de conformidade em si, mas o que os autores encontraram ao verificar manualmente cada falha: o código gerado sob prompt neutro continha vulnerabilidades reais e exploráveis, incluindo um debugger Werkzeug acessível permitindo execução remota de código, um endpoint de download sem autenticação e um endpoint que retornava todos os nomes e e-mails armazenados — e todas essas falhas passaram despercebidas pelo checklist automático inicial dos próprios pesquisadores, só sendo capturadas na verificação manual.

A conformidade sob prompt neutro variou de 47% a 88%, e o padrão encontrado é revelador: controles que já fazem parte de como o modelo "normalmente" escreve determinado tipo de código (hashing de senha, `storage_encrypted` em Terraform) aparecem mesmo sem serem pedidos, enquanto controles que não fazem parte da concepção usual da tarefa (hardening de S3, retenção de dados, MFA) simplesmente não aparecem. Uma única frase citando SOC 2 elevou a conformidade para a faixa de 86-100% e eliminou as construções inseguras identificadas — um ganho de 23 a 50 pontos percentuais por uma frase — mas alguns controles fora da "concepção da tarefa" do modelo (MFA, flags de cookie, ciclo de vida de conta) continuaram ausentes mesmo com a menção ao padrão.

O achado tem implicação direta para qualquer organização usando modelos de linguagem para gerar infraestrutura ou código de produção: segurança não é um comportamento padrão emergente do modelo, é um comportamento que precisa ser explicitamente solicitado ou embutido em templates/prompts de sistema — e mesmo assim alguns controles continuam fora do escopo natural da tarefa como o modelo a entende. O estudo também aponta uma limitação metodológica importante: um scorer automático baseado em padrões discordou de avaliação semântica em 27 de 216 julgamentos, inclusive deixando passar um defeito real, reforçando que avaliação automatizada de segurança de código gerado por IA ainda não é confiável sem checagem semântica manual.