Docker Sandboxes isola gli agenti AI in ambienti usa e getta

Far lavorare un agente AI direttamente sul PC significa concedergli un ampio ventaglio di permessi e una libertà d’azione che, in molti casi, appare davvero eccessiva. Strumenti come Claude Code, Codex o Gemini possono modificare file, installare dipendenze, eseguire comandi, compilare progetti e avviare container. Docker Sandboxes nasce per separare queste attività dal sistema operativo principale: ogni agente lavora dentro una microVM dedicata, con filesystem, rete e Docker Engine propri.

I container, che rappresentano il caposaldo di Docker, condividono il kernel dell’host e, soprattutto, diventano molto meno isolati se ricevono accesso al socket Docker principale. Docker Sandboxes crea invece una macchina virtuale leggera per ogni agente, così da concedergli privilegi elevati all’interno dell’ambiente senza trasformarli automaticamente in privilegi sul computer dell’utente.

Docker supporta diversi coding agent, fra cui Claude Code, Codex, Copilot, Cursor, Gemini, Kiro, OpenCode e Docker Agent. È disponibile anche una shell generica per usare la sandbox senza legarla a uno strumento specifico.

Docker Sandboxes: una microVM al posto del classico container

Il punto tecnico più importante riguarda il confine di isolamento. Ogni sandbox gestita con Docker Sandboxes dispone di un proprio kernel Linux, dei propri processi e di un Docker daemon indipendente. L’agente può quindi installare pacchetti con sudo, compilare software o eseguire container senza collegarsi al Docker Engine dell’host.

Con Sandboxes ogni ambiente dispone di un suo Docker Engine: l’agente può quindi eseguire docker build, creare container, reti e volumi senza interferire direttamente con quelli presenti sul sistema principale.

L’isolamento non significa però che l’agente non possa toccare il codice: la directory del progetto sul quale si desidera lavorare è resa disponibile dentro la microVM tramite filesystem passthrough. Tute le modifiche effettuate nella sandbox appaiono immediatamente anche sull’host: ne consegue che se da un lato Docker Sandboxes protegge il resto del PC, il sistema non protegge automaticamente il progetto affidato all’agente.

Un comando sbagliato può quindi cancellare o alterare file nel workspace. C’è poi un rischio meno evidente: l’agente potrebbe modificare elementi che l’utente eseguirà successivamente sull’host, come script npm, Makefile, task dell’IDE o configurazioni Git.

Per lavori più delicati Docker offre l’opzione --clone: invece di operare direttamente sulla directory originale, la sandbox utilizza una copia privata del repository. È una modalità sensata quando si vuole lasciare maggiore autonomia all’agente senza permettergli di modificare subito il progetto principale.

Internet passa attraverso un proxy controllato

Docker interviene anche sulla rete. Le connessioni HTTP e HTTPS della sandbox passano attraverso un proxy sull’host, che decide quali destinazioni l’agente può raggiungere.

Sono previste tre modalità principali: Open permette liberamente il traffico; Balanced abilita una serie di servizi comunemente necessari allo sviluppo; Locked Down parte invece da una configurazione deny-by-default e richiede regole esplicite.

Per esempio, un dominio può essere autorizzato con:

sbx policy allow network registry.npmjs.org

Un agente che deve installare pacchetti Node.js ha bisogno di raggiungere npm; uno che utilizza un modello remoto dovrà comunicare con l’API del relativo provider. In un ambiente particolarmente “delicato” conviene quindi partire da Locked Down e aprire soltanto le destinazioni realmente necessarie.

Docker segnala inoltre che la modalità Balanced include alcune wildcard abbastanza ampie: chi necessitasse di un controllo rigoroso dovrebbe quindi verificare le regole effettive con sbx policy ls.

Le API key restano fuori dalla sandbox

Una delle parti più interessanti riguarda la gestione delle credenziali. Copiare una API key direttamente nella microVM significherebbe renderla accessibile a qualsiasi processo eseguito dall’agente.

Docker utilizza invece un sistema di credential injection: il segreto resta sull’host e il proxy aggiunge la credenziale alla richiesta quando serve. La chiave non deve quindi comparire direttamente tra le variabili o nei file accessibili dalla sandbox.

I segreti possono essere gestiti anche tramite il comando sbx secret set. La protezione non elimina però ogni rischio: se una credenziale consente operazioni distruttive su un servizio remoto, l’agente potrebbe comunque richiederle. Conviene quindi assegnare token con privilegi limitati e, quando possibile, separati da quelli utilizzati normalmente dall’utente.

Docker Sandboxes supporta anche Model Context Protocol (MCP), utilizzato da molti agenti per collegarsi a strumenti esterni. Le richieste passano attraverso un gateway MCP gestito lato host.

Come si installa Docker Sandboxes

Docker Sandboxes funziona su Windows 11, macOS e Ubuntu. Su Windows richiede un chip x86-64 con supporto alla virtualizzazione e Windows Hypervisor Platform attiva. Su macOS serve un Mac Apple Silicon con macOS Sonoma 14 o successivo. Su Linux, il progetto Docker indica Ubuntu 24.04 o versioni successive e richiede KVM.

Docker Desktop non è obbligatorio. Su Windows l’installazione può essere effettuata con:

winget install -h Docker.sbx

Dopo l’autenticazione con sbx login è possibile entrare nella directory del progetto e avviare un agente. Con Claude Code, per esempio:

sbx run --name my-sandbox claude

La prima esecuzione richiede il download dell’immagine necessaria; gli avvii successivi risultano più rapidi perché l’ambiente resta memorizzato in locale.

Quando Docker Sandboxes ha davvero senso

Docker Sandboxes diventa interessante soprattutto quando si vuole concedere molta autonomia a un coding agent. Se ogni comando deve ricevere una conferma manuale, il vantaggio dell’isolamento diminuisce; se invece l’agente può installare pacchetti, eseguire build, lanciare test e creare container senza continue richieste, disporre di un perimetro sicuro separato dall’host acquista molto più valore.

Va detto però che non si tratta di una protezione assoluta. L’agente può ancora modificare i file che gli vengono affidati, utilizzare servizi Internet consentiti dalle policy e interagire con strumenti esterni autorizzati. La sandbox riduce soprattutto il raggio d’azione di un comando errato o di un agente compromesso.