Perché Isolare gli Agenti AI di Coding in MicroVM (e Come Farlo)

Diciamola tutta: gli agenti AI per il coding hanno rivoluzionato il modo di lavorare. Strumenti come Claude Code e Codex sanno scrivere funzionalità, risolvere bug e rifattorizzare codice a una velocità che fino a pochi anni fa sembrava fantascienza. Ma c'è un aspetto che nessuno sottolinea abbastanza — questi agenti sono anche terribilmente bravi a ficcare il naso in posti dove non dovrebbero.

Vuoi che esplorino il tuo cluster Kubernetes? Possono farlo. Che si colleghino in SSH ai server di produzione? Certo che sì. Che eseguano comandi con privilegi elevati? Tecnicamente, se glielo permetti.

È qui che la questione diventa seria. Vuoi la potenza di un assistente AI, ma hai anche bisogno di dormire sonni tranquilli sapendo che l'ambiente di produzione è al sicuro. La soluzione? Sandbox — e più precisamente, usare microVM per dare a questi agenti un universo isolato tutto per loro.

La Realtà dei Fatti sulla Sicurezza

Ecco una verità scomoda: far girare agenti AI in modalità non sorvegliata equivale sostanzialmente a eseguire codice non attendibile sulla tua macchina. Le aziende che costruiscono questi strumenti non cercano di rubare le tue credenziali — non è il loro modello di business. Ma il web è creativo, e vettori di attacco come lo Slopsquatting e gli attacchi di prompt injection stanno diventando sempre più sofisticati.

Gli agenti hanno mitigazioni integrate, questo è vero. Ma le mitigazioni non sono perfette, e nuove vulnerabilità emergono regolarmente. Basta guardare le recenti vulnerabilità di sandbox escape — ci ricordano che strumenti di isolamento leggeri come bwrap, per quanto utili, non sono fortezze impenetrabili.

I container offrono un ulteriore livello di protezione, ma ecco il punto delicato: i container condividono il kernel dell'host. Vulnerabilità kernel recenti hanno dimostrato il potenziale di escalation dei privilegi, il che significa che un attaccante determinato potrebbe potenzialmente sfondare l'isolamento del container. Per un confine di sicurezza, non è l'ideale.

È qui che le microVM diventano un'opzione attraente. A differenza dei container, ogni microVM esegue il proprio kernel. Anche se un attaccante trova una vulnerabilità nel kernel, è confinato nell'ambiente di quella specifica microVM. È sicurezza tramite isolamento — e funziona sorprendentemente bene nella pratica.

Cosa Sono le MicroVM, in Pratica?

Se conosci le macchine virtuali tradizionali, il concetto ti è già familiare: isolamento completo con kernel proprio, risorse di sistema proprie, tutto proprio. Lo svantaggio è sempre stato che le VM sono pesanti — ci mettono minuti ad avviarsi, consumano RAM significativa, e in generale sembrano esagerate per far girare un agente di coding.

Le microVM ribaltano tutto. Mantengono i benefici di sicurezza delle VM tradizionali (kernel separato, forte isolamento) mentre si avviano in centinaia di millisecondi invece che minuti. Ottieni il confine di sicurezza di una VM con un'impronta più simile a un container.

Su Fedora Linux, c'è un approccio elegante che usa il runtime krun per Podman. Questo significa che puoi usare lo stesso workflow Podman che già conosci per i container, ma con isolamento microVM sotto il cofano. Nessuno strumento nuovo da imparare, nessuna configurazione complessa — basta cambiare il runtime.

Come Installarlo

Installare il runtime krun su Fedora è semplice:

dnf install crun-krun

Una volta installato, avviare una microVM è quasi identico ad avviare un container normale:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Fine. Ora hai una microVM completamente isolata che esegue Fedora. Il workflow che già conosci, ma con confini di sicurezza più solidi.

Alcune Cose da Tenere a Mente

Le microVM non sono container normali, quindi ci sono alcune considerazioni pratiche da tenere presenti:

Assegna risorse sufficienti. I valori predefiniti potrebbero essere troppo conservativi per un agente di coding che deve compilare codice, eseguire test e gestire file di progetto. Usa le annotazioni krun per garantire allocazione adeguata di CPU e RAM — altrimenti potresti ritrovarti con kill OOM nei momenti più inopportuni.

Verifica la versione di libkrun. Le versioni precedenti alla 1.8 hanno un bug che impedisce l'input corretto da tastiera. Se non riesci a premere Invio nel tuo agente di coding, probabilmente è per questo. Aggiorna per evitare frustrazione.

La gestione degli utenti è diversa. La microVM si avvia sempre come root indipendentemente dalla direttiva USER che imposti nel Dockerfile. Dovrai o passare manualmente a un altro utente dopo l'avvio, o costruire il cambio utente nel tuo script entrypoint.

Un Setup Pratico per Claude Code

Facciamo un esempio reale: isolare Claude Code per un progetto Python usando uv per la gestione dei pacchetti. Useremo Podman Compose per l'orchestrazione.

Prima, installa Podman Compose:

dnf install podman-compose

Il setup si compone di tre file: un Dockerfile, un docker-compose.yaml e uno script entrypoint.

Il Dockerfile

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Crea gruppo e utente con UID/GID dell'host
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Tool che cambiano raramente
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# RPM che cambiano frequentemente
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

Nota alcuni punti chiave: creiamo un utente non privilegiato, installiamo gli strumenti necessari (uv e Claude Code), e strutturiamo il Dockerfile in modo che le dipendenze che cambiano spesso siano in fondo. Questo ottimizza la cache di build — non dovrai reinstallare uv ogni volta che aggiungi un nuovo pacchetto.

Il File Compose

Il docker-compose.yaml si occupa di montare la directory del progetto, impostare le label SELinux e configurare l'allocazione delle risorse. Qui le microVM si differenziano leggermente dai container normali — dovrai gestire la traduzione UID/GID e le richieste esplicite di risorse hardware.

Lo Script Entrypoint

L'entrypoint gestisce il cambio utente che abbiamo menzionato prima. Dato che le microVM si avviano sempre come root, questo script deve passare al tuo utente non privilegiato prima di cedere il controllo alla shell o all'agente di coding.

Ne Vale la Pena lo Sforzo Extra?

Assolutamente sì. La proposta di valore è chiara: puoi usare potenti agenti AI di coding senza dare loro accesso illimitato al tuo workstation, alle credenziali del cluster o all'ambiente di produzione. L'isolamento è reale — kernel separato, namespace separato, tutto separato.

Il sovraccarico di setup è minimo rispetto ai benefici di sicurezza. E una volta che hai l'infrastruttura in place, far girare ambienti agent isolati diventa routine.

Per sviluppatori e team che gestiscono codebase sensibili, fanno deploy su cluster di produzione o lavorano in settori regolamentati, non è opzionale — è essenziale. Gli agenti AI di coding sono strumenti, e come ogni strumento potente, hanno bisogno di misure di sicurezza adeguate.

In Conclusione

Le microVM su Fedora Linux rappresentano un punto d'incontro pratico tra la sicurezza della virtualizzazione completa e la praticità dei container. Si avviano velocemente, isolano efficacemente e si integrano senza problemi con i workflow Podman esistenti.

Se stai usando agenti AI di coding nel tuo flusso di sviluppo, soprattutto in modalità non sorvegliata, valuta di dargli una propria sandbox microVM. Il tuo io futuro — e il tuo team di sicurezza — te ne saranno grati.

Gli strumenti ci sono. La documentazione è solida. E la tranquillità? Non ha prezzo.