Sandbox AI: i 7 migliori strumenti di sicurezza del 2026

Vercel Sandbox è la migliore sandbox AI in assoluto per la maggior parte dei team che eseguono agenti nel cloud nel 2026. Ma il divario decisivo non è quello di prezzo: tra le soluzioni gestite, il carico normalizzato di questo confronto costa da $55.55 a $288 al mese. In produzione conta piuttosto verificare che il codice generato dal modello disponga sia di un kernel di esecuzione separato sia di un percorso di uscita che non esponga mai credenziali reali.

Le migliori sandbox AI in breve

I prezzi e i limiti dei prodotti riportati di seguito sono stati verificati il 19 agosto 2026. I sette strumenti coprono sia gli agenti di coding locali sia quelli gestiti nel cloud, perché questi carichi di lavoro hanno modelli di rischio e di costo diversi.

L'ordine non segue volutamente il prezzo più basso. Northflank presenta il conto cloud gestito più basso nel modello, $55.55, ma Vercel vince nel complesso: il confine Firecracker, la policy di egress modificabile a runtime e l'intermediazione delle credenziali costituiscono una base più pulita per un team di prodotto che vuole distribuire un agente senza gestire un cluster. Docker è secondo perché offre un confine locale insolitamente completo senza costi del fornitore, ma non è un runtime gestito per attività rivolte ai clienti.

La regola di scelta è semplice: scegliere lo strumento meno costoso che supera entrambi i confini richiesti dal carico di lavoro reale. Il primo confine mantiene il codice non attendibile dietro un kernel separato o una barriera alle syscall di robustezza analoga. Il secondo tiene i segreti di produzione e i permessi di uscita fuori da quel codice. Una VM economica che riceve una chiave API in chiaro non supera il test. Lo stesso vale per una VM ben isolata con accesso illimitato a Internet.

Come sono state selezionate

OpenAI ora raccomanda agli operatori della sicurezza di eseguire i workflow ad alto rischio senza accesso ai sistemi di produzione sensibili o a Internet aperta, verificare regolarmente i confini della sandbox, monitorare le azioni degli agenti e definire l'ambito autorizzato. Le indicazioni dell'Agents SDK sono ancora più esplicite: bisogna presumere tentativi di prompt injection ed esfiltrazione, separare orchestrazione e calcolo e tenere le credenziali fuori dall'ambiente in cui gira il codice generato. Sono istruzioni operative, non casi limite teorici. OpenAI ha pubblicato le indicazioni attuali il 10 agosto.

Da qui nasce il test dei due confini applicato a ogni verdetto:

1. Confine di esecuzione: ogni job ostile riceve un kernel, una microVM, una VM o un isolamento delle syscall documentato? Il processo o il filesystem di un utente può raggiungere quello di un altro?
2. Confine di egress e credenziali: è possibile negare la rete per impostazione predefinita, autorizzare solo destinazioni nominate e inserire le credenziali dopo che il traffico ha lasciato la sandbox?
3. Confine di controllo: policy, log, quote e identità possono restare fuori dal codice che il modello potrebbe riscrivere?
4. Compatibilità operativa: il prodotto è locale, API-first, edge-native, orientato alle GPU o una piattaforma completa? Anche il confine giusto diventa inutilizzato se inserito nel modello operativo sbagliato.
5. Costo ricorrente: quanto costa lo stesso carico dopo l'esaurimento del credito promozionale?

Questo è un confronto con prezzi e analisi, non un penetration test dichiarato. Ogni prezzo, limite e funzionalità proviene da una pagina proprietaria attiva. Per essere incluso, un prodotto doveva fornire dettagli proprietari sufficienti a valutare sia l'isolamento sia l'egress e offrire un confine per codice ostile, non un generico ambiente di sviluppo.

Il carico normalizzato è di 10,000 esecuzioni al mese. Ogni esecuzione dura 5 minuti, richiede 2 vCPU e 4 GiB di memoria e mantiene attiva la CPU per 1 minuto, mentre per i restanti 4 l'agente attende file, pacchetti o operazioni di rete. La distinzione è importante: Vercel e Cloudflare tariffano la CPU attiva in modo diverso dalla memoria allocata, mentre E2B, Daytona, Northflank e Modal addebitano il calcolo per l'intera finestra di esecuzione.

Il lavoro moderno con gli agenti ha due facce distinte. Se l'assistente di coding gira su un laptop, è utile confrontarlo con i workflow analizzati in Codex vs Claude Code vs Cursor. Se l'agente controlla un browser, anche la sessione del browser entra a far parte del confine, come spiega il confronto sui migliori browser per agenti AI. Una sandbox non sostituisce la scelta dell'agente giusto, così come un agente potente non sostituisce l'isolamento dei suoi strumenti.

1. Vercel Sandbox: la migliore sandbox AI per i team cloud

Vercel Sandbox è la scelta migliore in assoluto per un team di prodotto che cerca un'API gestita, un confine di calcolo robusto e segreti che non debbano entrare nel codice generato.

