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 habitual, esse conjunto é maior do que a maioria das pessoas imagina.

Inclui ~/.ssh/id_ed25519, que normalmente está sem encriptação porque se cansou de introduzir a frase-passe. 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 seu portátil está ligado, normalmente uma rede doméstica ou empresarial com serviços sem autenticação.

Nada disso exige um agente malicioso. Basta um comando inequivocamente errado. rm -rf com uma variável não definida a expandir para /, um git clean -xfd no diretório errado, um docker system prune -af --volumes que leva consigo a sua base de dados local, um chmod -R 777 executado de forma prestável no diretório pessoal. 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 ocorreriam 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 panorama em julho de 2026

Há três respostas honestas para a pergunta “onde deve ser executado o agente?”. Todas fazem uma troca entre os mesmos dois fatores: a robustez do isolamento e o nível de configuração que está disposto a aceitar.

Uma microVM local. As ferramentas desta categoria arrancam uma máquina virtual real no seu próprio hardware, montam o repositório dentro dela e permitem que o agente tenha acesso root no seu interior. clawk é o exemplo atual, e a sua proposta corresponde exatamente à tese deste artigo: fornecer aos agentes de programação uma VM Linux descartável, em vez de usar o portátil. Em julho 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 a sandbox e associar um agente, clawk down para a parar e clawk destroy para a remover. O isolamento é aplicado por um hypervisor, o que oferece uma proteção forte. A limitação é que a VM reside na máquina que transporta consigo, consome memória e para quando fecha a tampa.

Um contentor. O Docker é a resposta 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 não lhe fornece qualquer acesso à rede, o que é uma boa predefinição para uma compilação ou execução de testes. É importante perceber o que isto não faz: um contentor partilha o kernel do host, por isso uma vulnerabilidade no kernel pode permitir escapar do isolamento. Além disso, o isolamento desaparece assim que adiciona --privileged ou monta /var/run/docker.sock para que o agente possa “usar o Docker”. Montar o socket do Docker num contentor equivale a conceder a esse contentor acesso root ao host.

Um VPS normal que possa reconstruir. Não requer uma ferramenta nova, oferece 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 restante deste guia e é o que suporta execuções longas de agentes, porque uma tarefa que demora quatro horas não é afetada pelo facto de ter ido para casa.

O padrão de VPS: atribua ao agente o seu próprio utilizador

Comece por um sistema reforçado. Os primeiros dez minutos num VPS novo abrangem as partes que não são específicas do agente: atualizações, um login que não seja root, SSH apenas com chaves e uma firewall.

Depois, crie uma conta que exista apenas para o agente. Assim, um erro no agente 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 uma chave SSH. Note que agent não pertence deliberadamente ao grupo sudo. Um agente com sudo tem acesso root, e root pode ler os ficheiros de todos os outros utilizadores. Nesse caso, o isolamento criado anteriormente é apenas aparente. Se o agente precisar realmente de instalar pacotes, isso é um argumento para lhe atribuir um servidor inteiro, não para lhe conceder sudo num servidor partilhado. As regras gerais estão em princípio do menor privilégio para utilizadores Linux num VPS.

Verifique o limite antes de confiar no agente. Como utilizador agent, tente ler um ficheiro pertencente à sua própria conta:

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

Deverá ver cat: /home/you/.ssh/id_ed25519: Permission denied. Se vir material criptográfico, o seu diretório inicial está no modo 755 e o isolamento ainda não é real. Corrija-o com sudo chmod 700 /home/you.

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, pelo que 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 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 ligação pendurada. Um pedido HTTPS para o mesmo host deve continuar a funcionar.

Há 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 todos os hosts HTTPS na internet. Isso é suficiente para alcançar a API do modelo e também para alcançar um pastebin. Uma verdadeira lista de permissões por domínio exige que o tráfego passe por um proxy que leia o nome do host solicitado. Isso envolve mais componentes do que a maioria das configurações de um único programador pretende manter. Afirme apenas aquilo que tem: controlo do tráfego de saída ao nível da porta, 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 com cuidado é realmente suficiente

Se verifica todos os comandos antes de serem executados, um portátil é suficiente. O pedido de permissão é 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, sem credenciais de produção em qualquer parte da máquina, o impacto potencial 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 permissão. Vale a pena considerar isto agora que o modo automático passa a ser o padrão do Claude Code em 14 de agosto de 2026 e uma instalação nova deixa de pedir 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 eliminam a verificação humana que assegurava o isolamento. Nesse momento, a máquina tem de assumir esse controlo. 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 grau de confiança que deposita no modelo. Depende do que está ao lado dele quando o modelo erra.

FAQ

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

Para a maioria das tarefas, sim, com duas condições. O container não pode ser executado com --privileged nem ter /var/run/docker.sock montado nele, porque qualquer uma dessas condições dá ao processo um caminho para root no host. Um container partilha o kernel do host, por isso o limite é mais fraco do que numa 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 as contas dos restantes utilizadores da máquina. 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 que ele controle, em vez de 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 quando se ligar. Os pedidos de assinatura passam pela ligação, enquanto a chave privada permanece no seu portátil. Assim, ssh -T git@github.com autentica e git push funciona sem uma chave privada no servidor. A ressalva é que root nesse servidor pode usar o socket encaminhado enquanto estiver ligado. Por isso, use uma deploy key limitada ao repositório em qualquer máquina que partilhe com outras pessoas.

De que tamanho precisa de ser o VPS para 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. Comece com 2 GB de RAM para tarefas de scripting 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 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 trata o drift do dia a dia. Um snapshot criado antes da primeira execução do agente fornece uma imagem de sistema limpa à qual pode regressar. Se recriar a máquina parecer dispendioso, isso indica que algo importante está a viver numa máquina que classificou como descartável.