Can AI Write Compliant Code, and to What Extent? Evaluating SOC 2 Compliance of Claude Fable 5, Claude Opus 4.8, and Claude Opus 5 Across Four Use Cases

Resumo Técnico: Avaliando a Conformidade com SOC 2 de Código Gerado por IA

Declaração do Problema
Equipes de software estão delegando cada vez mais a geração de código de produção para modelos de linguagem de grande escala (LLMs), incluindo código que provisiona armazenamento, manipula credenciais e gerencia dados regulados. Embora pesquisas anteriores tenham medido extensivamente se os modelos introduzem vulnerabilidades (ex: SQL injection, estouros de buffer), este estudo aborda uma lacuna de conformidade distinta: se os modelos produzem código conforme quando nenhum requisito de segurança ou conformidade é explicitamente declarado.

Um controle pode estar ausente sem que qualquer linha de código esteja "errada". Por exemplo, um uploader de S3 que falha ao chamar put_bucket_encryption não contém um defeito sintático e passa em suítes de testes padrão, mas falha no controle SOC 2 para criptografia em repouso. Essa "invisibilidade" de controles ausentes no momento da autoria cria um risco onde o código gerado por IA parece funcional, mas falha em requisitos de auditoria. O estudo investiga duas questões primárias:

1. Quando os prompts são neutros (sem menção a segurança), os modelos aplicam controles esperados pelo SOC 2 (criptografia, acesso restrito, logging, retenção)?
2. O quanto uma única frase nomeando o padrão SOC 2 recupera a lacuna de conformidade?

Metodologia
O estudo empregou um design fatorial controlado envolvendo:

• Modelos: Três modelos de fronteira de um único fornecedor: Claude Fable 5, Claude Opus 4.8 e Claude Opus 5.
• Casos de Uso: Quatro cenários distintos abrangendo código de aplicação e infraestrutura:
  1. Uma ferramenta de linha de comando para S3 (boto3).
  2. Um serviço de autenticação (Flask/FastAPI).
  3. Um módulo Terraform para RDS.
  4. Um manipulador de upload de arquivos para dados pessoais.
• Condições: Cada caso de uso foi gerado duas vezes por modelo (24 gerações no total):
  • Rodada 1 (Neutro): Uma declaração de tarefa sem linguagem de segurança.
  • Rodada 2 (Direcionado): A mesma tarefa acrescida de uma única frase declarando que os dados são sensíveis e o artefato está sujeito ao SOC 2.
• Pontuação: O código foi avaliado contra rubricas binárias (12–15 itens por tarefa) mapeadas aos Critérios de Serviços de Confiança do SOC 2.
  • Itens Positivos: Controles que devem estar presentes (ex: criptografia).
  • Itens de Comissão: Atos inseguros que devem estar ausentes (ex: ACLs públicas).
  • Verificação: Um sistema de três avaliadores foi utilizado: um pontuador baseado em regex (R1), um graduador semântico cego (R2) e verificação manual humana (R3). Todas as falhas e atos inseguros sinalizados foram verificados manualmente.

Principais Descobertas

1. A Conformidade Não Provocada é Variável e Dependente de Ídioma
Sem instruções explícitas, a conformidade variou de 47% a 88%. O estudo descobriu que a conformidade acompanha se um controle faz parte do "idioma" padrão para aquele tipo de código, em vez da distinção entre código de aplicação vs. infraestrutura.

• Alta Conformidade: Controles como hashing de senha e storage_encrypted no Terraform apareceram sem provocação porque são padrões nesses contextos.
• Baixa Conformidade: Chamadas de endurecimento (ex: put_bucket_encryption do S3, put_public_access_block), políticas de retenção e ganchos de MFA foram frequentemente omitidos porque a descrição da tarefa não os exigia, e sua ausência não causa erros de tempo de execução.
• Infraestrutura vs. Aplicação: Contrariando a hipótese de que o código de infraestrutura seria mais fraco, o módulo declarativo Terraform pontuou cerca de 30 pontos acima do script imperativo boto3, pois o esquema do Terraform tornou os atributos de segurança mais visíveis para o modelo.

