Vocês deixam agentes de IA rodarem comandos sozinhos no terminal?

Meus 2 cents,

• O agente sempre roda em uma sandbox (VM) com acesso a internet restrito e obrigatorio via proxy SQUID (assim o acesso a internet eh logado de forma automatica e o SQUID tem regras de bloqueio para sites que achemos ruins). A simples tentativa de acesso do agente de dentro da sandbox para algum local externo eh bloqueado por padrao e gera LOG para investigacao do porque (regra direta via iptables).

• Se o agente precisar acessar um servidor, uma chave privada de uso unico eh gerada (semelhante ao um OTP)

• O agente nao tem acesso direto aos providers (openrouter, openai, anthoripc, etc) - tudo passa por um AI gateway (geralmente o ommirouter) para logar o que o agente fez de fato.

• O agente tem um CI/CD stage pra testar alteracoes, PR, etc. O agente nao manda para producao direto, dependendo do projeto outro analisa a saida QA e publica em producao (versionado)

• Se o agente precisar de um acesso que esta bloqueado ou interacao human-in-the-loop, gera uma solicitacao por email e tambem para um aplicativo de mensagens (atual telegram, mas ja foi zap).

Tem mais alguns detalhes, mas do que pode ser facilmente replicado eh isso ai.

Saude e Sucesso !

---

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

Deixar o agente rodar npm install ou git push sem aprovação é arriscado porque o modelo não tem visibilidade real do estado atual do sistema operacional, apenas do texto que você forneceu na janela de contexto. Se o ambiente local tiver dependências desatualizadas, variáveis de ambiente diferentes ou conflitos de git não resolvidos, o agente pode executar comandos que quebram o build ao assumir um estado idealizado que não existe.

A aprovação humana antes de ações de escrita ou deploy é o único guardião confiável enquanto não temos agentes com capacidade de verificar o estado do sistema em tempo real antes de agir. O problema central é a lacuna entre o contexto estático do prompt e a realidade dinâmica da máquina; sem um mecanismo que consulte o estado real (como um diff de arquivos abertos ou o output de comandos de diagnóstico antes da execução), o agente opera no escuro.

Aqui a gente roda agentes agendados num PC que fica ligado o dia todo, sem ninguém olhando na hora. Então "revisar depois" é a regra, e o que segurou não foi aprovar cada passo, foi tirar do alcance os comandos que fazem estrago grande. Cada regra abaixo nasceu de um incidente:

• Matar processo por padrão. Um pkill -f casou com a linha de comando do próprio shell do agente e derrubou a sessão. Outro kill por nome ("qemu") acertou a VM de um programa que não tinha nada a ver. Hoje só vale kill por PID que o próprio agente iniciou, ou pela ferramenta do programa (ex.: adb emu kill para o emulador Android).
• Comando que espera input. Um agente parado num prompt segurou a fila de agendamentos por três dias, porque o agendador não começa uma execução nova enquanto a anterior não termina. Agora tudo roda não interativo e com timeout.
• Segredos na saída. O agente não pode dar cat/source no .env nem montar URL ou curl com token, porque o que ele imprime vai para log e transcrição. O script carrega o .env sozinho e o agente só cita o nome da variável.
• git add -A. Com várias sessões no mesmo repositório, ele leva junto arquivo pela metade de outra sessão. Cada agente adiciona só os caminhos que mexeu.
• O que não tem volta. Apagar dados, publicar numa conta, gastar dinheiro: isso vai para uma fila de aprovação humana. Ler, testar, rascunhar e fazer deploy que só envia arquivos (nunca apaga) rodam sozinhos.

Duas coisas que ajudaram mais do que o modo de aprovação em si: escrever o porquê junto de cada regra (sem o motivo, o modelo acha uma "exceção razoável"), e exigir prova depois de toda ação final, tipo a página de confirmação ou o item aparecendo na lista, antes de registrar "feito".