VM usa e getta per agenti di coding: perché conviene

Perché una VM usa e getta è preferibile al laptop

Concedi a un agente di coding una VM usa e getta: nella peggiore delle ipotesi può distruggere una macchina che puoi ricreare in dieci minuti. L’agente ottiene comunque root, installa comunque i pacchetti ed esegue comunque la suite di test senza chiedere l’autorizzazione per ogni passaggio. La differenza riguarda il punto in cui si verificano i danni. Su un laptop, l’agente condivide la directory home con le chiavi SSH, il profilo del browser, i file .env e tutti gli altri repository che hai mai clonato. Su un server usa e getta, dispone di una shell, di una copia di lavoro e di nient’altro che valga la pena sottrarre.

Questo è l’intero argomento, e riguarda l’asimmetria più che la probabilità. Un agente prudente su un laptop configurato correttamente funziona bene quasi sempre. Quando non accade, il costo non consiste in un commit errato. Consiste nel ripristinare un backup, sempre che tu ne abbia uno.

Definisci il raggio d'azione prima di discuterne

Il raggio d'azione è l'insieme delle risorse che un processo può raggiungere. Per un agente eseguito con il tuo normale utente sul tuo normale computer, questo insieme è più ampio di quanto immagini la maggior parte delle persone.

Include ~/.ssh/id_ed25519, che di solito non è cifrata perché ti sei stancato di digitare la passphrase. Include ~/.aws/credentials e ~/.config/gh/hosts.yml, che per progettazione contengono testo in chiaro. Include ogni repository adiacente in ~/code, compresi quelli con stringhe di connessione alla produzione in un file env locale. Include la cronologia della shell, che contiene token incollati una sola volta. Include anche la rete a cui è collegato il laptop, spesso una rete domestica o aziendale con servizi non autenticati.