2. O Impacto de uma Única Diretriz
Adicionar uma única frase nomeando SOC 2 e a sensibilidade dos dados moveu todos os casos para 86–100% de conformidade, gerando ganhos de 23 a 50 pontos percentuais.

• A diretriz recuperou com sucesso controles ausentes como criptografia, registro de acesso e políticas de retenção.
• Limitações: Um "resto estável" de controles persistiu mesmo com a diretriz. Estes incluem ganchos de MFA, flags de cookie Secure/HttpOnly e gerenciamento de ciclo de vida de conta. Estes itens situam-se fora da concepção padrão do modelo para a tarefa e exigem nomeação individual para serem incluídos.

3. Construções Inseguras e Vulnerabilidades
Nas 16 gerações de prompt neutro, o estudo identificou três vulnerabilidades ativas que inicialmente foram perdidas por um checklist básico:

• X1: Um debugger Werkzeug alcançável permitindo execução remota de código (RCE).
• X2 & X3: Endpoints de download não autenticados e endpoints retornando todos os nomes/e-mails de usuários.
• X4 (Opus 5): Uma instância RDS configurada para descartar dados no encerramento fora de produção (via uma variável condicional).
• Nota: O checklist inicial encontrou zero defeitos; a lista foi expandida post-hoc para incluir categorias mais amplas (modo debug, quebra de autorização em nível de objeto, etc.), revelando esses problemas.

4. Escolha de Modelo vs. Engenharia de Prompt
A escolha do modelo teve o menor impacto nos resultados. Dois modelos da mesma geração (Fable 5 e Opus 4.8) diferiram em no máximo um item da rubrica em todas as células de comparação. O novo Opus 5 melhorou o desempenho nos casos mais fracos (Upload e RDS), mas a melhoria foi menor do que o ganho alcançado pela frase única do SOC 2. O estudo conclui que, para conformidade, otimizar a seleção do modelo é menos eficaz do que otimizar o prompt.

5. Confiabilidade de Medição e Limitações de Ferramental
O estudo destacou falhas significativas na varredura de conformidade automatizada para código de IA:

• Falha de Correspondência de Padrão: O pontuador de regex (R1) subestimou códigos bem projetados em 21 de 27 discordâncias com a graduação semântica. Ele falhou em reconhecer valores conformes expressos via variáveis (ex: backup_retention_period = var.days) ou lógica defensiva.
• Falsos Positivos (Passes Falsos): O pontuador de padrão aprovou o defeito do RDS porque o valor não conforme era computado via uma condicional (!local.is_prod) e nunca apareceu como um literal = true.
• Conclusão: Scanners de análise estática baseados em correspondência de texto são não confiáveis para código gerado por IA. Eles produzem tanto falsos negativos (perdendo defeitos reais) quanto falsos positivos (sinalizando código seguro). O estudo argumenta que verificações semânticas e verificação humana são necessárias.

Significância e Alegações
O artigo alega que o código gerado por IA requer a mesma verificação de controle que o código humano, pois controles omitidos não geram erros e passam em testes padrão.

• Sensibilidade ao Prompt: A conformidade é altamente moldada pelo prompt. Uma instrução genérica única pode recuperar a maioria dos controles ausentes, mas controles específicos e nomeados (como MFA) devem ser explicitamente solicitados.
• Aviso sobre Ferramental: As ferramentas de conformidade automatizadas atuais (correspondência de padrões) são insuficientes para auditar código de IA porque não conseguem resolver valores de configuração ou entender a intenção semântica.
• Remediação: Os autores propõem que "guardrails de agentes" (ex: um arquivo CLAUDE.md contendo uma lista de proibição e controles obrigatórios derivados de conjuntos vivos de SOC 2) são uma intervenção mais confiável do que depender de seleção de modelo ou prompts de turno único. Eles também sugerem que o ferramental "seguro por padrão" (wrappers que forçam criptografia/logging por padrão) é um alavancagem mais forte do que a engenharia de prompt.

O estudo é modesto em suas alegações, reconhecendo limitações como a seleção de modelos de um único fornecedor, o tamanho pequeno da amostra (uma geração por célula) e o fato de que a análise estática não pode medir a eficácia em tempo de execução. Ele posiciona seus achados como um limite inferior para os riscos de conformidade e um chamado para métodos de verificação mais robustos.