Agentes com execução isolada e checkpoints verificáveis

Um agente recebe uma issue, abre o repositório, altera o código e prepara um patch. Até aqui, seu trabalho pode permanecer dentro de um ambiente descartável. A fronteira muda quando esse mesmo agente tenta decidir se a alteração está correta e promovê-la. Nesse ponto, uma hipótese produzida por software passa a afetar uma branch compartilhada, um serviço ou dados que outras pessoas usam.

Minha proposta é manter essa fronteira explícita: o agente pode preparar o patch em isolamento, mas não deve validá-lo e promovê-lo sozinho. A arquitetura se apoia em três pilares: conter a execução, produzir um checkpoint verificável e promover de acordo com o risco. Não apresento essa composição como consenso nem como relato de operação em grande escala. É uma proposta arquitetural em evolução, construída a partir de controles já conhecidos em segurança, entrega de software e observabilidade.

A distinção importa. NIST, Kubernetes, SLSA, in-toto, OpenTelemetry e OPA documentam princípios e mecanismos úteis. Eles não definem, em conjunto, uma arquitetura pronta para agentes. Aqui eu os adapto a um problema específico: delegar trabalho aberto sem delegar ao mesmo processo a autoridade final sobre sua própria saída.

A fronteira entre preparar e promover

Um pipeline convencional percorre etapas conhecidas. Um agente escolhe passos, interpreta respostas e decide qual ferramenta chamar. A Anthropic diferencia agentes de workflows predefinidos e recomenda acrescentar agência quando ela melhora resultados mensuráveis.^[7] É a orientação de um fornecedor, não uma regra universal. O trade-off permanece: flexibilidade cria mais trajetórias para conter e verificar.

Considere um caso hipotético. Um agente deve corrigir a validação de um campo em uma API. Ele pode analisar o código, consultar documentação, editar uma cópia do repositório e executar testes. Nenhuma dessas ações precisa alcançar a branch principal. O risco cresce quando ele ganha credenciais para alterar o repositório remoto, modificar a suíte que julgará o próprio patch ou acionar um deployment.

Autonomia depende do alcance concedido em cada execução. Em vez de uma falsa fórmula numérica, proponho descrevê-lo como um vetor de política: recursos, verbos, ambiente, volume, duração, externalidade e reversibilidade. As dimensões não têm escala universal nem devem ser multiplicadas; tornam a autorização legível e comparável.

O NIST SP 800-207 rejeita confiança implícita baseada apenas na localização de rede e exige autenticação e autorização antes do acesso.^[2] Neste artigo, adapto esse princípio tratando cada execução como uma identidade de workload com credenciais curtas e limitadas à tarefa. Isso não transforma a proposta em uma implementação de zero trust. Apenas evita que “está dentro da rede” vire permissão para ler qualquer dado ou executar qualquer operação.

Essa separação cria três papéis. O proponente prepara o candidato. O validador testa o artefato e as evidências sem herdar a autoridade do proponente. O promotor aplica a política e move apenas o candidato aprovado. Os papéis podem ser implementados por automação, pessoas ou ambos. O requisito é independência de autoridade. Outro agente com o mesmo modelo, prompt, credenciais e contexto pode repetir o mesmo modo de falha; conforme o risco, a validação precisa também de ambiente limpo, ferramentas diferentes e testes determinísticos.

Pilar 1: conter a execução

Isolamento deve responder ao modelo de ameaça. Um container sem privilégio pode bastar para análise local. Código não confiável, segredos ou ferramentas de infraestrutura podem justificar uma sandbox mais forte, VM ou microVM. O RBAC do Kubernetes ajuda a limitar escopo, mas namespaces não isolam todos os recursos do cluster.^[3] A fronteira escolhida precisa resistir às ameaças plausíveis para aquela tarefa.

Para o agente do exemplo, eu começaria com uma imagem versionada, filesystem limitado ao repositório necessário, usuário sem privilégio, teto de CPU e memória, prazo máximo e descarte ao final. A rede sairia bloqueada ou restrita aos destinos exigidos pela tarefa. Dependências viriam de registries controlados. Segredos só seriam expostos quando uma operação específica precisasse deles.

