Dai agli agenti AI una VM usa e getta

Perché una VM usa e getta è migliore del laptop

Fornisci a un agente di programmazione una VM usa e getta: il danno peggiore che può causare è distruggere una macchina che puoi ricreare in dieci minuti. L'agente ottiene comunque l'accesso 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 ricade il danno. Su un laptop, l'agente condivide una directory home con le tue 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 un checkout e di nient'altro che valga la pena sottrarre.

Questo è l'intero argomento, basato sull'asimmetria e non sulla probabilità. Un agente prudente su un laptop configurato con attenzione non crea quasi mai problemi. Quando invece li crea, il costo non consiste in un commit errato. Consiste nel ripristino da un backup, se ne hai uno.

Definire il raggio d’azione prima di discuterne

Il raggio d’azione indica l’insieme degli elementi che un processo può raggiungere. Per un agente eseguito come utente normale sulla macchina che usi normalmente, questo insieme è più ampio di quanto immagini la maggior parte delle persone.

Include ~/.ssh/id_ed25519, che di solito non è crittografato 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 volta. Include anche la rete a cui è connesso il laptop, spesso una rete domestica o aziendale con servizi non autenticati.

Nulla di tutto questo richiede un agente dannoso. Basta un comando eseguito con sicurezza ma errato. rm -rf con una variabile non impostata che si espande 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 home directory. Gli agenti sono addestrati sulla stessa Internet che ha insegnato quei comandi a tutti gli altri.

Il meccanismo che ti protegge non è il giudizio dell’agente. È il fatto che la macchina che subisce 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. Recuperare un laptop di sviluppo richiede una giornata, e questo nello scenario migliore: il problema viene rilevato subito e hai un backup.

Fai il calcolo usando 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 tuo provider. Il punto di pareggio si raggiunge con meno di un incidente ogni diversi anni, e l'incidente non deve essere catastrofico per superare quella soglia. Un solo pomeriggio perso a causa di un ambiente locale corrotto è già sufficiente a coprire il costo dell'anno.

La seconda parte del calcolo riguarda gli snapshot. Uno snapshot creato prima di un'operazione rischiosa trasforma un esito negativo da "ripristinare tutto" a "tornare indietro e provare un prompt diverso". Questa opzione non esiste sul laptop che stai usando per leggere questo testo, perché non puoi creare uno snapshot di una macchina mentre la usi come postazione di lavoro.

Il panorama a luglio 2026

Esistono tre risposte corrette alla domanda «dove deve essere eseguito l'agent» e tutte comportano un compromesso tra gli stessi due fattori: 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 vera macchina virtuale sul proprio hardware, vi montano il repository e consentono all'agent di avere privilegi root al suo interno. clawk è l'esempio attuale e la sua proposta corrisponde esattamente alla tesi di questo articolo: fornire agli agent di coding una VM Linux temporanea, non il proprio laptop. A luglio 2026 supporta macOS 14 e versioni successive su Apple silicon, con supporto sperimentale per Linux tramite Firecracker, e si installa con brew install clawkwork/tap/clawk. Si esegue clawk all'interno di un repository per avviare la sandbox e collegare un agent, clawk down per arrestarla e clawk destroy per rimuoverla. L'isolamento è fornito da un hypervisor, quindi è solido. Il limite è che la VM risiede sulla macchina che si porta con sé, consuma memoria 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 buona impostazione predefinita per una build o un test. È importante capire cosa non offre: un container condivide il kernel dell'host, quindi una vulnerabilità del kernel può consentire l'uscita dal container; inoltre l'isolamento scompare nel momento in cui si aggiunge --privileged o si monta /var/run/docker.sock affinché l'agent possa «usare Docker». Montare il socket Docker in un container equivale a concedere a quel container privilegi root sull'host.

Un VPS standard che si può ricreare. Non richiede nuovi strumenti, offre un vero isolamento a livello di kernel e 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 agent, 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 già messo in sicurezza. La prima decina di minuti su un nuovo VPS copre gli aspetti che non sono specifici dell'agente: aggiornamenti, accesso non-root, SSH con sole chiavi e firewall.

Creare quindi un account usato esclusivamente dall'agente, in modo che un errore al suo interno non possa interessare altre parti 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. Notare che agent non appartiene deliberatamente al gruppo sudo. Un agente con sudo dispone dell'accesso root, e root può leggere i file di tutti gli altri utenti; in questo caso, quindi, la separazione appena creata è solo apparente. Se l'agente deve realmente installare pacchetti, è un motivo per assegnargli un intero server, non per concedergli sudo su un server condiviso. Le regole generali sono riportate in principio del privilegio minimo per gli utenti Linux su un VPS.

Verificare il confine di isolamento prima di considerarlo 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 invece vengono visualizzati materiali crittografici, la directory home è in modalità 755 e l'isolamento non è ancora effettivo. Correggerlo con sudo chmod 700 /home/you.

Mantieni le credenziali completamente fuori dalla macchina

Lo scopo di una macchina usa e getta viene meno se vi copi i segreti di produzione. La regola è semplice: su quel sistema non deve esserci alcuna credenziale che ti dispiacerebbe ruotare questo pomeriggio.

