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.

Definire il raggio d’azione prima di discuterne

Per raggio d’azione si intende l’insieme delle risorse che un processo può raggiungere. Per un agent in esecuzione con il tuo utente normale sul tuo computer abituale, questo insieme è più ampio di quanto immagini la maggior parte delle persone.

Include ~/.ssh/id_ed25519, che di solito non è crittografata perché ti sei stancato di inserire la passphrase. Include ~/.aws/credentials e ~/.config/gh/hosts.yml, che per progettazione sono in testo normale. Include ogni repository parallelo in ~/code, compresi quelli con le stringhe di connessione alla produzione in un file env locale. Include la cronologia della shell, che contiene i token che hai incollato una 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 agent malevolo. Basta un comando eseguito con sicurezza ma errato. rm -rf con una variabile non impostata che viene espansa in /, un git clean -xfd nella directory sbagliata, un docker system prune -af --volumes che elimina anche il database locale, un chmod -R 777 eseguito sulla directory home. Gli agent vengono addestrati sullo stesso Internet che ha insegnato quei comandi a chiunque altro.

Il meccanismo che ti protegge non è il giudizio dell’agent. È il fatto che il computer che contiene i dati esposti al danno è un computer 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 luglio 2026

Esistono tre risposte valide alla domanda «dove deve essere eseguito l’agente?». Tutte richiedono di bilanciare gli stessi due aspetti: la solidità dell’isolamento e il livello di configurazione che si è disposti ad accettare.

Una micro-VM locale. Gli strumenti di questa categoria avviano una macchina virtuale reale sul proprio hardware, vi montano il repository e consentono all’agente di avere accesso a root al suo interno. clawk è l’esempio attuale e la sua proposta corrisponde esattamente alla tesi di questo articolo: fornire agli agenti di coding una VM Linux usa e getta, non il laptop. A luglio 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. Per avviare la sandbox e collegare un agente, eseguire clawk all’interno di un repository; per arrestarla, usare clawk down; per rimuoverla, usare clawk destroy. L’isolamento è garantito da un hypervisor, quindi è solido. Il limite è che la VM risiede sulla macchina che si porta con sé: utilizza memoria locale 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 gli impedisce completamente l’accesso alla rete. È una buona impostazione predefinita per una build o un’esecuzione di test. È importante chiarire cosa non offre: un container condivide il kernel dell’host, quindi una vulnerabilità del kernel può consentire l’uscita 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 accesso root sull’host.

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

Il modello VPS: assegnare all'agente un utente dedicato

Partire da un sistema adeguatamente protetto. Le prime dieci minuti su un nuovo VPS coprono gli aspetti non specifici dell'agente: aggiornamenti, accesso non-root, SSH con sole chiavi e firewall.

Creare quindi un account utilizzato esclusivamente dall'agente, in modo che un errore al suo interno non possa compromettere altre risorse 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 significa che non esiste alcuna password da indovinare e che si accede all'account tramite sudo -u agent o una chiave SSH. Notare che agent non appartiene volutamente al gruppo sudo. Un agente con sudo dispone dei privilegi root e root può leggere i file di ogni altro utente; in questo modo la separazione appena configurata sarebbe solo apparente. Se l'agente deve realmente installare pacchetti, questo è un motivo per assegnargli un intero server dedicato, non per concedergli sudo su un server condiviso. Le regole generali sono descritte in principio del privilegio minimo per gli utenti Linux su un VPS.

Verificare il confine di sicurezza prima di considerare l'isolamento affidabile. Come utente agent, provare a leggere un file appartenente al proprio account:

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

Dovrebbe essere visualizzato cat: /home/you/.ssh/id_ed25519: Permission denied. Se vengono invece visualizzate chiavi o altri dati crittografici, la directory home è in modalità 755 e l'isolamento non è ancora effettivo. Correggerlo con sudo chmod 700 /home/you.

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.

Limita l'accesso dell'agent alla rete

L'isolamento del filesystem definisce metà del confine di sicurezza. L'altra metà è il traffico in uscita: le destinazioni con cui il processo può comunicare. Linux può filtrare il traffico in uscita in base all'utente che lo ha generato. 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 valutate in ordine, quindi l'ultima regola REJECT intercetta tutto ciò che le righe precedenti non hanno consentito. Esegui il test come agent:

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

Il comando dovrebbe fallire con curl: (7) Failed to connect to example.com port 80: Connection refused, perché la regola di rifiuto risponde 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 con sudo apt install -y iptables-persistent e poi con 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. Una vera allow-list di domini richiede che il traffico passi attraverso un proxy in grado di leggere il nome host richiesto. È una configurazione più complessa di quella che la maggior parte degli ambienti con un solo sviluppatore vuole gestire. Dichiara soltanto ciò che hai effettivamente implementato: controllo del traffico in uscita a livello di porte, 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é sopravvalutare l’isolamento porta le persone a non ascoltare più.

Se verificate ogni comando prima dell’esecuzione, un laptop è sufficiente. La richiesta di autorizzazione è un controllo reale e eseguire Claude Code in sicurezza su un server richiede di capire che 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 nel momento in cui ignorate le richieste di autorizzazione. È un aspetto da considerare ora che la modalità automatica diventa quella predefinita di Claude Code il 14 agosto 2026 e una nuova installazione non chiede più conferma prima di modificare file o eseguire comandi. Le esecuzioni non supervisionate, 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. A quel punto deve occuparsene la macchina. Lo stesso vale per tutto ciò che amplia l’accesso dell’agente, incluso eseguire un agente di coding su un VPS su più repository contemporaneamente.

La decisione non riguarda realmente 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 condizioni fornisce al processo un percorso verso root sull’host. Un container condivide il kernel dell’host, quindi il confine di isolamento è più debole rispetto a 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. Concedergli sudo annulla l’isolamento configurato, perché root può leggere gli account di tutti gli altri utenti sulla macchina. Crea l’utente dell’agente senza sudo e concedigli l’accesso in scrittura soltanto alla propria directory di lavoro. Se l’installazione di pacchetti è realmente necessaria, assegna all’agente un’intera macchina di sua proprietà 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 sulla macchina?

Inoltra il tuo SSH agent con ssh -A quando ti connetti. Le richieste di firma viaggiano attraverso la 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. Tieni presente che root su quel server può usare il socket inoltrato mentre sei connesso. Su qualsiasi macchina condivisa con altre persone, usa quindi una deploy key limitata al repository.

Di quali dimensioni deve essere un 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, quindi genera traffico di rete e un carico locale minimo. Inizia con 2 GB di RAM per le attività di scripting e passa a 8 GB se il repository esegue build di container o compila componenti sostanziali.

Con quale frequenza devo distruggere e ricreare la macchina?

Ricrea la macchina quando lo stato non è più spiegabile e, come minimo, ogni volta che una credenziale presente sulla macchina potrebbe essere stata esposta. Un nuovo checkout tra un’attività e l’altra gestisce il drift quotidiano, mentre uno snapshot acquisito prima della prima esecuzione dell’agente ti fornisce un’immagine di sistema pulita a cui tornare. Se la ricreazione sembra costosa, è un segnale che qualcosa di importante risiede su una macchina che avevi definito usa e getta.