Dê a agentes de código uma VM descartável

Por que uma VM descartável é melhor que seu laptop

Dê a um agente de programação uma VM descartável, e o pior que ele poderá fazer será destruir uma máquina que você consegue recriar em dez minutos. O agente ainda terá acesso a root, ainda poderá instalar pacotes e ainda executará o conjunto de testes sem pedir permissão a cada etapa. A diferença está no local onde o dano ocorre. Em um laptop, o agente compartilha o diretório home com suas chaves SSH, o perfil do navegador, seus arquivos .env e todos os outros repositórios que você já clonou. Em um servidor descartável, ele terá um shell, um checkout e nada mais que valha a pena obter.

Esse é todo o argumento, e ele trata mais de assimetria do que de probabilidade. Um agente cuidadoso em um laptop bem protegido funcionará bem quase sempre. Na única vez em que isso não ocorrer, o custo não será um commit incorreto. Será restaurar um backup, se você tiver um.

Defina o raio de impacto antes de discutir sobre ele

Raio de impacto é o conjunto de coisas que um processo pode alcançar. Para um agente executado como seu usuário normal na sua máquina normal, esse conjunto é maior do que a maioria das pessoas imagina.

Ele inclui ~/.ssh/id_ed25519, que geralmente não é criptografado porque você se cansou de digitar a senha. Inclui ~/.aws/credentials e ~/.config/gh/hosts.yml, que são texto simples por definição. Inclui todos os repositórios irmãos em ~/code, inclusive os que contêm strings de conexão de produção em um arquivo de ambiente local. Também inclui o histórico do shell, que contém tokens que você colou uma vez. Inclui ainda a rede à qual seu laptop está conectado, que costuma ser uma rede doméstica ou corporativa com serviços não autenticados.

Nada disso exige um agente malicioso. Basta um comando executado com confiança, mas incorreto. rm -rf com uma variável não definida expandindo para /, um git clean -xfd no diretório errado, um docker system prune -af --volumes que leva seu banco de dados local junto, um chmod -R 777 útil em um diretório pessoal. Os agentes são treinados na mesma internet que ensinou esses comandos a todas as outras pessoas.

O mecanismo que protege você não é o julgamento do agente. É o fato de que a máquina que sofre o dano é uma máquina que você estava disposto a perder.

A matemática de custos é entediante, e esse é o objetivo

Um VPS pequeno custa alguns dólares por mês. Recuperar um laptop de desenvolvimento custa um dia de trabalho. Esse é o melhor caso: você percebe o problema imediatamente e tinha um backup.

Faça as contas com seus próprios números. Pegue seu valor por hora e multiplique pelas horas necessárias para reinstalar um sistema operacional, restaurar um diretório pessoal, fazer a rotação de uma chave SSH, fazer a rotação de um token de acesso pessoal e clonar novamente vinte repositórios. Compare esse valor com doze meses do menor servidor oferecido pelo seu provedor. O ponto de equilíbrio ocorre com menos de um incidente a cada vários anos. O incidente nem precisa ser catastrófico para superar esse valor. Uma única tarde perdida devido a um ambiente local corrompido já paga o servidor por um ano.

A segunda parte da conta são os snapshots. Um snapshot antes de uma execução arriscada transforma um resultado ruim de "restaurar tudo" em "reverter e tentar outro prompt". Essa opção não existe no laptop em que você está digitando este texto, porque não é possível criar um snapshot de uma máquina enquanto você a usa como estação de trabalho.

O cenário em julho de 2026

Há três respostas válidas para "onde o agente deve ser executado", e todas equilibram os mesmos dois fatores: a força do isolamento e o quanto de configuração você aceita fazer.

Uma micro VM local. As ferramentas dessa categoria inicializam uma máquina virtual real no seu próprio hardware, montam o repositório nela e permitem que o agente tenha acesso de root dentro da VM. clawk é o exemplo atual, e sua proposta corresponde exatamente à tese deste artigo: fornecer aos agentes de programação uma VM Linux descartável, não o seu laptop. Em julho de 2026, ele é compatível com macOS 14 e versões posteriores em Apple silicon, com suporte experimental a Linux por meio do Firecracker, e é instalado com brew install clawkwork/tap/clawk. Execute clawk dentro de um repositório para inicializar o sandbox e conectar um agente, clawk down para interrompê-lo e clawk destroy para removê-lo. O isolamento é fornecido por um hypervisor, portanto é forte. A limitação é que a VM fica na máquina que você transporta, consumindo sua memória, e para quando você fecha a tampa.

Um container. Docker é a opção que a maioria das pessoas já tem instalada, e é realmente útil.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm remove o container ao sair, e --network none não fornece nenhuma rede a ele, o que é um bom padrão para uma compilação ou execução de testes. É importante entender o que isso não faz: um container compartilha o kernel do host, portanto uma falha no kernel pode permitir uma saída, e o isolamento desaparece assim que você adiciona --privileged ou monta /var/run/docker.sock para que o agente possa "usar Docker". Montar o socket do Docker em um container equivale a conceder root nesse host ao container.

