Dê ao agente de código uma VM descartável

Por que uma VM descartável é melhor do que o seu portátil

Dê a um agente de programação uma VM descartável, e o pior que ele pode fazer é destruir uma máquina que pode reconstruir em dez minutos. O agente continua a ter root, continua a instalar pacotes e continua a executar a suite de testes sem pedir autorização para cada passo. A diferença está no local onde os danos ocorrem. Num portátil, o agente partilha o diretório pessoal com as suas chaves SSH, o perfil do navegador, os ficheiros .env e todos os outros repositórios que já clonou. Num servidor descartável, tem uma shell, um checkout e nada mais que valha a pena obter.

Esse é todo o argumento, e trata-se de assimetria, não de probabilidade. Um agente cuidadoso num portátil bem administrado funciona bem quase sempre. Na única vez em que isso não acontece, o custo não é um commit incorreto. É uma restauração a partir de backup, se tiver uma.

Defina o raio de impacto antes de discutir sobre ele

O raio de impacto é o conjunto de elementos que um processo consegue alcançar. Para um agente executado como o seu utilizador normal na sua máquina normal, esse conjunto é maior do que a maioria das pessoas imagina.

Esse conjunto inclui ~/.ssh/id_ed25519, que normalmente não está encriptado porque se cansou de introduzir a passphrase. 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, incluindo os que têm strings de ligação à produção num ficheiro env local. Inclui o histórico da shell, que contém tokens que colou uma vez. Também inclui a rede à qual o portátil está ligado, que muitas vezes é uma rede doméstica ou de escritório com serviços sem autenticação.