Essa é também uma forma de aplicar menor agência. Em vez de entregar um shell com uma credencial ampla, o orquestrador pode oferecer operações estreitas, como consultar logs de um serviço, criar uma pull request ou propor um plano de infraestrutura. A ferramenta valida argumentos fora do modelo e usa uma identidade própria para cada efeito.

Prompt injection entra aqui como ameaça, não como tema separado. A OWASP registra que não existe mitigação infalível dentro do modelo e recomenda limitar privilégios, restringir comportamento e validar saídas.^[10] Um texto recuperado de issue, e-mail, página web ou resultado de ferramenta deve continuar sendo dado não confiável. Ele não pode aumentar permissões, mudar a política nem redefinir o objetivo autorizado. Restringir egress e reduzir dados no contexto diminuem oportunidades de exfiltração dentro do modelo de ameaça, mas não oferecem garantia absoluta contra todo canal lateral. Canary tokens podem sinalizar alguns acessos indevidos; são detecção complementar, não bloqueio.

Na supply chain, plugins, actions e servidores de ferramentas são código privilegiado de terceiros. Quando houver suporte, dependências podem ser fixadas por digest e atualizadas por processo verificado. Assinaturas, provenance e SBOM ajudam a verificar origem; não provam segurança.

Concorrência também é uma propriedade da contenção. O default prudente é não compartilhar estado mutável entre agentes sem isolamento e controle comprovados. Overlays copy-on-write, workspaces transacionais ou locking podem permitir concorrência segura em alguns contextos. Antes da promoção, porém, o estado-base do patch precisa ser comparado ao estado atual. Se mudou, o candidato deve ser reconciliado e validado outra vez, inclusive contra conflitos semânticos em schemas, contratos e políticas.

Pilar 2: produzir um checkpoint verificável

Um commit identifica conteúdo. Não informa, sozinho, qual objetivo orientou a mudança, de onde vieram os inputs, quais testes rodaram ou quem autorizou o próximo passo. Nesta proposta, checkpoint verificável é o envelope imutável que conecta seis elementos: objetivo e restrições, estado-base, artefato candidato, evidências de validação, política aplicável e estratégia de reversão ou compensação.

O envelope pode registrar identidade da execução, versões do modelo e do harness, digest da imagem quando disponível, ferramentas e efeitos externos. Para reproduzir a validação, hashes não bastam. Conteúdo web, respostas de API, relógio, aleatoriedade e demais estados externos precisam ser capturados, versionados ou referenciados por snapshots. Em ambientes estocásticos, o critério é equivalência do artefato e das validações dentro de tolerâncias definidas, não uma trajetória idêntica.

SLSA e in-toto oferecem conceitos estabelecidos para provenance e integridade da cadeia de software.^[4]^[5] O NIST AI 600-1 também trata de governança, provenance e histórico de testes.^[1] Minha proposta adapta esses controles ao checkpoint; nenhuma dessas fontes especifica esse envelope. O GitHub ressalta que uma attestation comprova origem e integridade, não segurança.^[6] A política ainda precisa avaliar a evidência.

O checkpoint separa evidência de auditoria. O validador recebe artefato, critérios e resultados relevantes. A auditoria pode reter eventos adicionais, com remoção de segredos, acesso controlado e prazo de retenção. Registros append-only ou assinados ajudam, mas assinatura isolada não garante completude nem imutabilidade. O armazenamento deve resistir a adulteração e preservar o vínculo entre tarefa, artefato e decisão.

Efeitos externos merecem tratamento próprio. Se uma ferramenta cria tickets, cobra clientes ou envia mensagens, retries não podem duplicar o efeito. Uma chave de idempotência é uma opção quando o provedor a oferece; ela deve ser opaca, estável e limitada ao tenant e à operação. Outbox, ledger ou deduplicação podem ser mais adequados em outros sistemas. Não há uma fórmula obrigatória.