Niente di tutto questo richiede un agente malevolo. Basta un comando eseguito con sicurezza, ma errato. rm -rf "$BUILD_DIR"/* con BUILD_DIR non impostato, che si espande in /* e aggira il rifiuto predefinito di GNU rm di eliminare direttamente /, un git clean -xfd nella directory sbagliata, un docker system prune -af --volumes che elimina anche il database locale, oppure un chmod -R 777 eseguito sulla home directory. Gli agenti vengono addestrati sullo stesso Internet che ha insegnato questi comandi a tutti gli altri.

Il meccanismo che ti protegge non è il giudizio dell'agente. È il fatto che la macchina su cui si produrrebbe il danno è una macchina che eri disposto a perdere.

Il calcolo dei costi è noioso. Ed è proprio questo il punto.

Un piccolo VPS costa pochi dollari al mese. Ripristinare un laptop usato da uno sviluppatore richiede un'intera giornata, anche nel caso migliore: ti accorgi subito del problema e hai un backup.

Fai il calcolo con i tuoi numeri. Prendi la tua tariffa oraria e moltiplicala per le ore necessarie a reinstallare un sistema operativo, ripristinare una home directory, ruotare una chiave SSH, ruotare un personal access token e clonare nuovamente venti repository. Confronta il risultato con il costo di dodici mesi del server più piccolo offerto dal provider. Il punto di pareggio si raggiunge con meno di un incidente ogni diversi anni, e l'incidente non deve essere catastrofico per superarlo. Un solo pomeriggio perso a causa di un ambiente locale danneggiato ripaga già l'intero anno.

La seconda parte del calcolo riguarda gli snapshot. Uno snapshot creato prima di un'esecuzione rischiosa trasforma un esito negativo da "ripristinare tutto il mio ambiente" a "eseguire il rollback e provare un prompt diverso". Sul laptop che stai usando per leggere questo testo, questa possibilità non esiste: non puoi creare uno snapshot di una macchina mentre la usi come postazione di lavoro.

Il panorama a ottobre 2026

Esistono tre risposte corrette alla domanda «dove deve essere eseguito l’agente?». Tutte presentano lo stesso compromesso tra la solidità dell’isolamento e la quantità di configurazione che si è disposti ad accettare.

Una micro VM locale. Gli strumenti di questa categoria avviano una macchina virtuale reale sull’hardware locale, vi montano il repository e consentono all’agente di avere accesso come root al suo interno. clawk è l’esempio attuale e la sua proposta coincide con la tesi di questo articolo: fornire agli agenti di coding una VM Linux usa e getta, non il laptop. A ottobre 2026 supporta macOS 14 e versioni successive su Apple silicon, con supporto sperimentale a Linux tramite Firecracker, e si installa con brew install clawkwork/tap/clawk. Eseguire clawk all’interno di un repository avvia la sandbox e collega un agente; clawk down la arresta e clawk destroy la rimuove. L’isolamento è fornito da un hypervisor, quindi è solido. Il limite è che la VM risiede sulla macchina che si porta con sé, utilizza parte della memoria disponibile e si arresta quando si chiude il coperchio.

Un container. Docker è la soluzione che la maggior parte delle persone ha già installato ed è realmente utile.

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

--rm elimina il container all’uscita e --network none lo avvia senza alcun accesso alla rete, una configurazione predefinita adatta a una compilazione o a un’esecuzione di test. È importante capire cosa non offre questa soluzione: un container condivide il kernel dell’host, quindi una vulnerabilità del kernel può consentire di evadere dall’isolamento; inoltre, il confine scompare non appena si aggiunge --privileged o si monta /var/run/docker.sock affinché l’agente possa «usare Docker». Montare il socket Docker in un container equivale a concedere a quel container l’accesso root all’host.

Un normale VPS che si può ricreare. Non richiede nuovi strumenti, offre un vero isolamento a livello di kernel, consente di usare gli snapshot del provider e continua a funzionare quando si spegne il laptop. È il modello descritto nel resto di questa guida ed è quello che resiste alle esecuzioni prolungate degli agenti, perché un’attività che richiede quattro ore non dipende dal fatto che si sia tornati a casa.

Il modello VPS: assegna all'agente un utente dedicato

Parti da un server già messo in sicurezza. I primi dieci minuti su un nuovo VPS coprono gli aspetti non specifici dell'agente: aggiornamenti, accesso non-root, SSH con sole chiavi e firewall.

Crea quindi un account utilizzato esclusivamente dall'agente, in modo che un errore al suo interno non possa interferire con il resto del server.

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 indica che non esiste alcuna password da indovinare e che si accede all'account con sudo -u agent o con una chiave SSH. Nota che agent non appartiene intenzionalmente al gruppo sudo. Un agente con sudo dispone dei privilegi root, e root può leggere i file di tutti gli altri utenti: in questo caso la separazione appena creata è solo apparente. Se l'agente deve davvero installare pacchetti, è un motivo per assegnargli un intero server dedicato, non per concedergli sudo su un server condiviso. Le regole generali sono descritte in privilegi minimi per gli utenti Linux su un VPS.

Verifica il confine di sicurezza prima di fidarti dell'account. Come utente agent, prova a elencare la directory home del tuo account:

sudo -u agent ls /home/you

Dovresti vedere ls: cannot open directory '/home/you': Permission denied. Se invece visualizzi un elenco di file, la tua directory home è leggibile da altri utenti e l'agente può leggere qualsiasi file al suo interno che non sia protetto separatamente, ad esempio un file .env leggibile da tutti. Correggi il problema con sudo chmod 700 /home/you. Questa verifica non protegge la tua chiave SSH privata: ssh ignora un file di chiave privata accessibile ad altri utenti, quindi qualsiasi chiave che funzioni per te è già illeggibile da agent, indipendentemente dai permessi della directory home.

Tieni le credenziali completamente fuori dalla macchina

Lo scopo di una macchina usa e getta viene meno se vi copi i secret di produzione. La regola è semplice: su quella macchina non deve esserci alcuna credenziale che non saresti disposto a ruotare oggi stesso.

Per git, inoltra il tuo SSH agent invece di copiare una chiave. La chiave privata resta sul tuo laptop e attraverso la connessione passano soltanto le richieste di firma.

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

Il secondo comando dovrebbe restituire Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Questo dimostra che git push funzionerà senza alcun file di chiave presente sul server. Esegui successivamente ls -la ~/.ssh sulla macchina e verifica che non contenga alcuna chiave privata.

L'inoltro dell'agent presenta un solo rischio concreto, che va dichiarato chiaramente: mentre sei connesso, chiunque disponga dell'accesso root su quel server può usare il socket inoltrato per autenticarsi a tuo nome. Su un server in cui l'unico altro utente sei tu, questo è un compromesso accettabile. Su una macchina condivisa non lo è; in quel caso, la soluzione migliore è una deploy key limitata a un solo repository. Le opzioni sono descritte in Nozioni di base sulla gestione delle chiavi SSH.

Per le chiavi API, assegna all'agent una chiave dedicata con un proprio limite di spesa e salvala in un file di proprietà dell'utente agent con modalità 600. Quando la macchina viene distrutta, revoca quella chiave invece di chiederti se sia stata esposta. Monitorare la spesa dei modelli per ogni chiave è anche il modo per mantenere prevedibili i valori riportati in Controllo dei costi di un agent AI su un VPS.

Limitare l'accesso dell'agente alla rete

L'isolamento del filesystem definisce solo metà del confine. L'altra metà è il traffico in uscita: ciò con cui il processo può comunicare. Linux può filtrare il traffico in uscita in base all'utente che lo ha creato. Questo si adatta esattamente a questo modello.

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

Le regole vengono lette in ordine. Per questo la regola finale REJECT intercetta tutto ciò che le righe precedenti non hanno consentito. Esegui il test come agente:

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

Il comando dovrebbe fallire subito con un errore curl: (7) Failed to connect to example.com, seguito da un messaggio che varia in base alla versione di curl in uso. La regola di rifiuto risponde infatti immediatamente invece di lasciare la connessione in attesa. Una richiesta HTTPS allo stesso host dovrebbe continuare a funzionare.

Ci sono due limiti da considerare. Primo, queste regole vengono perse al riavvio successivo se non le salvi, usando sudo apt install -y iptables-persistent e poi sudo netfilter-persistent save. Secondo, il filtro si applica a porte e indirizzi, non ai nomi. Una regola che consente la porta 443 permette di raggiungere qualsiasi host HTTPS su Internet. Questo è sufficiente per raggiungere l'API del modello, ma anche per raggiungere un servizio pastebin. Un vero elenco di domini consentiti richiede che il traffico passi attraverso un proxy in grado di leggere il nome host richiesto. Si tratta di una configurazione più complessa di quella che la maggior parte degli ambienti gestiti da un singolo sviluppatore vuole adottare. Dichiara soltanto ciò che hai effettivamente configurato: controllo del traffico in uscita a livello di porta, su una macchina che eri disposto a perdere.

Ripristinare uno stato pulito tra le attività

Avere uno stato pulito per ogni attività è un vantaggio spesso sottovalutato. Un agente che ha lavorato per tre ore sull'ultimo ticket può aver lasciato pacchetti installati, migrazioni applicate solo in parte, un node_modules obsoleto e un working tree Git con modifiche che nessuno ha esaminato. L'attività successiva eredita tutto questo e si finisce per consumare il tempo dedicato alla revisione per capire quale problema appartiene a quale esecuzione. Un agente con un ambito più ristretto lascia meno residui fin dall'inizio. Abbinare quindi una macchina usa e getta a una skill che spinge l'agente ad applicare la modifica minima funzionante mantiene abbastanza contenute sia le differenze sia lo stato residuo da poterli esaminare.

La soluzione più economica consiste nell'usare un checkout nuovo per ogni attività.

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

La soluzione più solida consiste nel creare uno snapshot del provider una sola volta, subito dopo aver configurato la macchina e prima che qualsiasi agente la utilizzi. Il ripristino dello snapshot riporta l'intero sistema, compresi i pacchetti, a uno stato noto. La maggior parte dei provider offre questa funzione nel pannello di controllo o tramite un'API, anziché come comando da eseguire sulla macchina. I passaggi esatti dipendono quindi dal provider. La regola è creare lo snapshot quando la macchina è ancora in uno stato semplice e invariato.

Conserva fuori dalla macchina usa e getta tutto ciò che ti serve. In pratica, questo significa soprattutto fare il push dei branch invece di accumularli localmente. Se la macchina contiene qualcosa di cui sentiresti la mancanza, esegui un backup corretto con backup restic su un VPS. Una macchina che puoi distruggere è utile solo se la sua distruzione non causa realmente problemi.

Se vuoi diversi ambienti isolati senza pagare diversi server, un VPS più grande può ospitare direttamente VM guest. La virtualizzazione annidata su un VPS spiega come funziona, incluso come verificare se il provider la consente. In questo caso l'isolamento ha effetti in entrambe le direzioni. Se preferisci che due agenti coordinino il lavoro sulla stessa macchina invece di restare completamente separati, una sessione Claude Code può inviare testo direttamente a un'altra senza far passare ogni consegna da te.

Quando un laptop è davvero sufficiente, se usato con attenzione

Siate onesti su questo punto, perché esagerare i vantaggi dell'isolamento porta le persone a smettere di ascoltare.

Se controllate ogni comando prima dell'esecuzione, un laptop è sufficiente. La richiesta di autorizzazione è un controllo reale e eseguire Claude Code in sicurezza su un server spiega cosa blocca effettivamente ciascun livello. Se il lavoro riguarda un solo repository e sulla macchina non sono presenti credenziali di produzione, il raggio d'azione di un eventuale incidente è già limitato. Se le sessioni dell'agente sono brevi e supervisionate, anche la finestra di esposizione è breve.

La situazione cambia non appena ignorate le richieste di autorizzazione. È un aspetto da considerare ora che la modalità automatica è l'impostazione predefinita di Claude Code e una nuova installazione non chiede più conferma prima di modificare file o eseguire comandi. Le esecuzioni senza supervisione, i processi notturni e qualsiasi flusso di lavoro in cui approvate un piano e poi vi allontanate eliminano il controllo umano che garantiva il contenimento. In questi casi deve essere la macchina a fornire quel controllo. Lo stesso vale per tutto ciò che amplia il raggio d'azione dell'agente, incluso eseguire un agente di coding su un VPS operando contemporaneamente su più repository.

La decisione non riguarda davvero quanto vi fidate del modello. Riguarda ciò che si trova accanto al modello quando commette un errore.

FAQ

Un container offre un isolamento sufficiente per un agente di coding?

Per la maggior parte delle attività, sì, a due condizioni. Il container non deve essere eseguito con --privileged e non deve avere /var/run/docker.sock montato al suo interno, perché ciascuna delle due configurazioni offre al processo un percorso verso root sull'host. Un container condivide il kernel dell'host, quindi il confine di isolamento è più debole rispetto a quello di una macchina virtuale. Se l'agente esegue codice non attendibile scaricato da Internet, è preferibile usare una VM reale o un server separato.

L'agente deve avere sudo sul server?

No. Assegnargli sudo annulla l'isolamento creato, perché root può leggere gli account di tutti gli altri utenti del sistema. Crea l'utente dell'agente senza sudo e concedigli l'accesso in scrittura soltanto alla propria directory di lavoro. Se l'attività richiede davvero l'installazione di pacchetti, assegna all'agente un'intera macchina dedicata invece di concedergli root su una macchina condivisa.

Come posso consentire all'agente di eseguire il push su git senza mettere la mia chiave SSH sul server?

Inoltra il tuo agente SSH con ssh -A durante la connessione. Le richieste di firma viaggiano sulla connessione, mentre la chiave privata resta sul tuo laptop; in questo modo ssh -T git@github.com esegue l'autenticazione e git push funziona senza alcuna chiave privata sul server. Il limite è che root su quel server può usare il socket inoltrato mentre sei connesso. Perciò, su qualsiasi macchina condivisa con altre persone, usa una deploy key limitata al repository.

Di quali dimensioni deve essere il VPS per un agente?

Il lavoro dell'agente consiste soprattutto nel modificare file, eseguire build e lanciare test. Dimensiona quindi la macchina in base alla build, non al modello. Un modello ospitato viene eseguito sull'hardware del provider, generando traffico di rete e un carico locale minimo. L'agente stabilisce comunque un requisito minimo: al 20 ottobre 2026, i requisiti di sistema di Claude Code indicano 4 GB di RAM come minimo. Parti da 4 GB anche per le attività di scripting e passa a 8 GB se il repository crea container o compila componenti sostanziali.

Con quale frequenza devo eliminare e ricreare la macchina?

Ricrea la macchina quando lo stato non è più spiegabile e, come minimo, ogni volta che una credenziale presente sul sistema potrebbe essere stata esposta. Un checkout pulito tra un'attività e l'altra gestisce il normale degrado dello stato. Uno snapshot acquisito prima della prima esecuzione dell'agente ti offre inoltre un'immagine di sistema pulita a cui tornare. Se ricreare la macchina sembra troppo costoso, è un segnale che qualcosa di importante risiede su una macchina che avevi considerato usa e getta.