Ogni sandbox gira in una microVM Firecracker. Gli ambienti integrati includono Node.js 22, 24 e 26, oltre a Python 3.13; per un runtime personalizzato si usa un'immagine OCI. Le sessioni Pro ed Enterprise possono durare fino a 24 ore, contro i 45 minuti di Hobby, e il limite di risorse sale da 4 vCPU con Hobby a 8 con Pro e 32 con Enterprise. La memoria è fissata a 2 GB per vCPU, quindi il carico a 2 vCPU di questo confronto riceve esattamente 4 GB.

Il vantaggio di sicurezza emerge dopo l'avvio della VM. Il firewall di rete di Vercel può modificare la policy mentre il processo è in esecuzione, inserire una credenziale soltanto quando una richiesta in uscita lascia la sandbox e inoltrare richieste selezionate attraverso un proxy proprio. Diventa così possibile strutturare un job sicuro in due fasi: autorizzare il registro dei pacchetti durante la configurazione, rimuovere l'accesso esteso e infine eseguire il codice generato dal modello con un elenco ristretto di destinazioni. La sandbox riceve gli strumenti necessari senza ereditare le chiavi usate per chiamare GitHub, un'API di modelli o uno storage a oggetti.

Il punto debole è la configurazione, non l'isolamento. La documentazione del firewall Vercel indica allow-all come valore predefinito, quindi una nuova sandbox ha accesso illimitato a Internet. Il modello di configurazione di Vercel installa i pacchetti con accesso esteso, poi passa a un'allowlist definita dall'utente prima di eseguire il codice non attendibile. Se l'orchestrazione salta il secondo passaggio, Firecracker continua a proteggere l'host, ma la sandbox può inviare all'esterno qualunque dato vi sia stato inserito. Il broker delle credenziali impedisce al guest di copiare la chiave in chiaro, ma non può impedire al codice generato di usarla in modo improprio tramite una richiesta consentita mentre il job è attivo.

L'aggiornamento sull'osservabilità del 7 luglio trasforma questa policy in un controllo operativo. I team possono monitorare CPU attiva, memoria allocata, trasferimento dati, sandbox in esecuzione e sessioni, per poi raggruppare le metriche per Sandbox Name e Sandbox Session ID. Vercel include l'osservabilità di Sandbox in ogni piano, con interrogazioni manuali nei piani Pro ed Enterprise. La conseguenza sul budget è concreta: assegnare un tag a ogni tipo di job, attribuirne la spesa e indagare sulle sessioni il cui egress o la cui durata escono dall'intervallo abituale.

Ideale per: agenti di coding gestiti, interpreti di codice, sistemi di creazione delle anteprime ed esecuzione rivolta ai clienti su uno stack Vercel.
Punto di forza: Firecracker, policy di egress a runtime, intermediazione delle credenziali e proxy opzionale delle richieste riuniti in un solo prodotto.
Prezzi: Hobby costa $0. Pro costa $20/mese con $20 di credito d'uso incluso, poi $0.128 per ora di CPU attiva, $0.0212 per GB-ora di memoria allocata, $0.60 per 1 milione di creazioni, $0.15 per GB di rete e $0.08 per GB-mese di snapshot. Enterprise ha prezzi personalizzati.
Prova gratuita: Hobby include 5 ore di CPU attiva, 420 GB-ora di memoria, 5,000 creazioni, 20 GB di rete, 10 sandbox simultanee e 15 GB di spazio per gli snapshot. È disponibile una prova Pro.

Una sequenza sicura per distribuire Vercel

1. 1

   Definire il modello di minaccia

   Elencare ciò che il codice generato può leggere, scrivere, chiamare ed esporre. Le credenziali del repository, i database di produzione, i metadati cloud e le API amministrative interne devono restare fuori dalla sandbox per impostazione predefinita.

2. 2

   Creare un'immagine pulita

   Partire da un runtime integrato o da un'immagine OCI che contenga soltanto gli strumenti necessari al job. Tenere i dati dei clienti e le credenziali a lunga durata fuori dall'immagine e da ogni snapshot.

3. 3

   Aprire brevemente l'egress di configurazione

   Autorizzare soltanto il registro dei pacchetti, l'host del codice sorgente o lo store degli artefatti necessari alla configurazione. Se serve temporaneamente un accesso esteso, il cambio di policy deve essere un passaggio esplicito dell'orchestrazione, non una consuetudine informale.

4. 4

   Chiudere la rete

   Prima dell'avvio del codice generato dal modello, passare a un elenco di destinazioni specifiche e negare tutto il resto. Se una policy stabile lo richiede, inoltrare le chiamate ad alto rischio attraverso un proxy proprio.

5. 5

   Intermediare ogni segreto

   Inserire una credenziale soltanto per l'host e la forma di richiesta approvati. Non copiare mai il valore grezzo in una variabile d'ambiente solo perché la microVM è isolata.

6. 6

   Osservare e distruggere

   Trasmettere i log, limitare durata e risorse, conservare soltanto l'output necessario e poi distruggere la sandbox. Eseguire periodicamente un test che tenti di raggiungere un host bloccato e recuperare una chiave intermediata.

Verdetto: Vercel è la scelta predefinita quando si vogliono ridurre al minimo le decisioni infrastrutturali senza accettare un confine debole. Conviene scegliere altro quando i requisiti più difficili sono l'esecuzione locale, il cloud di proprietà o una maggiore disponibilità di GPU.

