Prompt de segurança não é controle: como provar propriedades no software gerado por IA

Escrever “use boas práticas” ou “gere código seguro” no prompt pode orientar o modelo. Não cria, por si só, uma propriedade verificável no sistema entregue. O mesmo gerador que recebeu a instrução não pode ser a única autoridade a declarar que a cumpriu.

Este Evidence Brief parte do paper Prompt Structure Redistributes, Not Reduces para separar quatro camadas frequentemente misturadas: orientação de geração, comportamento produzido, finding de ferramenta e risco aceito. O estudo sustenta a necessidade dessa separação; o contrato técnico abaixo é uma proposta profissional da Trustyu Forge, não uma conclusão experimental dos autores.

O que foi medido

Os pesquisadores usaram 424 tarefas Python de um dataset sintético orientado a vulnerabilidades. Cada tarefa passou uma vez por cinco variantes de prompt e dois modelos — GPT-4o e LLaMA 3.1-8B — em um desenho zero-shot. São 4.240 interações. Outputs com Python válido foram analisados com Bandit e CodeQL.

A primeira variável era compliance de geração, não segurança. No GPT-4o, outputs inválidos caíram de 338 em 424 tarefas no prompt mínimo para 37–52 nos prompts estruturados. No LLaMA, a resposta foi menos estável. Um prompt estruturado, portanto, mudou fortemente a chance de haver código para analisar — e alterou o denominador das comparações seguintes.

Condicionado ao código válido, orientações de segurança não reduziram de forma consistente a prevalência total de fraquezas detectadas. No GPT-4o, findings de alta severidade passaram de 20,8% para 13,6%, enquanto os de baixa severidade foram de 32% para 43,5%. Os efeitos do LLaMA foram menos consistentes. O resultado observado foi redistribuição dependente do modelo, não eliminação uniforme.

O que esses números não provam

• o corpus não representa aplicações reais em produção;
• Python, dois modelos e uma geração por configuração não sustentam generalização universal;
• findings de Bandit e CodeQL são sinais estáticos, não confirmação de explorabilidade;
• ferramentas estáticas podem produzir falsos positivos e negativos;
• o estudo não executou um programa amplo de testes funcionais e dinâmicos;
• a auditoria manual de relevância e deriva cobriu 15 das 424 tarefas;
• o pacote de replicação está disponível, mas não havia replicação independente no corte deste brief.

O próprio paper relata comportamentos relevantes em saídas não sinalizadas pelas duas ferramentas e declara que runtime, contexto e lógica exigem análises complementares. Um resultado verde reduz uma classe de incerteza; não encerra a análise de segurança.

Compliance, correção e segurança são gates diferentes

Um prompt pode influenciar o primeiro gate e ajudar nos seguintes. Ele não deve ter autoridade para dispensá-los. [HARNESS31-C2]

Deriva semântica também precisa de teste

Na amostra manual do paper, prompts de segurança mais fortes levaram o GPT-4o a substituir ou remover construções inseguras explicitamente pedidas. A deriva semântica passou de 3/15 no baseline estruturado para 9–10/15 nas variantes posteriores. Como o benchmark contém pedidos deliberadamente perigosos, trocar a implementação pode ser desejável. Ainda assim, reduzir findings por alterar o comportamento não prova que a implementação preservou a decisão de produto.

Por isso, segurança e fidelidade à spec não devem competir dentro do texto do prompt. A spec declara o comportamento autorizado e suas invariantes. O threat model declara abuso, ativos e fronteiras. Os testes demonstram as duas coisas em mecanismos separados.

Contrato técnico: orientação não pode virar autoridade

1. Especificação antes da geração

Registre funcionalidade, dados, identidades, capacidades, dependências, limites, casos proibidos e critérios de aceite. Texto ambíguo no prompt deve permanecer risco explícito, não requisito implicitamente “entendido” pelo modelo.

2. Controles fora do modelo

Autorização, isolamento, segredos, políticas de rede, limites de recurso, proteção de dados e release gates precisam existir como mecanismos de plataforma. O modelo pode sugerir configuração; não deve reescrever silenciosamente a política que avalia seu próprio output.

Workspace separado ajuda a reduzir colisões, mas não equivale a sandbox com egress, identidade, capabilities e recursos controlados. [R1-C2]

3. Verificação multimétodo

Combine mecanismos conforme o risco:

• lint, tipos e build para integridade básica;
• testes unitários, de contrato e regressão para comportamento;
• SAST e análise semântica para padrões e fluxos conhecidos;
• SCA, SBOM e policy para dependências e proveniência;
• testes negativos, fuzzing ou DAST quando a superfície justificar;
• revisão especializada para identidade, autorização, criptografia, dados e infraestrutura;
• evals quando o comportamento do modelo permanecer dentro do produto.

Nenhuma ferramenta individual é um certificado. Divergências, suppressions e áreas não cobertas entram no registro de risco.

4. Autoridade e segregação

Quem gera pode acionar testes e propor correções. Quem verifica precisa ter critério protegido. Quem aceita o risco precisa estar identificado e autorizado. Papéis distintos só criam contraponto quando preservam permissões, inputs, findings e decisão; nomes diferentes no prompt não provam independência. [R1-C3]

5. Release ligado ao artefato exato

Checks precisam apontar para o commit avaliado. O build precisa gerar um artefato identificado por digest. A aprovação precisa referenciar esse mesmo alvo, e a promoção deve produzir receipt. Se um novo push muda o código, evidências antigas deixam de autorizar o release.

Evidence Packet mínimo

Para cada mudança assistida por IA com impacto material, preserve:

• spec, threat model e decisão que iniciaram o trabalho;
• fornecedor/modelo quando disponível, configuração e hash do prompt reutilizável;
• commit-base, diff e identidade do executor;
• versões e configurações dos verificadores;
• testes executados, resultados e artefatos brutos relevantes;
• findings confirmados, descartados, mitigados ou aceitos, com justificativa;
• suppressions e exceções com owner e validade;
• aprovação humana ligada ao commit e ao digest do artefato;
• receipt de promoção, smoke test, observabilidade e rollback;
• limitações conhecidas e próxima revalidação.

Se a organização só consegue mostrar o prompt “seguro”, ela possui uma intenção. Se mostra controles, resultados, autoridade e artefato, possui evidência.

Gate proporcional ao risco

A tabela é orientação profissional, não resultado do paper. O perfil exato depende de impacto, exposição, reversibilidade e obrigações do produto.

O que este brief prova — e o que não prova

O estudo oferece evidência de que estrutura de prompt pode alterar compliance, severidade e composição de findings em um benchmark controlado. Não prova que prompts são inúteis, que um modelo é universalmente inseguro ou que os findings encontrados seriam exploráveis em produção.

O brief propõe que prompts de segurança permaneçam no fluxo como orientação de defesa em profundidade. A alegação de segurança, porém, precisa se apoiar em propriedades especificadas, verificadores protegidos, autoridade explícita e evidências ligadas ao software exato.

Fontes diretas

• Paper no arXiv
• Versão HTML completa
• Pacote de replicação no Zenodo
• Dataset de origem
• Bandit
• CodeQL
• NIST SP 800-218 — Secure Software Development Framework

Conclusão

“Faça seguro” é uma instrução útil. “Foi verificado, aprovado e promovido sob estes controles” é uma afirmação governável.

Na engenharia AI-native, o prompt inicia o trabalho. Arquitetura, testes, authority e Evidence Packet decidem se o resultado pode operar.