Um VPS comum que você possa recriar. Não exige uma ferramenta nova, oferece um isolamento real no nível do kernel, permite usar snapshots do provedor e continua em execução quando você desliga o laptop. Este é o padrão descrito no restante deste guia e é o que suporta execuções longas de agentes, porque um trabalho que leva quatro horas não é afetado pelo fato de você ter ido para casa.

O padrão de VPS: dê ao agente seu próprio usuário

Comece por um servidor protegido. Os dez primeiros minutos em uma nova VPS cobrem as partes que não são específicas do agente: atualizações, um login que não seja root, SSH somente com chave e um firewall.

Depois, crie uma conta que exista somente para o agente. Assim, um erro dentro dela não poderá afetar outras partes do servidor.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password significa que não há uma senha para adivinhar, e você acessa a conta com sudo -u agent ou uma chave SSH. Observe que agent deliberadamente não está no grupo sudo. Um agente com sudo tem acesso root, e root pode ler os arquivos de todos os outros usuários. Nesse caso, o isolamento que você acabou de criar é apenas aparente. Se o agente realmente precisar instalar pacotes, isso é um motivo para usar um servidor inteiro sob responsabilidade dele, não para conceder sudo a ele em um servidor compartilhado. As regras gerais estão em privilégio mínimo para usuários Linux em uma VPS.

Verifique o limite antes de confiar nele. Como o usuário agent, tente ler um arquivo pertencente à sua própria conta:

sudo -u agent cat /home/you/.ssh/id_ed25519

Você deverá ver cat: /home/you/.ssh/id_ed25519: Permission denied. Se aparecer material de chaves, seu diretório inicial está no modo 755 e o isolamento ainda não é real. Corrija isso com sudo chmod 700 /home/you.

Mantenha as credenciais totalmente fora da máquina

O objetivo de uma máquina descartável é perdido se você copiar nela os segredos de produção. A regra é simples: nada nessa máquina deve ser uma credencial cuja rotação você não faria ainda hoje.

Para o git, encaminhe o SSH agent em vez de copiar uma chave. A chave privada permanece no seu laptop, e somente as solicitações de assinatura atravessam a conexão.

ssh -A agent@203.0.113.10
ssh -T git@github.com

O segundo comando deve responder Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. Isso prova que git push funcionará sem nenhum arquivo de chave presente no servidor. Depois, execute ls -la ~/.ssh na máquina e confirme que não há nenhuma chave privada nela.

O encaminhamento do agent tem uma ressalva importante, que deve ser declarada claramente: enquanto você estiver conectado, qualquer pessoa com acesso root nesse servidor poderá usar o socket encaminhado para se autenticar como você. Em um servidor cujo único outro usuário é você, essa é uma troca aceitável. Em uma máquina compartilhada, não é; nesse caso, uma deploy key limitada a um único repositório é a melhor opção. As opções são abordadas em Noções básicas sobre gerenciamento de chaves SSH.

Para chaves de API, forneça ao agent uma chave própria, com seu próprio limite de gastos, armazenada em um arquivo pertencente ao usuário agent, com modo 600. Quando a máquina for destruída, revogue essa chave em vez de tentar descobrir se ela vazou. Manter os gastos do modelo visíveis por chave também é como os números em Controle de custos de agentes de IA em um VPS permanecem previsíveis.

Limite o que o agente pode acessar na rede

O isolamento do sistema de arquivos cobre metade da barreira. A outra metade é a saída de rede: os destinos com os quais o processo pode se comunicar. O Linux pode filtrar o tráfego de saída pelo usuário que o criou, o que se ajusta exatamente a este padrão.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

As regras são lidas em ordem, portanto a regra final REJECT captura tudo o que as linhas anteriores não permitiram. Teste como o agente:

sudo -u agent curl -sS -m 5 http://example.com

Isso deve falhar com curl: (7) Failed to connect to example.com port 80: Connection refused, porque a regra de rejeição responde imediatamente, em vez de deixar a conexão travar. Uma solicitação HTTPS para o mesmo host ainda deve funcionar.

Há duas limitações importantes. Primeiro, essas regras são perdidas na próxima reinicialização, a menos que você as salve usando sudo apt install -y iptables-persistent e depois sudo netfilter-persistent save. Segundo, esse filtro considera portas e endereços, não nomes. Uma regra que permite a porta 443 permite todos os hosts HTTPS na internet. Isso é suficiente para acessar a API do modelo e também para acessar um pastebin. Uma lista de permissões de domínios verdadeira exige que o tráfego passe por um proxy que leia o nome do host solicitado. Isso acrescenta mais componentes do que a maioria das configurações de um único desenvolvedor deseja manter. Declare apenas o que você realmente tem: controle de saída no nível da porta, em uma máquina que você estava preparado para perder.

Restaurar um estado limpo entre as tarefas