2. Docker Sandboxes: la migliore per gli agenti di coding locali

Docker Sandboxes è la soluzione locale più solida del confronto perché è un prodotto microVM distinto, non un normale container con un nome rassicurante.

La microVM costituisce il confine di fiducia principale. Ogni sandbox dispone di un kernel separato e del proprio Docker Engine, senza alcun percorso verso il daemon Docker dell'host. Il traffico TCP in uscita passa attraverso un proxy lato host con una policy deny-by-default; il traffico UDP e ICMP diretto verso l'esterno viene bloccato; le credenziali API possono essere inserite negli header HTTP senza collocare i valori grezzi nella VM. È un'architettura locale seria per sessioni non presidiate di Codex, Claude Code, Copilot CLI, OpenCode o Kiro.

Anche il prezzo del fornitore è inequivocabile: la CLI sbx costa $0, non prevede tariffe per utente e può essere utilizzata commercialmente. La governance centralizzata dell'organizzazione, che comprende policy gestite per rete, filesystem e MCP oltre ai log di audit, richiede un abbonamento a pagamento separato. Il costo di calcolo effettivo si sposta sul laptop o sulla workstation: il confronto corretto non è tra i $0 di Docker e i $55.55 di Northflank, bensì tra hardware locale e tempo dell'operatore da una parte e servizio gestito dall'altra.

Il punto critico si trova esattamente dove il lavoro locale incontra l'host. La modalità diretta monta il workspace in lettura e scrittura, quindi un agente può modificare hook Git, configurazioni CI, attività dell'IDE, target del Makefile, script dei pacchetti e altri file che uno sviluppatore potrebbe poi eseguire fuori dalla VM. --clone rende il repository dell'host di sola lettura e fornisce all'agente un clone privato: è l'opzione più sicura per repository sconosciuti o esecuzioni autonome. Docker avverte inoltre che nell'allowlist predefinita possono restare domini wildcard estesi, che le skill condivise degli agenti costituiscono uno spazio in lettura e scrittura tra sandbox se non vengono disattivate e che i server MCP stdio locali girano sull'host, non nella microVM.

Docker Sandboxes 0.38.0 è stato pubblicato il 6 agosto con Kit spec v2, gestione MCP di prima classe, credenziali OAuth conservate sull'host, policy Cedar a livello di organizzazione e un controllo --deny-network HOST per singola sandbox. Ha inoltre corretto CVE-2026-17106. La conseguenza è una regola di manutenzione, non un trofeo da release note: il software di isolamento locale deve seguire una cadenza di aggiornamento obbligatoria, mentre una superficie MCP appena centralizzata richiede la stessa verifica di fiducia dell'host di qualunque altro ponte in uscita dalla VM.

Docker Sandboxes è quindi eccellente per la postazione di uno sviluppatore, ma poco adatto come backend cloud pronto all'uso. Protegge la workstation dalla maggior parte delle attività dell'agente, mentre il workspace, le skill condivise e le integrazioni MCP lato host restano ponti espliciti. Ognuno va valutato separatamente.

Ideale per: agenti di coding locali che devono installare pacchetti, creare build Docker ed eseguire attività non presidiate senza un accesso esteso all'host.
Punto di forza: isolamento in microVM, rete in uscita deny-by-default tramite proxy e inserimento delle credenziali lato host a $0 di costo del fornitore.
Prezzi: $0 per la CLI, senza costo per utente; la governance dell'organizzazione ha prezzi personalizzati.
Prova gratuita: la CLI principale e le sandbox locali isolate sono gratuite.

Verdetto: Docker Sandboxes è indicato per gli agenti locali, con la modalità clone attiva per il lavoro rischioso, regole di rete estese ridotte e ogni server MCP dell'host trattato come componente privilegiato. Prima di confrontarlo con API gestite bisogna quantificare hardware e attività operative che va a sostituire.

3. Cloudflare Sandbox SDK: la migliore opzione edge basata sulle policy

Cloudflare Sandbox SDK è la scelta più adatta quando il piano di controllo risiede già in Workers e l'agente necessita di un percorso verso Internet governato con precisione.

Cloudflare Containers esegue ogni sandbox in una VM separata, con isolamento di filesystem, processi e rete, oltre a quote delle risorse per sandbox. La pagina sulla sicurezza è esplicita sull'architettura multi-tenant: i processi all'interno di una sandbox condividono file, processi e rete localhost, quindi bisogna usare una sandbox distinta per ogni utente. Questa indicazione vale più di una generica promessa di isolamento completo, perché mostra all'architetto dove tracciare il confine dell'identità.

Il secondo confine è un'estensione naturale di Workers. L'accesso a Internet è consentito per impostazione predefinita, ma enableInternet = false cambia la postura: il traffico viene negato salvo autorizzazione da parte di allowedHosts o di un handler in uscita. L'handler viene eseguito nel runtime Workers attendibile, all'esterno della sandbox; può inserire un header di autorizzazione e limitare una credenziale alla singola istanza della sandbox. Il guest non riceve mai il token reale. Con Internet disabilitata, il traffico non HTTP è negato e il DNS può usare soltanto i server Cloudflare, chiudendo così una semplice via di esfiltrazione.