Nada disso exige um agente malicioso. Basta um comando executado com confiança, mas errado. rm -rf "$BUILD_DIR"/* com BUILD_DIR unset, que expande para /* e passa pela recusa predefinida do GNU rm de eliminar o próprio /, um git clean -xfd no diretório errado, um docker system prune -af --volumes que leva consigo a base de dados local, ou um chmod -R 777 aplicado por engano a um diretório home. Os agentes são treinados na mesma Internet que ensinou esses comandos a todas as outras pessoas.

O mecanismo que o protege não é o discernimento do agente. É o facto de a máquina onde os danos ocorrem ser uma máquina que estava disposto a perder.

A matemática dos custos é entediante. 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: o problema é detetado imediatamente e existe um backup.

Faça as contas com os seus próprios valores. Pegue na sua taxa horária e multiplique-a pelo número de horas necessário para reinstalar um sistema operativo, restaurar um diretório pessoal, substituir uma chave SSH, substituir um token de acesso pessoal e voltar a clonar vinte repositórios. Compare esse valor com doze meses do servidor mais pequeno que o seu fornecedor disponibiliza. O ponto de equilíbrio ocorre com menos de um incidente a cada vários anos. O incidente nem sequer precisa de ser catastrófico para ultrapassar esse valor. Perder uma única tarde devido a um ambiente local corrompido já paga o ano.

A segunda parte das contas são os snapshots. Um snapshot antes de uma execução arriscada transforma um resultado negativo de "restaurar toda a minha vida" em "reverter e experimentar um prompt diferente". Essa opção não existe no laptop onde está a escrever isto, porque não pode criar um snapshot de uma máquina enquanto a utiliza como secretária.

O cenário em outubro de 2026

Há três respostas honestas para a pergunta "onde deve o agente ser executado". Todas fazem o mesmo compromisso entre duas coisas: a força do isolamento e a quantidade de configuração que está disposto a aceitar.

Uma micro VM local. As ferramentas desta categoria arrancam uma máquina virtual real no seu próprio hardware, montam o seu repositório dentro dela e permitem que o agente tenha acesso de root. clawk é o exemplo atual, e a sua proposta corresponde exatamente à tese deste artigo: disponibilizar aos agentes de programação uma VM Linux descartável, não o seu portátil. Em outubro de 2026, destina-se ao macOS 14 e posteriores em Apple silicon, com suporte experimental para Linux através do Firecracker, e é instalada com brew install clawkwork/tap/clawk. Execute clawk dentro de um repositório para arrancar o sandbox e associar um agente, clawk down para o parar e clawk destroy para o remover. O isolamento é fornecido por um hypervisor, que oferece uma separação forte. A limitação é que a VM fica na máquina que transporta consigo. Por isso, consome memória local e para quando fecha a tampa.

Um contentor. 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 elimina o contentor ao terminar e --network none deixa-o sem acesso à rede. Este é um bom padrão para uma compilação ou uma execução de testes. Tenha claro o que isto não faz: um contentor partilha o kernel do host. Portanto, um erro no kernel pode permitir escapar do isolamento. Além disso, o isolamento desaparece assim que adicionar --privileged ou montar /var/run/docker.sock para permitir que o agente "use Docker". Montar o socket do Docker dentro de um contentor equivale a dar a esse contentor acesso de root ao host.

Uma VPS comum que pode reconstruir. Não exige uma ferramenta nova, fornece um isolamento real ao nível do kernel, permite usar snapshots do fornecedor e continua a executar quando desliga o portátil. Este é o padrão descrito no resto deste guia. É também o que suporta execuções longas dos agentes, porque uma tarefa que demora quatro horas não depende de ter regressado a casa.

O padrão VPS: dê ao agente o seu próprio utilizador

Comece com um servidor protegido. As primeiros dez minutos num VPS novo abrangem as partes que não são específicas do agente: atualizações, um início de sessão sem root, SSH apenas com chaves e uma firewall.

Depois, crie uma conta que exista apenas para o agente. Assim, um erro dentro dela não pode afetar mais nada no 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 existe uma palavra-passe para tentar adivinhar e que o acesso à conta é feito com sudo -u agent ou com uma chave SSH. Tenha em atenção que agent não pertence deliberadamente ao grupo sudo. Um agente com sudo tem acesso a root, e root pode ler os ficheiros de todos os outros utilizadores. Nesse caso, o isolamento que acabou de criar é apenas aparente. Se o agente precisar realmente de instalar pacotes, isso justifica usar um servidor inteiro sob o seu controlo, não atribuir-lhe sudo num servidor partilhado. As regras gerais estão em princípio do menor privilégio para utilizadores Linux num VPS.

Verifique este limite antes de confiar no agente. Como utilizador agent, tente listar o diretório home da sua própria conta:

sudo -u agent ls /home/you

Deverá ver ls: cannot open directory '/home/you': Permission denied. Se aparecer uma listagem de ficheiros, o diretório home pode ser lido por outros utilizadores. Nesse caso, o agente pode ler tudo o que estiver dentro dele e não tiver restrições adicionais, como um ficheiro .env legível por todos. Corrija a situação com sudo chmod 700 /home/you. A sua chave SSH privada não é protegida por este teste: o ssh ignora um ficheiro de chave privada que possa ser acedido por outros utilizadores. Por isso, qualquer chave que funcione consigo já não pode ser lida por agent, independentemente das permissões do diretório home.

Mantenha as credenciais totalmente fora da máquina

A finalidade de uma máquina descartável deixa de existir se copiar os segredos de produção para ela. A regra é simples: nada nessa máquina deve ser uma credencial cuja rotação você não aceitaria fazer esta tarde.

Para o git, encaminhe o SSH agent em vez de copiar uma chave. A chave privada permanece no seu laptop e apenas as solicitações de assinatura atravessam a ligaçã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 ficheiro de chave presente no servidor. Execute ls -la ~/.ssh nessa máquina depois e confirme que não existe nenhuma chave privada nela.

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

Para chaves de API, atribua ao agent uma chave própria, com um limite de gastos próprio, armazenada num ficheiro pertencente ao utilizador agent e com modo 600. Quando a máquina for destruída, revogue essa chave em vez de tentar determinar se ela foi exposta. Manter os gastos do modelo visíveis por chave também é o que torna previsíveis os valores apresentados em Controlo de custos de um agent de IA numa VPS.

Limite o que o agente pode alcançar na rede

O isolamento do sistema de ficheiros é apenas metade da fronteira. A outra metade é o tráfego de saída: aquilo com que o processo pode comunicar. O Linux pode filtrar o tráfego de saída com base no utilizador 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 por ordem, por isso o REJECT final captura tudo o que as linhas anteriores não permitiram. Teste como o agente:

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

Isto deve falhar imediatamente com um erro curl: (7) Failed to connect to example.com, seguido de uma mensagem que varia conforme a versão do curl, porque a regra de rejeição responde logo em vez de deixar a ligação pendurada. Um pedido HTTPS para o mesmo anfitrião deve continuar a funcionar.

Existem duas limitações importantes. Primeiro, estas regras perdem-se no próximo reboot, a menos que as guarde com sudo apt install -y iptables-persistent e depois com sudo netfilter-persistent save. Segundo, este filtro aplica-se a portas e endereços, não a nomes. Uma regra que permita a porta 443 permite qualquer anfitrião HTTPS na Internet. Isso é suficiente para alcançar a API do modelo e também um serviço de pastebin. Uma verdadeira lista de permissões por domínio exige que o tráfego passe por um proxy que leia o nome do anfitrião pedido. Essa configuração é mais complexa do que a maioria das instalações de um único programador pretende manter. Afirme apenas o que tem: controlo do tráfego de saída ao nível das portas, numa máquina que estava preparado para perder.

Redefinir para um estado limpo entre 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 apenas parcialmente, um node_modules obsoleto e uma working tree do git com alterações que ninguém reviu. A tarefa seguinte herda tudo isso, e você gasta o seu tempo de revisão a determinar que problemas pertencem a cada execução. Um agente mais restrito deixa menos resíduos desde o início. Por isso, combinar uma máquina descartável com uma skill que orienta o agente para a menor alteração que funciona mantém o diff e o estado residual suficientemente pequenos para revisão.

A opção mais simples é usar um checkout novo por 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 provider uma única vez, logo depois de configurar a máquina e antes de qualquer agente lhe ter tocado. Restaurar esse snapshot devolve todo o sistema, incluindo os pacotes, a um estado conhecido. A maioria dos providers disponibiliza esta função no painel de controlo ou através de uma API, e não como um comando executado na máquina. Por isso, os passos exatos dependem do seu provider. A regra é criar o snapshot enquanto a máquina ainda está num estado básico.

Mantenha fora da máquina descartável tudo aquilo de que precisa. Na prática, isso significa sobretudo fazer push das branches em vez de as guardar localmente. Se a máquina acabar por conter algo cuja perda seria um problema, faça um backup adequado com backups restic num VPS. Uma máquina que pode ser destruída só é útil se a destruição for realmente uma operação sem surpresas.

Se quiser vários ambientes isolados sem pagar por vários servidores, um VPS maior pode alojar VMs guest diretamente. A virtualização aninhada num VPS explica como isso funciona, incluindo como verificar se o seu provider a permite. O isolamento funciona nos dois sentidos neste caso. Se preferir que dois agentes no mesmo servidor coordenem entre si em vez de ficarem isolados, uma sessão do Claude Code pode enviar texto diretamente para outra em vez de encaminhar cada transferência através de você.

Quando um portátil cuidadosamente configurado é realmente suficiente

Se revê cada comando antes de este ser executado, um portátil é suficiente. O pedido de confirmação de permissões é um controlo real, e executar o Claude Code com segurança num servidor explica o que cada nível bloqueia efetivamente. Se o seu trabalho estiver limitado a um único repositório e não existirem credenciais de produção em nenhum local da máquina, o raio de impacto já é reduzido. Se as sessões do agente forem curtas e supervisionadas, o período de exposição também será curto.

A resposta muda no momento em que ignora os pedidos de confirmação. Isto merece atenção agora que o modo automático é a predefinição do Claude Code e uma instalação nova já não lhe pede confirmação antes de editar ficheiros ou executar comandos. Execuções sem supervisão, tarefas durante a noite e qualquer fluxo de trabalho em que aprova um plano e se afasta removem a verificação humana que garantia a contenção. Nesse caso, a própria máquina tem de fazer essa contenção. O mesmo se aplica a tudo o que amplie o alcance do agente, incluindo executar um agente de programação numa VPS em vários repositórios ao mesmo tempo.

A decisão não depende realmente do quanto confia no modelo. Depende do que está ao lado dele quando o modelo se engana.

FAQ

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

Na maioria dos casos, sim, com duas condições. O contentor não pode ser executado com --privileged nem ter /var/run/docker.sock montado nele, porque qualquer uma destas condições dá ao processo um caminho para obter acesso root no host. Um contentor partilha o kernel do host, por isso o limite é mais fraco do que o de uma máquina virtual. Se o agente executar código não confiável obtido da Internet, prefira uma máquina virtual real ou um servidor separado.

O agente precisa de sudo no servidor?

Não. Dar-lhe sudo anula o isolamento criado, porque root pode ler os dados de todas as outras contas no sistema. Crie o utilizador do agente sem sudo e dê-lhe acesso de escrita apenas ao seu próprio diretório de trabalho. Se a tarefa precisar realmente de instalar pacotes, dê ao agente uma máquina inteira sob o seu controlo em vez de lhe dar root numa máquina partilhada.

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

Encaminhe o seu agente SSH com ssh -A ao estabelecer a ligação. Os pedidos de assinatura são enviados pela ligação, enquanto a chave privada permanece no seu portátil, por isso ssh -T git@github.com autentica e git push funciona sem uma chave privada no servidor. A ressalva é que root nesse servidor pode utilizar o socket encaminhado enquanto estiver ligado. Por isso, use uma chave de implementação limitada ao repositório em qualquer máquina que partilhe com outras pessoas.

Que tamanho de VPS precisa um agente?

O trabalho do agente consiste sobretudo em editar ficheiros, executar builds e executar testes. Dimensione a máquina para o build, não para o modelo. Um modelo alojado é executado no hardware do fornecedor, o que acrescenta tráfego de rede e quase nenhuma carga local. O próprio agente ainda define um mínimo: em 20 de October de 2026, os requisitos de sistema do Claude Code indicam 4 GB de RAM como mínimo. Comece com 4 GB mesmo para tarefas de scripting e passe para 8 GB se o repositório criar contentores ou compilar algo substancial.

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

Recrie-a quando o estado deixar de ser explicável e, no mínimo, sempre que uma credencial na máquina possa ter sido exposta. Um checkout novo entre tarefas resolve a deriva diária, e um snapshot criado antes da primeira execução do agente fornece uma imagem limpa do sistema à qual pode regressar. Se recriar a máquina parecer dispendioso, isso indica que algo importante está a ser mantido numa máquina que considerou descartável.