Toda disciplina de ambientes que seu time construiu para humanos se aplica a agentes de código, e a maioria dos times abandonou tudo isso silenciosamente no momento em que o agente ficou bom. A mesma organização que não deixaria um contratado novo chegar perto de produção no primeiro dia entrega a um agente uma credencial de longa duração e uma descrição de tarefa, e depois finge surpresa quando algo que não deveria ser apagado é apagado.

A tese é chata de propósito: um agente é um contribuidor incomumente rápido, sem juízo institucional, e a escada de ambientes existe exatamente para contribuidores assim. Dev, staging, produção, com um gate entre cada um. Nunca foi sobre o humano. Sempre foi sobre o raio de impacto.

Por que a escada foi ignorada

Ninguém tomou a decisão de pular a escada. Ela foi corroída, numa sequência que vale a pena reconhecer porque seu time provavelmente está em algum ponto dela.

O agente começa como autocomplete, e ninguém coloca autocomplete em staging. Depois ele passa a rodar a suíte de testes localmente, o que está tudo bem. Depois ele precisa acessar um serviço real para reproduzir um bug, então alguém dá a ele acesso de leitura ao staging. Depois os dados de staging estão desatualizados, então alguém o aponta para uma réplica de produção. Depois uma tarefa precisa de uma escrita, e a credencial que já está no ambiente por acaso tem essa permissão. Em nenhum momento alguém decidiu que o agente deveria poder escrever em produção. Ele chegou lá por uma série de passos individualmente razoáveis, que é como a maioria dos incidentes chega a qualquer lugar.

O que um agente faz de diferente

A escada importa mais para agentes do que para pessoas, por razões estruturais, não por um julgamento sobre a competência do modelo.

  • A velocidade remove a pausa. Um humano fazendo algo destrutivo costuma hesitar antes. Essa hesitação é um controle de segurança não escrito, e é boa parte do motivo pelo qual a escada se sustentou para humanos mesmo sendo aplicada de forma frouxa. Um agente executa com plena confiança em dois segundos. Não há pausa para pegá-lo no meio do caminho.
  • Sem noção de consequência. Um engenheiro sabe que essa tabela é a tabela de cobrança e que quinta-feira é dia de fatura. Esse conhecimento não está no repositório, então não está no contexto do agente. Ele conhece o schema. Não conhece o que está em jogo.
  • Objetivos literais. Instruído a fazer um teste de integração passar, um agente vai considerar alterar os dados contra os quais o teste faz asserções. Essa é uma solução legítima para o problema declarado. Só está errada por causa de contexto que o agente não tem.
  • Volume. Um engenheiro abre três pull requests por dia. Uma frota de agentes abre trinta. A probabilidade de uma mudança ruim por mudança pode cair e o número absoluto de mudanças ruins ainda assim subir.

A escada, reformulada para agentes

Os mesmos três degraus, com a parte específica de agentes destacada.

  • Dev: descartável e isolado. Um agente, um workspace, nenhum estado compartilhado. Se dois agentes trabalham no mesmo checkout, eles vão brigar pelos mesmos arquivos e você vai passar a tarde lendo um conflito de merge que nenhum dos dois entende. Branches efêmeras e worktrees são baratas; estado mutável compartilhado não é.
  • Staging: forma real, riscos falsos. Staging só se justifica se ele se parece com produção estruturalmente, mesmo schema, mesma topologia de serviços, mesmo comportamento de falha, enquanto não contém nada cuja perda importe. Dados semeados ou sintéticos, nunca uma cópia de produção. Uma réplica de produção em staging é produção com monitoramento pior.
  • Produção: só humanos e gates. A saída do agente chega em produção do mesmo jeito que qualquer mudança, por meio de um pull request revisado e do seu gate de deploy já existente. Nenhuma porta lateral, nenhuma conta de serviço com atalho.

Isolamento é a credencial, não a URL

É aqui que os times se enganam. Apontar o agente para staging.internal não é isolamento se a credencial no ambiente dele também é válida em produção. A fronteira do ambiente é definida pelo que a identidade consegue alcançar, não por qual hostname a tarefa menciona. Um agente com um papel amplo está a apenas uma chamada de ferramenta confusa de distância da conta errada, e ele vai fazer essa chamada de forma educada e imediata.

A versão disso que se sustenta é prática comum da AWS, sem nada de extraordinário, aplicada de forma consistente:

  • Contas separadas por ambiente, de modo que um erro entre ambientes exija uma assunção de papel que não existe, em vez de um erro de digitação que existe.
  • Um papel dedicado por tarefa do agente, restrito aos recursos que aquela tarefa precisa, assumido pela duração da execução e nada além disso.
  • Nenhuma chave de longa duração no ambiente do agente. Credenciais de curta duração significam que um contexto vazado é um problema com data de validade.
  • Negar por padrão os verbos destrutivos. Um agente que nunca precisa de DeleteObject deve ser estruturalmente incapaz de chamá-lo, não apenas desencorajado a fazê-lo.
  • Aprovação humana para qualquer coisa que cruze para uma conta que contém dados reais, como um controle que o agente não consegue satisfazer sozinho.

Os gates de revisão são o objetivo, não o atrito

A objeção é previsível: isso deixa o agente mais lento, e todo o apelo do agente era a velocidade. Essa objeção merece ser levada a sério e depois rejeitada, porque ela avalia mal a troca envolvida.

A vantagem de velocidade do agente está na geração, não na verificação. Ele escreve uma correção plausível em noventa segundos em vez de uma hora, o que é real e considerável. A verificação nunca foi o gargalo que ele remove. Remover o gate de revisão não deixa o agente mais rápido naquilo em que ele já é rápido, apenas remove o mecanismo que pega os dez por cento de saídas confiantes que estão erradas. Você mantém a correção de noventa segundos. Você mantém o revisor. Esse é o arranjo inteiro, e é um bom arranjo.

A conclusão

Nada disso é engenharia nova. Separação de ambientes, credenciais restritas, revisão antes de produção: seu time escreveu essas regras para humanos e em grande parte as segue. O erro é tratar um agente como ferramenta em vez de como contribuidor, porque ferramenta não precisa de escada de ambientes e contribuidor precisa. Dê ao agente uma sandbox que se pareça com produção e não contenha nada que importe, uma identidade que expira e não consegue cruzar a fronteira, e um revisor entre ele e o deploy. Depois deixe-o ir rápido dentro dessa caixa.

Leia isso a seguir

Para os controles no nível de conta por trás disso, multi-party approval in AWS Organizations cobre o gate para operações que nada deveria rodar sozinho, em ercan.cloud. O hub fica em ercanermis.com.