I due limiti dichiarati con franchezza sono esposizione e maturità. Un tunnel rapido usa un hostname casuale trycloudflare.com senza token di accesso separato; chiunque conosca l'URL può raggiungerlo, quindi un'anteprima sensibile richiede comunque l'autenticazione dell'applicazione. La panoramica aggiornata il 13 agosto consiglia @cloudflare/sandbox@next per i nuovi progetti e descrive SDK 1.0 come anteprima. Può essere accettabile per un prodotto iniziale con un raggio d'impatto limitato. Un acquirente regolamentato che ammette solo dipendenze stabili potrebbe dover attendere oppure bloccare la versione stabile attuale e rinunciare ad alcune funzionalità.

Anche le dimensioni fisse delle istanze Cloudflare modificano il confronto dei prezzi. Il job normalizzato richiede 2 vCPU e 4 GiB, ma l'istanza più piccola compatibile è standard-3, con 2 vCPU, 8 GiB e 16 GB di disco. Il basso costo della memoria mantiene competitiva la piattaforma, ma in questo esempio metà della memoria allocata rimane inutilizzata.

Ideale per: agenti basati su Workers, applicazioni edge, terminali nel browser, contesti di codice e carichi soprattutto HTTP con egress programmabile.
Punto di forza: credenziali e logica di egress possono risiedere in Workers fuori dalla sandbox, con ambito limitato per destinazione e istanza.
Prezzi: Workers Free non include Containers né Sandbox SDK. Workers Paid costa $5/mese e include 375 minuti-vCPU, 25 ore-GiB di memoria e 200 ore-GB di disco. Il consumo aggiuntivo costa $0.000020 per secondo-vCPU, $0.0000025 per secondo-GiB e $0.00000007 per secondo-GB di disco.
Prova gratuita: nessuna prova dedicata di Sandbox; Containers richiede Workers Paid.

Verdetto: Cloudflare è la migliore alternativa a Vercel quando Workers è già il livello di controllo attendibile e le policy HTTP costituiscono la superficie di controllo principale. Prima va disattivato l'accesso a Internet; ogni tunnel deve avere l'autenticazione applicativa; il budget deve tenere conto delle dimensioni fisse delle istanze.

4. E2B: la migliore API microVM per runtime di agenti portabili

E2B è l'opzione microVM API-first più mirata per i team che vogliono una sandbox per agenti indipendente da una piattaforma di distribuzione più ampia.

Ogni sandbox E2B viene eseguita in una microVM Firecracker con kernel, memoria e page cache propri. La presenza di un kernel separato conta: per raggiungere l'host, una vulnerabilità del kernel all'interno di un guest deve comunque superare Firecracker. SDK v2.0.0 e versioni successive attivano inoltre per impostazione predefinita l'accesso sicuro al controller, che richiede il token restituito alla creazione della sandbox per le chiamate al controller. Potrebbe essere necessario ricreare i template personalizzati meno recenti prima che funzionino con questa postura.

L'API offre le primitive di rete corrette: allow_internet_access, allowOut, denyOut e un proxy di egress. Disabilitare l'accesso a Internet equivale a negare 0.0.0.0/0. La richiesta di creazione attuale rende visibili questi controlli, ma nelle pagine di prodotto citate E2B non presenta un broker di credenziali di prima classe paragonabile a quelli di Vercel, Cloudflare, Daytona o Docker. Se il codice generato deve usare un token di produzione, è opportuno collocare un proxy attendibile fuori da E2B e inserire lì la credenziale, invece di affidarla a una variabile d'ambiente del guest.

E2B diventa più interessante quando il controllo della distribuzione è il requisito più difficile. Enterprise BYOC supporta attualmente AWS e GCP; l'azienda afferma inoltre che template, snapshot, log di runtime e traffico sensibile restano nella VPC del cliente. È meno interessante per chi cerca un'istanza personalizzata economica da 4 GiB: nella pagina dei prezzi, CPU e RAM personalizzate richiedono Pro, che aggiunge $150/mese prima del consumo.

Hobby è generoso per la valutazione. Costa $0 più il consumo, include un credito d'uso una tantum di $100, non richiede una carta, consente sessioni fino a 1 ora e supporta 20 sandbox simultanee. Pro estende le sessioni a 24 ore e la simultaneità a 100, con capacità acquistabile fino a 1,100. L'upgrade aumenta i limiti, ma non crea crediti d'uso ricorrenti.

Ideale per: agenti API-first, interpreti di codice, carichi di valutazione e imprese che richiedono BYOC su AWS o GCP.
Punto di forza: kernel Firecracker per sandbox dietro un'API semplice e progettata per gli agenti.
Prezzi: Hobby costa $0 più il consumo. Pro costa $150/mese più il consumo. Enterprise ha un costo base personalizzato più il consumo. La CPU costa $0.000014 per secondo-vCPU, cioè $0.0504 per ora-vCPU; la memoria costa $0.0000045 per secondo-GiB, cioè $0.0162 per ora-GiB. Lo storage include 10 GiB con Hobby e 20 GiB con Pro.
Prova gratuita: credito d'uso una tantum di $100 con Hobby, senza carta di credito.

