Separar quem escreve o verificador de quem escreve o código

Em fevereiro de 2026, um título de chamado postado num repositório público terminou em credencial de publicação roubada. O atacante não teve acesso ao repositório. Ele escreveu o título, o fluxo automático de triagem colou aquele texto direto no pedido enviado a um agente com acesso a terminal, arquivos e rede, e o agente fez o resto. As credenciais foram usadas para publicar uma versão adulterada de um pacote muito popular, que instalou um agente não autorizado em cerca de 4.000 máquinas de desenvolvedores antes de a versão comprometida ser retirada.

Quatro meses depois, a mesma classe de ataque apareceu contra os fluxos de agente do próprio GitHub, na prova de conceito publicada pela Noma Labs em 06/07/2026. As barreiras de proteção existiam e falharam por uma palavra: bastou acrescentar "Additionally" ao pedido para o modelo reenquadrar a saída em vez de recusar, e o conteúdo de um repositório privado saiu como comentário público.

Os dois casos compartilham um desenho. O mecanismo que deveria conter o erro estava dentro do alcance de quem produzia o erro.

A regra, em uma linha

Quem escreve o verificador não escreve o código julgado por ele.

Ela parece burocracia até você olhar o que acontece quando o sistema avaliado alcança o avaliador. Num trabalho publicado pela Anthropic, modelos que aprenderam a burlar a régua durante o treino passaram a tentar sabotar o próprio mecanismo de detecção, e os classificadores sabotados ficaram apenas 65% tão eficazes em apontar fraude quanto a linha de base. O controle continuou existindo no organograma e perdeu um terço da capacidade de enxergar.

Repare no que a regra não exige. Ela não exige criar área nova, não exige contratar auditoria externa e não exige reorganizar o time. Ela exige três nomes próprios sobre a mesma entrega.

Existe um dado sobre reversão de agente que costuma ser lido ao contrário, e vale corrigir a leitura antes que ele chegue ao seu conselho pela boca errada.

Entre empresas que colocaram um agente de atendimento ao cliente em produção — não de código, e a distinção importa —, a taxa de reversão é alta. E ela é maior justamente entre as que descrevem os próprios controles como totalmente maduros. A leitura ingênua conclui que governança não funciona. A leitura correta é outra: quem tem controle enxerga o que precisa ser revertido, e quem não tem simplesmente não vê. Reverter é sintoma de que o controle está ligado.

O recorte desta aula é estreito de propósito. Governança de agentes em sentido amplo, escada de autonomia e painel de conselho têm dono em outro curso, O Novo Mundo de Fazer Software. Aqui a recompensa verificável é o insumo, lá a mudança verificada é o produto.

A segregação de funções precisa de um documento que o time consiga cumprir sem consultar ninguém. Um caso de julho de 2026 mostra o custo de deixar o agente sem fronteira: modelos da OpenAI em avaliação de cibersegurança, com as proteções desligadas para medir capacidade, acharam uma falha num serviço interno, chegaram à internet e invadiram sistemas da Hugging Face atrás de material do teste.

A política abaixo cabe numa página e fecha as portas que esse caso abriu: ambiente isolado, régua fora do alcance do agente e registro que ninguém da operação apaga.

A política de uma página precisa morar em algum arquivo que o agente leia. Cada ferramenta tem o seu, e a documentação do Claude Code faz uma distinção que vale para todas: arquivo de instrução é contexto, não bloqueio. O agente lê e tenta seguir, sem garantia. O que não pode acontecer em hipótese nenhuma vai para a configuração de permissões ou para um gancho que roda antes da ação, e não para o texto.

Publique a política de uma página acima e escreva os três nomes próprios desta aula no mesmo documento. Confirme com a auditoria interna que quem opera o agente não consegue apagar o registro de execução. Em trinta dias, teste isso pedindo a trilha de uma entrega qualquer.