Daniel Meppiel, responsável pelo go-to-market do Agentic SDLC na Microsoft e autor de The Agentic SDLC Handbook, publicou uma proposta sobre a forma como as empresas podem confiar em código produzido por agentes de IA sem terem de rever cada linha. Antes da Microsoft, trabalhou em sistemas distribuídos no CERN e em ferramentas para programadores no GitHub e na Sonar. O ensaio, intitulado "Agent Contracts and Receipts: toward verifiable agentic software factories", saiu a 4 de novembro de 2026 no seu site, The AI Native Mind. Nasce da palestra que deu na aiDevCon NYC, "Version your factory, not just your code", e é acompanhado de uma especificação no GitHub que o autor classifica como rascunho 0.1, "um convite, não uma norma".
O ponto de partida é um estrangulamento que, segundo Meppiel, as grandes empresas encontram repetidamente. Os agentes de programação tornaram barato gerar alterações, mas cada pull request continua à espera de que a integração contínua repita todos os testes e de que alguém o reveja. Os classificadores de risco que aprovam sozinhos as alterações pequenas ajudam, admite, mas mexer na aprovação de pagamentos nunca é de baixo risco, e um classificador só avalia a alteração em si, não se o sistema que a escreveu é o que a empresa autorizou. A tese do autor é que a confiança não pode vir do modelo nem da leitura do que ele produz: tem de vir do sistema de produção, concebido e atestado como qualquer cadeia de fornecimento de software.
A peça central é o Agent Contract, um único ficheiro versionado que descreve uma tarefa de um agente, à semelhança da descrição de funções de um novo colaborador. Indica os ficheiros de que precisa e os que entrega, importa competências (skills) com versões fixas, define um orçamento de tentativas e de segundos e enumera as verificações que vão julgar o resultado, fixadas antes da execução. Os contratos encadeiam-se num grafo a que Meppiel chama fábrica de software agêntica, e o conjunto recebe uma só versão e uma impressão digital, um resumo criptográfico que abrange todos os contratos, verificações e competências. A fábrica não depende de um agente concreto; hoje corre no GitHub Copilot CLI ou no OpenCode.
Cada execução concluída deixa um recibo, um pacote in-toto sobre os ficheiros exatos que foram entregues. Inclui proveniência SLSA com a versão da fábrica, os passos, o agente, o modelo e o commit de base; um resultado de teste in-toto por cada verificação declarada; e um ABOM, uma lista de materiais do agente em formato CycloneDX com as competências e pacotes fornecidos, cada um fixado pelo respetivo hash. Para o autor, o modelo clássico da cadeia de fornecimento tem de mudar em dois pontos. Como o trabalho de um agente não se reconstrói byte a byte, um processo separado, sem agente nem credencial de modelo, volta a correr as verificações sobre os ficheiros entregues. E como o agente é o ator menos fiável, nunca assina: um workflow de CI fixado, fora do seu alcance, valida o recibo e assina-o com o Sigstore.
Por fim, há uma única verificação obrigatória no momento do merge. Um ficheiro de política gerido pela equipa de segurança, o apm-policy.yml, enumera as impressões digitais das fábricas aprovadas, o assinante de confiança, as origens de competências permitidas e as competências revogadas; cada repositório pode apertar as regras da organização, mas nunca aliviá-las. A verificação lê a política a partir do ramo de base, procura cada ficheiro alterado pelo seu resumo SHA-256 no arquivo de atestações do assinante e chumba tudo o que a entrega assinada não cobre. Na demonstração, o pedido de um banco fictício para reter transferências elevadas para novos beneficiários deu origem a um pull request real num repositório de pagamentos de teste, saído de uma fábrica com cinco contratos e onze verificações; segundo o autor, a verificação demorou 22 segundos.
Meppiel é claro quanto aos limites. Um resultado verde indica que fábrica aprovada produziu a alteração e que verificações passaram, não que o código esteja certo, pelo que vale tanto quanto as verificações. Não se reivindica nenhum nível de build SLSA, os modelos ficam registados mas não são confirmados, a revogação trava novas entregas sem retirar código já integrado e os recibos gerados num portátil não são assinados. O autor sublinha ainda que saber que competências o agente recebeu não prova que as tenha seguido.
A proposta tem código por trás, em dois projetos de código aberto criados pelo próprio Meppiel. O APM, o Agent Package Manager da Microsoft, instala as fábricas e fixa cada competência a um commit e a um hash de conteúdo, sob uma política única para toda a organização; o ensaio refere que o Dependabot já suporta atualizações de versão do APM. O APMX, que descreve como uma implementação independente e experimental, executa as fábricas no agente escolhido, escreve os recibos e fornece a verificação através do comando apmx audit. Garante que nenhum dos dois é obrigatório para usar o formato e convida as comunidades SLSA, in-toto e CycloneDX, e qualquer interessado, a criticar o rascunho nas discussões do GitHub.