Verdetto: E2B è l'API microVM indipendente più lineare del gruppo. È indicata quando portabilità o BYOC contano più del costo base di Pro; un proxy esterno attendibile per le credenziali va incluso nell'architettura, non rimandato a una fase successiva di hardening.

5. Daytona: il migliore proxy di credenziali con runtime flessibili

Daytona offre il broker di credenziali documentato con maggiore chiarezza in questo gruppo, oltre alla possibilità di scegliere tra container predefiniti ad avvio rapido e VM Linux o Windows dedicate.

La gestione dei segreti è insolitamente concreta. Daytona conserva una credenziale cifrata dell'organizzazione, inserisce nella sandbox soltanto un segnaposto opaco e sostituisce il valore reale in un header HTTPS in uscita presso il proprio proxy. Il proxy invia il valore esclusivamente a un host autorizzato e rimuove dalla risposta l'eventuale segreto restituito prima che questa raggiunga il guest. Il codice generato può usare un token senza mai leggerlo.

Il progetto prevede una pericolosa via d'uscita: se si omette il campo hosts di un segreto, questo diventa privo di restrizioni e il proxy può sostituire il valore reale per qualunque destinazione. La documentazione consiglia di definire un'allowlist per ogni segreto. La sostituzione funziona inoltre soltanto negli header HTTPS, non nei body delle richieste, nelle query string, tramite HTTP in chiaro o con valori trasformati, come Basic Auth codificata in Base64. Se un fornitore accetta una chiave solo nel body, il broker di Daytona non può proteggere quella chiamata.

I controlli di rete comprendono allowlist di domini e CIDR, blocco completo del traffico in uscita e proxy upstream. Le restrizioni delle organizzazioni Tier 1 e Tier 2 hanno la precedenza e non possono essere allentate per la singola sandbox. Tier 3 e Tier 4 consentono per impostazione predefinita il pieno accesso a Internet, che va limitato per i job ostili. La domanda importante per l'acquirente non è se Daytona supporti un'allowlist, bensì se la combinazione tra tier dell'organizzazione e configurazione della sandbox produca la policy effettiva desiderata.

La scelta del runtime è l'altro elemento decisivo. I container Linux sono predefiniti e si avviano rapidamente. Daytona offre anche classi VM Linux e VM Windows dedicate, oltre a sandbox GPU con opzioni H100, H200, RTX PRO 6000, RTX 5090 e RTX 4090. Per attività di build attendibili, la classe container può offrire il giusto compromesso in termini di velocità. Per codice multi-tenant ostile, la classe VM va selezionata esplicitamente, senza presumere che la parola sandbox garantisca il confine più robusto.

Ideale per: agenti che devono chiamare API esterne senza poter vedere le credenziali, carichi misti Linux e Windows ed esecuzione su GPU.
Punto di forza: segreti segnaposto, inserimento HTTPS limitato per host e rimozione dei segreti dalle risposte fuori dal guest.
Prezzi: il servizio pubblico prevede un costo base di $0 ed è a consumo. La CPU costa $0.0504 per ora-vCPU, la memoria $0.0162 per ora-GiB e lo storage $0.000108 per ora-GiB oltre i primi 5 GiB. Il calcolo gestito dal cliente è disponibile tramite vendita diretta.
Prova gratuita: $200 di calcolo gratuito senza carta di credito.

Verdetto: Daytona è la scelta migliore quando distribuire i segreti è più difficile che creare le sandbox. Bisogna sempre impostare hosts, scegliere una VM per codice tenant realmente ostile e includere il tier di rete effettivo dell'organizzazione nella verifica prima del lancio.

6. Northflank: la migliore per BYOC e controllo della piattaforma

Northflank è l'opzione migliore quando la sandbox deve risiedere nel proprio account cloud e condividere una piattaforma applicativa più ampia con servizi, database, job e policy.

Northflank offre microVM Kata Container o gVisor per un isolamento dei carichi di livello VM. La pagina attuale sull'infrastruttura dichiara che ogni container riceve un kernel proprio, con confini di namespace, risorse, storage e rete. Un service mesh aggiunge TLS reciproco tra i carichi, mentre policy di rete a livello di progetto e networking privato riducono gli accessi involontari tra progetti.

La superficie di distribuzione è più ampia di quella di ogni runner API-first qui presente. Northflank può utilizzare il proprio cloud gestito o collegare account AWS, GCP, Azure o Civo; supporta inoltre Kubernetes del cliente on-premises, su bare metal o in un cloud pubblico. Nei pool di nodi BYOC abilitati alle microVM, i carichi ricevono per impostazione predefinita l'isolamento in microVM. È una soluzione valida per residenza dei dati, contratti cloud esistenti, accesso a servizi privati e team enterprise che vogliono governare insieme infrastruttura applicativa e sandbox.

Questa stessa ampiezza costituisce il limite. Un piccolo prodotto basato su agenti non ha automaticamente bisogno di cluster, progetti, service mesh, template di distribuzione, database e piano di controllo della piattaforma. Northflank può offrire la stima più bassa delle risorse del confronto e, nello stesso tempo, costare di più sul piano organizzativo se nessuno gestisce la piattaforma. L'acquirente giusto desidera già BYOC o la piattaforma circostante. Tutti gli altri dovrebbero confrontare le ore di ingegneria con Vercel o E2B prima di celebrare il costo unitario.