Rollback tampouco nasce da existência de uma versão anterior. Um deployment só é reversível quando esse caminho foi testado e não depende de schema, configuração, dados ou integrações incompatíveis. O Kubernetes mantém histórico e permite reverter o template de um Deployment, mas não reverte o sistema inteiro.^[14] Quando desfazer não for possível, o checkpoint deve descrever compensação, contenção do dano ou o motivo para exigir aprovação antes do efeito.

Pilar 3: promover por risco

O checkpoint prepara uma decisão; ele não a toma. O promotor recebe o digest do candidato, a identidade de quem o produziu, os resultados de validação, o risco e as aprovações exigidas. Ferramentas de policy as code, como OPA, podem separar a decisão do mecanismo que a executa e devolver permitir ou negar com uma justificativa auditável.^[12]

Como default ilustrativo, não como padrão, R0 pode cobrir leitura pública; R1, escrita em branch ou sandbox; R2, merge ou mudança interna comprovadamente reversível; R3, produção, dinheiro, dados pessoais ou efeitos difíceis de compensar. Materialidade, compliance e controles compensatórios podem mudar a classificação.

A participação humana deve acompanhar essa materialidade. Pedir um clique a cada tool call produz fadiga e pouco entendimento. Em pesquisa observacional sobre seus produtos, a Anthropic encontrou usuários experientes usando mais autoaprovação e também interrompendo mais execuções.^[8] O resultado não estabelece causalidade nem se generaliza automaticamente, mas é consistente com uma supervisão baseada em visibilidade e capacidade de intervir.

Em risco alto, a aprovação deveria mostrar objetivo, mudança semântica, evidências, efeitos previstos, risco residual e resposta a falhas. Um transcript longo não substitui essa síntese. Em riscos menores, validação independente, política e amostragem podem bastar. Pessoas entram onde seu julgamento muda a decisão.

Começar pequeno e medir o que importa

A proposta ainda precisa ser testada e ajustada em cada contexto. Eu começaria por uma classe estreita de tarefa, com feedback verificável e efeito restrito: corrigir um bug simples, atualizar uma dependência ou preparar uma refatoração sem mudança de comportamento. O agente trabalha em ambiente efêmero, produz o checkpoint e para. Outro processo valida. Só então a política decide se o candidato avança.

OpenTelemetry oferece uma base vendor-neutral para correlacionar traces, métricas e logs.^[11] A execução pode ser observada como objetivo, ferramentas, efeitos, validações e decisão, sem guardar raciocínio interno. IDs correlacionáveis permitem medir tempo até evidência, custo por tarefa aceita, falhas e intervenções humanas úteis.

O AgentDojo mostrou, em sua configuração experimental, que defesas reduziram mas não eliminaram ataques de prompt injection, e que os modelos avaliados resolveram menos de 66% das tarefas mesmo sem ataque.^[9] Esses números não descrevem uma taxa universal de produção. Eles lembram que sucesso em demonstrações não autoriza ampliar permissões sem medição no ambiente real.

Métricas DORA podem acompanhar o piloto como sinais observacionais de fluxo e estabilidade, não como prova causal do valor do agente. O relatório de 2024 encontrou associações entre adoção de IA e resultados de entrega na amostra estudada; isso não demonstra que IA causou melhora ou piora.^[13] A comparação útil é local: qualidade aceita, tempo até evidência válida, falhas ou efeitos indevidos e custo por tarefa aceita. Reprodução deve considerar tolerâncias definidas para ambiente, artefato e validações.

Se o piloto melhora velocidade, mas aumenta retrabalho ou incidentes, a autonomia não cresceu de forma sustentável. Se a equipe não consegue identificar o estado-base, verificar o artefato e saber qual autoridade promoveu a mudança, ainda não existe um checkpoint confiável. Existe apenas acesso automatizado.

A ordem que proponho é simples: primeiro contenha, depois meça, então amplie autonomia.