Per git, inoltra il tuo agente SSH invece di copiare una chiave. La chiave privata rimane sul laptop e attraverso la connessione passano solo 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 ls -la ~/.ssh sul sistema al termine e verifica che non contenga alcuna chiave privata.

L'inoltro dell'agente presenta un'unica controindicazione concreta, che va dichiarata chiaramente: mentre sei connesso, chiunque disponga dell'accesso root a quel server può usare il socket inoltrato per autenticarsi come te. Su un server il cui unico altro utente sei tu, è un compromesso accettabile. Su un sistema condiviso, invece, non lo è; in questo caso è preferibile 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'agente 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 eliminata, revoca la 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 agente AI su un VPS.

Limita ciò che l'agente può raggiungere sulla rete

L'isolamento del filesystem definisce solo metà del perimetro. L'altra metà è l'uscita dalla rete: ciò con cui il processo può comunicare. Linux può filtrare il traffico in uscita in base all'utente che lo ha creato, quindi 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, quindi l'ultima regola REJECT intercetta tutto ciò che le righe precedenti non hanno consentito. Verificalo come agente:

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 comunque riuscire.

Ci sono due limitazioni 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. È 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. Questa soluzione è più complessa di quanto la maggior parte delle configurazioni gestite da un singolo sviluppatore richieda. Dichiara solo ciò che hai realmente 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à

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 usare il tempo previsto per la revisione per capire a quale esecuzione appartenga ogni problema.

La soluzione più semplice consiste nel creare 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ù completa consiste nel creare uno snapshot del provider una sola volta, subito dopo la configurazione della macchina e prima che qualsiasi agente la utilizzi. Il ripristino dello snapshot riporta l'intero sistema, inclusi 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, quindi i passaggi esatti dipendono dal provider. È importante creare lo snapshot quando la macchina è ancora in uno stato invariato.

Conserva tutto ciò che ti serve al di fuori della macchina temporanea. In pratica, esegui il push dei branch invece di conservarli solo 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 eliminare è utile solo se la sua eliminazione non causa realmente problemi.

Se vuoi diversi ambienti isolati senza pagare diversi server, un VPS più grande può ospitare direttamente VM guest. Virtualizzazione annidata su un VPS spiega come funziona, incluso come verificare se il provider la consente.

Quando un laptop è davvero adeguato

Siate onesti su questo punto, perché esagerare l'importanza dell'isolamento porta le persone a non ascoltare più.

Se controllate ogni comando prima dell'esecuzione, un laptop è adeguato. La richiesta di autorizzazione è un controllo reale e eseguire Claude Code in sicurezza su un server illustra cosa blocca effettivamente ogni livello. Se il vostro lavoro riguarda un solo repository e sulla macchina non sono presenti credenziali per ambienti 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. Le esecuzioni senza supervisione, i processi notturni e qualsiasi workflow in cui approvate un piano e vi allontanate eliminano il controllo umano che garantiva il contenimento. A quel punto deve essere la macchina a garantire il contenimento. Lo stesso vale per qualsiasi elemento che estenda la portata dell'agente, incluso eseguire un agente di programmazione su un VPS su diversi 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 contenitore offre un isolamento sufficiente per un agente di programmazione?

Per la maggior parte delle attività, sì, a due condizioni. Il contenitore non deve essere eseguito con --privileged e non deve avere /var/run/docker.sock montato al suo interno, perché entrambe le configurazioni danno al processo un percorso verso root sull'host. Un contenitore condivide il kernel dell'host, quindi il confine è meno solido rispetto a una macchina virtuale. Se l'agente esegue codice non attendibile scaricato da Internet, preferire una VM reale o un server separato.

L'agente deve avere sudo sul server?

No. Concedergli sudo annulla l'isolamento creato, perché root può leggere gli account di tutti gli altri utenti sul sistema. Creare l'utente dell'agente senza sudo e concedergli l'accesso in scrittura solo alla propria directory di lavoro. Se l'attività richiede realmente l'installazione di pacchetti, assegnare 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 copiare la mia chiave SSH sul server?

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

Di quali dimensioni deve essere il VPS per un agente?

Il lavoro dell'agente consiste soprattutto nella modifica di file, nell'esecuzione di build e nell'esecuzione di test. Dimensionare 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 quasi nullo. Iniziare con 2 GB di RAM per le attività di scripting e passare a 8 GB se il repository crea container o compila componenti sostanziali.

Con quale frequenza devo distruggere e ricreare la macchina?

Ricreare la macchina quando lo stato non è più spiegabile e, come requisito minimo, ogni volta che una credenziale sulla macchina potrebbe essere stata esposta. Un nuovo checkout tra un'attività e l'altra gestisce la deriva quotidiana, mentre uno snapshot creato prima della prima esecuzione dell'agente fornisce un'immagine di sistema pulita a cui tornare. Se la ricostruzione sembra costosa, è un segnale che qualcosa di importante risiede su una macchina che si era deciso di trattare come usa e getta.