Il piano Sandbox gratuito è utile per imparare a usare la piattaforma: include 2 servizi gratuiti, 1 database gratuito e 2 cron job gratuiti. Il calcolo di produzione viene fatturato al secondo a $0.01667 per ora-vCPU e $0.00833 per ora-GB. L'egress costa $0.06 per GB e lo storage SSD $0.15 per GB-mese.

Ideale per: BYOC, servizi privati, requisiti di residenza dei dati e team che vogliono una sola piattaforma per sandbox e infrastruttura applicativa.
Punto di forza: isolamento Kata o gVisor in distribuzioni cloud gestite o di proprietà del cliente.
Prezzi: Sandbox è gratuito. Il piano a consumo parte da $0/mese e addebita $0.01667 per ora-vCPU, $0.00833 per ora-GB di memoria, $0.06 per GB di egress e $0.15 per GB-mese di SSD. Enterprise ha prezzi personalizzati.
Prova gratuita: piano Sandbox gratuito con 2 servizi, 1 database e 2 cron job.

Verdetto: Northflank è la risposta corretta quando il posizionamento nel cloud di proprietà o una piattaforma unificata sono obbligatori. Non è automaticamente conveniente per un team di due persone, perché il contatore più basso può comunque creare il lavoro di piattaforma più grande.

7. Modal: la migliore per Python, ML e carichi intensivi su GPU

Modal è la sandbox migliore del confronto quando il codice generato opera accanto a Python, notebook, inferenza dei modelli o carichi GPU intermittenti.

Modal Sandboxes usa gVisor, che intercetta e limita le chiamate di sistema tra il carico guest e il kernel dell'host. Una Sandbox predefinita non può accettare connessioni di rete in ingresso né accedere ad altre risorse Modal. Questo riduce il raggio d'impatto all'interno della piattaforma e offre una solida primitiva di esecuzione per analisi dei dati e job che fanno largo uso di modelli.

La policy in uscita è meno prudente. Per impostazione predefinita, le sandbox possono collegarsi a qualunque IP pubblico. Modal supporta un blocco completo della rete, allowlist CIDR e un'allowlist di domini in beta per il traffico TLS, ma questi controlli devono essere attivati. Anche le modifiche delle policy a runtime hanno una condizione iniziale: per restringere in seguito un elenco di domini o CIDR, la sandbox deve essere stata creata con quella categoria di allowlist già abilitata. block_network=True non può essere modificato tramite lo stesso percorso dinamico, quindi il ciclo di vita di un agente che apre la rete soltanto durante la configurazione va progettato in anticipo.

Il vantaggio economico di Modal risiede nella piattaforma serverless ML circostante, non nel contatore sandbox più basso. Un core fisico equivale a 2 vCPU e costa $0.00003942 per core-secondo. La memoria costa $0.00000667 per secondo-GiB. Starter costa $0 più il calcolo, include $30 di credito mensile, 3 postazioni nel workspace e simultaneità per 100 container e 10 GPU. Team costa $250/mese più il calcolo, restituisce $100 di credito mensile e aggiunge postazioni illimitate, simultaneità per 5,000 container e 50 GPU, un proxy con IP statico, budget per ambiente, domini personalizzati e rollback delle distribuzioni.

Modal è dunque facile da giustificare quando la stessa piattaforma gestisce anche modelli, funzioni pianificate e job GPU. Lo è meno per un semplice interprete di codice i cui requisiti principali siano l'isolamento in microVM e l'intermediazione delle credenziali. La pagina attuale sulla sicurezza di Sandbox documenta controllo della rete e isolamento della piattaforma, ma non un meccanismo esterno per inserire segreti esplicito quanto quello di Daytona o Cloudflare.

Ideale per: agenti Python, notebook, analisi dei dati, pipeline ML e carichi di codice generato che usano intensamente le GPU.
Punto di forza: Sandboxes gVisor integrate con la piattaforma serverless CPU e GPU di Modal.
Prezzi: Starter costa $0 più il calcolo e include $30 di credito mensile. Team costa $250/mese più il calcolo e include $100 di credito mensile. Enterprise ha prezzi personalizzati. La CPU di Sandbox costa $0.00003942 per core fisico al secondo, dove 1 core equivale a 2 vCPU; la memoria costa $0.00000667 per secondo-GiB.
Prova gratuita: $30 di credito Starter mensile ricorrente.

Verdetto: Modal vince quando la sandbox è una componente di un sistema ML o GPU. Per una semplice API destinata a codice ostile, Vercel, Cloudflare, E2B o Daytona offrono al responsabile della sicurezza un percorso più diretto.

Cosa rivela davvero il conto mensile

La stima gestita più economica è $55.55, la più alta $288: una differenza di $232.45 al mese. È rilevante su grandi volumi, ma poca cosa rispetto al costo di un ingegnere che mantiene un runner interno o di un incidente che espone un token di produzione. Sul piano della sicurezza, non ha senso accettare segreti in chiaro o egress aperto per risparmiare un importo mensile a tre cifre contenute.

