Sandbox: esecuzione di codice sicura con E2B, Daytona e compagnia

Panoramica

Un agente che puo scrivere codice e anche un agente che vuole eseguirlo, e dall'istante in cui lasci codice arbitrario eseguirsi sul tuo laptop o server, una riga cattiva puo cancellare file, far trapelare segreti dal tuo ambiente o aprire una connessione che non avevi previsto. Una sandbox risolve cio dando al codice un computer fresco, isolato e usa e getta dove girare. Se il run va male, butti la sandbox e non perdi niente. Questa lezione spiega il rischio onestamente, definisce cos'e una sandbox, presenta i principali servizi e ti da una regola chiara per sapere quando usarne una e quando un run locale va bene.

Cosa imparerai

Imparerai perche eseguire codice generato da IA sulla tua macchina e un rischio di sicurezza e affidabilita, cosa offre realmente una sandbox (isolamento, usa e getta, limiti di risorse), come servizi gestiti come E2B e Daytona ne montano una a richiesta per il tuo agente, e le tre situazioni concrete che esigono sempre una sandbox. Riparti capace di decidere per compito se il codice puo girare localmente o deve essere rinchiuso.

Prerequisiti

I Corsi da 1 a 3, soprattutto il materiale sui segreti e la sicurezza del Corso 3. Devi capire che la tua macchina tiene variabili d'ambiente, chiavi SSH e sessioni connesse che ogni processo locale puo leggere, perche e esattamente cio che una sandbox protegge. Le basi di API contano anche, poiche piloti questi servizi tramite i loro SDK.

Il problema

I workflow agentici generano codice poi devono eseguirlo, per vedere se funziona, trasformare dati o soddisfare una richiesta. La tentazione e lasciarlo semplicemente girare - e per codice che hai scritto ed esaminato, va bene. Ma l'output d'agente non e sempre corretto, e se un input e venuto da un utente o dal web aperto, non e sempre amichevole. Una sola comando rm, un ciclo infinito che mette la tua CPU in ginocchio, uno script che legge process.env e telefona a casa: non sono casi esotici, sono i modi di fallimento standard quando si esegue codice non fidato con pieno accesso al tuo vero sistema.

Cos'e davvero una sandbox

Una sandbox e un ambiente di esecuzione isolato e usa e getta - in pratica una macchina virtuale leggera o un container indurito - che non ha nessun accesso al tuo vero filesystem, ai tuoi segreti o alla tua rete, salvo cio che autorizzi esplicitamente. Il codice vi gira con il suo filesystem, i suoi limiti di memoria e di CPU e un budget di tempo duro. Quando il run e finito, demolisci la sandbox e niente persiste. Il modello mentale e una camera bianca: il codice riceve esattamente gli input che gli dai, produce esattamente gli output che raccogli, e non puo raggiungere niente al di fuori della camera.

• Isolamento: il codice non puo vedere il tuo filesystem host, le tue variabili d'ambiente ne altri processi.
• Usa e getta: ogni run e un ambiente fresco; una sandbox compromessa o rotta e semplicemente distrutta.
• Limiti di risorse: CPU, memoria e tempo di orologio sono limitati, perche un ciclo impazzito non possa mettere la tua macchina in ginocchio.
• I/O controllato: decidi tu quali file entrano e cosa esce; l'accesso rete puo essere ristretto o rifiutato.

E2B, Daytona e amici

Non costruisci le sandbox da solo - chiami un servizio che ne monta una tramite un SDK in meno di un secondo. E2B e specificamente costruito perche gli agenti di IA eseguano codice: crei una sandbox, vi esegui codice o comandi shell, leggi l'output e la termini, tutto da qualche riga nella tua app. Daytona offre ambienti di development rapidi ed effimeri nello stesso spirito, utili quando un agente ha bisogno di un workspace piu completo di un'esecuzione unica. Entrambi astraggono la plumbing di VM e di container, perche il tuo agente ottenga un posto sicuro dove eseguire codice a richiesta. Il pattern qui sotto e a cosa somiglia quasi ogni integrazione.

import { Sandbox } from '@e2b/code-interpreter'

// Montare una sandbox fresca e isolata solo per questo run
const sandbox = await Sandbox.create()

try {
  // Eseguire codice generato dall'agente dove non puo nuocerti
  const execution = await sandbox.runCode(agentGeneratedPython)
  console.log(execution.logs.stdout)
  console.log(execution.error) // rinchiuso : un errore qui non e un tuo problema
} finally {
  // Demolire sempre - niente persiste
  await sandbox.kill()
}