Um estado limpo por tarefa é um benefício subestimado. Um agente que passou três horas no último ticket deixou pacotes instalados, migrações aplicadas parcialmente, um node_modules obsoleto e uma working tree do git com alterações que ninguém revisou. A próxima tarefa herda tudo isso, e você gasta seu orçamento de revisão tentando descobrir qual problema pertence a qual execução.

A opção simples é fazer um checkout novo para cada tarefa.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

A opção mais robusta é criar um snapshot do provedor uma vez, logo depois de configurar a máquina e antes que qualquer agente a utilize. Restaurar esse snapshot retorna todo o sistema, incluindo os pacotes, a um estado conhecido. A maioria dos provedores disponibiliza esse recurso no painel de controle ou por meio de uma API, e não como um comando na máquina, portanto as etapas exatas dependem do seu provedor. A prática correta é criar o snapshot enquanto a máquina ainda está em um estado limpo.

Mantenha fora da máquina descartável tudo aquilo que for importante para você. Isso geralmente significa fazer push das branches em vez de mantê-las apenas localmente. Se a máquina acabar armazenando algo que faria falta, faça backup corretamente com backups restic em um VPS. Uma máquina que você pode destruir só é útil se destruí-la for realmente uma operação sem consequências.

Se quiser vários ambientes isolados sem pagar por vários servidores, um VPS maior pode hospedar VMs convidadas diretamente. Virtualização aninhada em um VPS explica como isso funciona, incluindo como verificar se o seu provedor permite esse recurso.

Quando um laptop com os cuidados adequados é realmente suficiente

Seja honesto sobre isso, porque exagerar o isolamento faz as pessoas deixarem de prestar atenção.

Se você revisa cada comando antes da execução, um laptop é suficiente. O prompt de permissão é um controle real, e executar o Claude Code com segurança em um servidor explica o que cada nível dele realmente bloqueia. Se o seu trabalho está em um único repositório e não há credenciais de produção em nenhum lugar da máquina, o raio de impacto já é pequeno. Se as sessões do seu agente são curtas e supervisionadas, a janela de exposição também é curta.

A resposta muda no momento em que você ignora os prompts. Execuções não supervisionadas, tarefas noturnas e qualquer fluxo de trabalho em que você aprova um plano e se afasta removem a verificação humana que fazia a contenção. Nesse caso, a máquina precisa fazer isso. O mesmo se aplica a qualquer coisa que amplie o alcance do agente, incluindo executar um agente de programação em um VPS em vários repositórios ao mesmo tempo.

A decisão não depende realmente de quanto você confia no modelo. Depende do que está ao lado dele quando o modelo erra.

FAQ

Um container oferece isolamento suficiente para um agente de programação?

Para a maior parte do trabalho, sim, com duas condições. O container não pode ser executado com --privileged e não pode ter /var/run/docker.sock montado nele, porque qualquer uma dessas condições fornece ao processo um caminho até o root do host. Um container compartilha o kernel do host, portanto o limite é mais fraco que o de uma máquina virtual. Se o agente estiver executando código não confiável obtido da internet, prefira uma VM real ou um servidor separado.

O agente precisa de sudo no servidor?

Não. Dar sudo a ele desfaz o isolamento criado, porque root pode ler todas as outras contas da máquina. Crie o usuário do agente sem sudo e dê a ele acesso de escrita somente ao próprio diretório de trabalho. Se a tarefa realmente exigir a instalação de pacotes, forneça ao agente uma máquina inteira sob seu controle, em vez de root em uma máquina compartilhada.

Como permitir que o agente faça push para o git sem colocar minha chave SSH no servidor?

Encaminhe seu agente SSH com ssh -A ao se conectar. As solicitações de assinatura trafegam pela conexão, enquanto a chave privada permanece no seu laptop. Assim, ssh -T git@github.com faz a autenticação e git push funciona sem uma chave privada no servidor. O ponto de atenção é que root nesse servidor pode usar o socket encaminhado enquanto você estiver conectado. Portanto, use uma chave de implantação restrita ao repositório em qualquer máquina compartilhada com outras pessoas.

De que tamanho de VPS um agente precisa?

O trabalho do agente consiste principalmente em editar arquivos, executar builds e executar testes. Portanto, dimensione a máquina para o build, não para o modelo. Um modelo hospedado é executado no hardware do provedor, o que adiciona tráfego de rede e quase nenhuma carga local. Comece com 2 GB de RAM para trabalho com scripts e passe para 8 GB se o repositório criar containers ou compilar algo substancial.

Com que frequência devo destruir e recriar a máquina?

Recrie a máquina quando o estado deixar de ser explicável e, no mínimo, sempre que uma credencial nela puder ter sido exposta. Um checkout novo entre as tarefas resolve o desvio do estado no dia a dia. Um snapshot feito antes da primeira execução do agente fornece uma imagem limpa do sistema para a qual você pode retornar. Se recriar a máquina parecer caro, isso indica que algo importante está armazenado em uma máquina que você chamou de descartável.