Sono stime comparative, non fatture. Il totale Vercel presuppone che il costo base Pro di $20 sia compensato dai $20 di credito d'uso incluso. Per soddisfare la richiesta di 2 vCPU, Cloudflare deve allocare un'istanza standard-3 con 8 GiB e 16 GB di disco. E2B include il piano Pro da $150 perché il confronto usa un'allocazione personalizzata da 4 GiB. Modal sottrae il proprio credito Starter ricorrente di $30. I $200 di Daytona e i $100 di E2B sono crediti una tantum, quindi non riducono la riga del costo a regime.

Il metodo di tariffazione può ribaltare l'ordine. Vercel e Cloudflare addebitano la CPU attiva, quindi un agente legato all'I/O paga meno durante l'attesa. Se la CPU lavora per tutti i 5 minuti, Vercel sale da $113.34 a $284.01 e Cloudflare da $91.63 a $187.63. Un agente di coding che compila intensamente deve modellare lo scenario impegnativo. Un agente browser in attesa delle pagine può avvicinarsi di più all'ipotesi di 1 minuto.

Il punto di pareggio pratico tra Vercel e Daytona è di 1.58 minuti di CPU attiva in un'esecuzione da 5 minuti, cioè circa 95 secondi. Al di sotto di questo punto, nel modello vince la tariffazione della CPU attiva di Vercel; al di sopra, le tariffe fisse sul tempo di esecuzione di Daytona diventano più economiche prima di rete e storage. È una decisione di workflow mascherata da prezzo: bisogna misurare per quanto tempo l'agente calcola davvero, anziché dimensionare il budget sul solo tempo trascorso.

La voce più importante del budget è la responsabilità operativa. La stima di $55.55 di Northflank sembra eccezionale finché il team non aggiunge cluster, policy, template di distribuzione, risposta agli incidenti e un ingegnere capace di gestirli. I $288 di E2B sembrano molti finché BYOC non evita di costruire una piattaforma separata. Un acquisto valido confronta l'onere operativo totale, non soltanto il prezzo delle vCPU.

Quale strumento scegliere

Scegliere Vercel Sandbox quando serve la migliore opzione gestita predefinita e si è pronti a restringere la policy di rete prima della fase non attendibile. La scelta si sposta altrove quando BYOC, esecuzione locale o maggiore disponibilità di GPU sono obbligatori.

Scegliere Docker Sandboxes quando uno sviluppatore esegue localmente Codex, Claude Code, Copilot CLI, OpenCode o Kiro. Per repository rischiosi va usata la modalità clone. È preferibile passare a uno strumento gestito quando tra i requisiti compaiono job dei clienti, alta simultaneità, uptime centralizzato o API remote.

Scegliere Cloudflare Sandbox SDK quando Workers è già il piano di controllo attendibile e la maggior parte delle chiamate autorizzate usa HTTP. La scelta cambia se la maturità precedente alla versione 1.0 dell'SDK o le dimensioni fisse dei Container generano più rischio di quanto ne eliminino.

Scegliere E2B quando si desidera un'API Firecracker indipendente o BYOC su AWS e GCP. La scelta cambia se la memoria personalizzata rende difficile giustificare il costo base Pro di $150 o se non si vuole creare un proxy esterno per le credenziali.

Scegliere Daytona quando l'agente deve chiamare servizi esterni con un segreto che non può leggere, oppure quando classi VM Linux, VM Windows e GPU devono stare dietro una sola API. La scelta cambia se ogni carico è una semplice microVM Linux e le opzioni di runtime aggiuntive non offrono alcun valore.

Scegliere Northflank quando le sandbox devono risiedere accanto a servizi privati nel proprio account cloud. La scelta cambia se l'organizzazione dovrebbe creare un team di piattaforma soltanto per risparmiare sul contatore di calcolo.

Scegliere Modal quando il livello di esecuzione è inseparabile da Python, notebook, inferenza dei modelli, funzioni pianificate o GPU. La scelta cambia se il job consiste soltanto nell'esecuzione di codice ostile e un'API più orientata alla sicurezza può svolgerlo con meno lavoro sulle policy.

Per chi deve scegliere l'agente prima del runner, il confronto sui migliori assistenti di coding AI copre la decisione a monte. Le due scelte vanno tenute distinte: l'assistente stabilisce come viene generato il lavoro; la sandbox stabilisce ciò che quel lavoro può raggiungere.

Le soluzioni da evitare

Un runner la cui documentazione di sicurezza si ferma alla parola “isolato”: chi si occupa degli acquisti ha bisogno di risposte scritte su confine del kernel, separazione dei tenant, egress predefinito, posizione delle credenziali, log e responsabilità degli aggiornamenti. Se il fornitore non sa rispondere a tutte e sei le domande, non bisogna inserire dati di produzione o chiavi nel guest.

Un container Docker Engine grezzo scambiato per Docker Sandboxes: docker run non è il prodotto microVM sbx e non ne eredita il kernel separato, il proxy di rete lato host, l'inserimento delle credenziali o il confine del workspace in modalità clone. I nomi non definiscono l'architettura.