I dettagli prodotto e i nomi di SDK cambiano in fretta in questo ambito, quindi tratta lo snippet come la forma del pattern e conferma i nomi di metodo attuali contro la documentazione ufficiale E2B e Daytona prima di costruire. Il concetto - creare, eseguire, raccogliere, distruggere - e stabile, anche se le API si muovono.

Quando hai davvero bisogno di una sandbox

Non ogni run di codice ha bisogno di isolamento, e il sur-sandboxing aggiunge latenza e costo. La regola e semplice: sandboxa ogni volta che il codice o i suoi input non sono pienamente fidati, e fai girare localmente quando lo sono. Tre situazioni superano sempre questa linea.

• Codice sottomesso dall'utente: tutto cio che un prodotto lascia gli utenti scrivere ed eseguire (una feature "esegui questo snippet", un campo di trasformazione di dati, un motore di formule) deve essere sandboxato. Esegui codice estraneo sulla tua infrastruttura.
• Output d'agente non fidato: se un agente genera codice a partire da un input non fidato (una pagina scrapata, una richiesta utente, un documento di terzi) e lo esegui senza leggere ogni riga, rinchiudilo. L'agente e sicuro solo quanto il peggiore input che ha visto.
• Esperimenti paralleli: quando vuoi far girare molte varianti in una volta - testare uno script generato contro dieci set di dati, fuzzare un'idea, lasciare piu agenti tentare soluzioni - le sandbox ti danno ambienti puliti, isolati e paralleli che non possono disturbarsi a vicenda ne disturbare il tuo host.
• Quando il locale va bene: codice che hai scritto o pienamente esaminato, eseguito contro input fidati, su una macchina di cui controlli i segreti. Non pagare la tassa sandbox per questo.

Errori frequenti

I pericolosi: eseguire codice generato da agente localmente "solo questa volta" e far trapelare una chiave API dal tuo ambiente; costruire una feature di prodotto che esegue l'input utente senza isolamento, il che e una vulnerabilita di esecuzione di codice remoto da manuale; dimenticare di porre limiti di CPU, memoria e tempo, cosicche un run impazzito ti nuoce comunque; e lasciare le sandbox in vita invece di demolirle, il che spreca denaro e annulla l'usa e getta. L'errore inverso esiste anche: sandboxare codice banale e fidato e rallentarti senza guadagno di sicurezza.

ROI business

Il sandboxing e la differenza tra una feature agentica che puoi mettere in sicurezza davanti agli utenti e una responsabilita che non puoi consegnare. Un solo incidente rinchiuso - un input ostile che avrebbe cancellato un server e che ora distrugge solo una sandbox usa e getta - ripaga tutta la pratica. Per i prodotti che eseguono codice utente o agente, le sandbox non sono una rifinitura opzionale; sono il controllo che ti permette di offrire la feature del tutto. E per la sperimentazione interna, sandbox parallele economiche lasciano una piccola squadra tentare dieci idee nel tempo che ci vorrebbe per farne girare una accuratamente.

Checklist

Sei pronto ad andare avanti quando ognuno di questi punti e acquisito, perche la prossima lezione ti fa costruire strumenti che possono eseguire codice generato.

• Spiegare in una frase perche eseguire codice non fidato localmente e rischioso.
• Definire le quattro proprieta di una sandbox (isolamento, usa e getta, limiti, I/O controllato).
• Descrivere il pattern creare-eseguire-raccogliere-distruggere con un servizio come E2B.
• Nominare le tre situazioni che esigono sempre una sandbox, e una che non la esige.

Risorse

Tieni nei preferiti la documentazione E2B e Daytona, perche i loro SDK evolvono e i nomi di metodo attuali contano quando costruisci. Il materiale di sicurezza del Corso 3 sui segreti e le variabili d'ambiente e qui il fondamento - una sandbox aiuta solo se tieni anche i veri segreti fuori dal codice che le dai. Nel dubbio sul sandboxing, pendi verso Si per tutto cio che tocca un input utente o di terzi.

La tua missione

Iscriviti a E2B (ha una quota gratuita), poi scrivi un piccolissimo script che monta una sandbox, vi esegue qualche riga di Python generato, mostra l'output e la demolisce. Fai deliberatamente girare una riga che sarebbe distruttiva sulla tua vera macchina (per esempio scrivere un file spazzatura) e conferma che resta rinchiusa. Questa prova pratica e cio che trasforma il sandboxing da un'idea astratta in un'abitudine.

Prossima lezione

Coperta l'esecuzione sicura, sei pronto a costruire veri strumenti sopra le API di modelli. La prossima lezione mostra come, attraverso due studi di caso da fondatore: uno strumento di attribuzione di fatture e un catalogatore di carte da collezione svizzere, che trasformano una foto in un record di database.