Docker Sandboxes in modalità diretta su un repository sconosciuto: la VM protegge gran parte dell'host, ma l'agente modifica direttamente l'albero di lavoro. Un hook Git o uno script di pacchetto alterato può essere eseguito in seguito sull'host. Usare --clone e ispezionare ogni ponte in uscita dalla VM.

Un tunnel rapido Cloudflare senza autenticazione applicativa: l'hostname casuale non dispone di un token di accesso separato. L'URL va considerato individuabile e il servizio deve integrare l'autenticazione prima di esporre un'anteprima sensibile.

Un segreto Daytona senza hosts: omettere il campo rende il segreto privo di restrizioni. Il broker è utile soltanto quando la destinazione approvata è esplicita.

Qualunque fase di configurazione lasciata su allow-all: Vercel documenta chiaramente il modello corretto: accesso esteso per la configurazione, seguito da una fase di esecuzione limitata. Se la policy non viene mai ristretta, la microVM riduce il rischio di compromissione dell'host, ma non impedisce al codice di inviare dati all'esterno.

È questo l'elemento che divide la categoria. L'isolamento risponde alla domanda: “Il codice può evadere?”. La policy di egress e delle credenziali risponde invece: “Che cosa può fare il codice senza evadere?”. Entrambi i problemi possono produrre lo stesso risultato per l'azienda: la fuoriuscita dei dati di produzione.

Cosa fare lunedì

Lunedì non si comincia con una demo del fornitore, ma con un inventario di una pagina di tutti i punti in cui viene eseguito codice generato da un modello.

1. Individuare ogni percorso di esecuzione. Includere agenti di coding locali, job CI, agenti browser, notebook per l'analisi dei dati, interpreti di codice e sistemi che creano anteprime per i clienti.
2. Disegnare il confine attuale. Annotare l'isolamento del kernel o del runtime, i file montati, le reti raggiungibili e ogni credenziale disponibile al guest.
3. Spostare i segreti all'esterno. Collocare le chiavi API in un orchestratore attendibile, un Worker, un proxy dell'host o il broker di credenziali del fornitore. Una variabile d'ambiente della sandbox resta leggibile dal codice.
4. Negare l'egress per impostazione predefinita. Autorizzare l'host dei pacchetti durante la configurazione, poi passare al più piccolo elenco di destinazioni prima di avviare il codice generato.
5. Eseguire due prove di guasto. Tentare di leggere il file o il processo di un altro tenant, quindi provare a inviare un token-esca a un host non autorizzato. Sono necessari sia il blocco del tentativo sia un log utile.
6. Assegnare responsabile e limiti. Qualcuno deve verificare cambiamenti delle policy, test dei confini falliti, immagini, log e spesa. Prima che il traffico cresca, impostare limiti di durata, simultaneità, CPU, memoria e budget mensile.

L'acquisto può avvenire dopo la creazione di quella pagina. Un team con soli rischi locali potrebbe fermarsi a Docker Sandboxes in modalità clone. A un team che sviluppa su Vercel potrebbe bastare modificare la policy di rete e intermediare i segreti. Una piattaforma regolamentata potrebbe scoprire che BYOC con Northflank o E2B è giustificato. Il risultato da ottenere lunedì è la decisione sul confine, non un nuovo abbonamento.

Domande frequenti

Quale strumento AI offre la sicurezza migliore?

Vercel Sandbox è la migliore scelta gestita in assoluto in questo confronto perché combina una microVM Firecracker, una policy di egress a runtime e l'intermediazione delle credenziali. Docker Sandboxes è più adatto agli agenti di coding locali, mentre Northflank o E2B diventano preferibili quando è obbligatoria la distribuzione nel proprio cloud. Vince la soluzione che soddisfa il confine di fiducia richiesto.

Quali sono le tendenze della sicurezza AI nel 2026?

La tendenza concreta punta su kernel separati, credenziali inserite fuori dal guest, egress deny-by-default e verifiche periodiche dei confini. Le indicazioni di OpenAI del 10 agosto rendono esplicita la conseguenza operativa: isolare gli agenti capaci dai sistemi di produzione e da Internet aperta, quindi monitorarne i tentativi.

Esistono sandbox AI gratuite nel 2026?

Sì. Docker Sandboxes offre una CLI da $0 senza costo per utente. Vercel ha un piano Hobby con limiti, E2B fornisce un credito una tantum da $100, Daytona offre $200 di calcolo, Northflank propone un piano Sandbox gratuito e Modal include $30 di credito Starter mensile ricorrente. Cloudflare Sandbox richiede il piano Workers Paid da $5/mese.

Che cos'è una sandbox AI?

Una sandbox AI è un ambiente di esecuzione isolato nel quale un agente può eseguire codice generato senza ereditare un accesso esteso all'host, agli altri utenti, ai sistemi di produzione, ai segreti o a percorsi di rete senza restrizioni. Una sandbox adatta alla produzione comprende sia un confine di esecuzione sia un confine separato per egress e credenziali.

Scarica la checklist per l'audit dei workflow aziendali basati sull'AI per trasformare la scelta della sandbox in un workflow definito, con responsabile, elenco dei controlli e cadenza delle verifiche.