Kiro sandbox: come si attiva e cosa protegge davvero dei comandi dell'agente

La sandbox locale di Kiro è il perimetro in cui l'agente di Amazon esegue i comandi shell, ed è uscita il 13 ottobre 2026 con Kiro IDE 1.3.0 e Kiro CLI 2.31.0. Con la sandbox si può restringere cosa quel comando e i suoi processi figli riescono a leggere, scrivere e raggiungere in rete. Ne beneficia chiunque lasci lavorare un agente di coding su un repository vero, e la funzione è spenta finché non la accendi.

Cosa limita la sandbox di Kiro, e cosa lascia fuori

La sandbox mette dentro un sandbox del sistema operativo i comandi di terminale che l'agente esegue e tutti i processi che quei comandi avviano. Se attivi l'opzione apposita, ci finiscono anche i server MCP locali che comunicano via stdio. Il changelog della CLI 2.31 la descrive così, e la documentazione della sandbox aggiunge i dettagli che mancano nelle note di rilascio.

Fuori dal perimetro restano tre cose: l'agente stesso, gli strumenti di file integrati e i server MCP remoti. Per i file valgono le regole di permesso fs_read e fs_write, che decidono quali percorsi un comando in sandbox può vedere e scrivere. Le sessioni nel cloud usano un'altra sandbox, separata. Il limite lo dichiara Kiro stesso: la sandbox "riduce quello che un comando può fare, non è una garanzia di isolamento", e per questo conviene continuare a leggere i comandi che l'agente propone.

Come si attiva nell'IDE e nella CLI

Nella CLI basta eseguire /sandbox in una sessione locale V3. Nell'IDE si clicca Command sandbox nella barra di stato, che apre il file di configurazione attivo: quello del progetto se esiste, altrimenti quello globale. Lì si imposta enabled a true, si sceglie la modalità di rete e si salva. Il cambiamento si applica alla sessione in corso. Lo stato mostrato può essere Off, Applying, Active, Error oppure Unavailable.

Il file si chiama sandbox.json e vive in due posti: a livello globale in ~/.kiro/settings/ (nella CLI in $KIRO_HOME) e a livello di progetto in .kiro/settings/ dentro la radice del workspace. Le chiavi sono tre.

La regola di precedenza è la parte che interessa a chi gestisce un team. Quando esiste una policy globale attiva, il file di progetto può solo stringerla: non può spegnere la sandbox, aprire la rete o disattivare l'MCP in sandbox. Un repository clonato da fuori, in pratica, non può allentare le regole che hai deciso tu sulla tua macchina. Se invece il file globale manca o è disattivato, un sandbox.json di progetto con enabled: true accende la sandbox per quel repository.

Le tre modalità di rete

DEFAULT_BLOCKED blocca tutto tranne gli host che una regola consente. COMMON_DEPENDENCIES lascia raggiungibili i servizi comuni di pacchetti, sorgenti, build e container. DEFAULT_ALLOWED apre a qualsiasi host, e la documentazione avverte di non contare sulle regole di divieto in quella modalità.

Per consentire un host si scrivono regole sandbox_network, con nomi esatti o caratteri jolly del tipo *.suffisso. Le regole si valutano in ordine e vince la prima che corrisponde, al contrario di altre capacità in cui il divieto prevale sempre. Quindi gli host specifici vanno scritti prima dei caratteri jolly più larghi. Se un comando fallisce perché la rete è chiusa, la documentazione indica due strade: una regola di consenso oppure il passaggio a COMMON_DEPENDENCIES.

Cosa serve sul sistema, e dove la sandbox non parte

Su macOS non c'è nulla da installare, perché Kiro usa Seatbelt, il sandbox integrato. Su Linux servono bwrap nel PATH e, per alcune modalità, socat, e Kiro non li installa al posto tuo. Su Windows alcune modalità richiedono una configurazione una tantum da amministratore: l'IDE la propone, nella CLI si lancia /sandbox setup, mentre DEFAULT_BLOCKED funziona senza.

C'è un caso da conoscere prima di fidarsi dell'indicatore verde. Se il backend manca, lo stato è Unavailable e i comandi girano senza isolamento del sistema operativo, a meno che la modalità in uso non richieda protezione. Su una macchina Linux senza bwrap puoi quindi credere di essere protetto quando non lo sei. La prima verifica, dopo averla accesa, è guardare lo stato e controllare che sia Active.

Le note di rilascio non dicono nulla su piani e prezzi, e la pagina della documentazione elenca solo le versioni (IDE 1.3 e CLI 2.31, sessioni locali V3). Non risultano condizioni diverse per piano, ma non è scritto che non ce ne siano.

Modalità autonoma: l'autonomia dentro il perimetro

Nella stessa release della CLI arriva /autonomous on, disponibile in una sessione locale V3. Kiro porta a termine un compito senza chiedere approvazione per ogni comando shell. Prima di partire passa all'agente Default e accende la sandbox locale, e questo è il collegamento che conta: l'autonomia viene concessa dentro un perimetro, non al posto del perimetro. Il changelog non dettaglia altro, e la pagina della sandbox rimanda per questa parte alla documentazione dell'autonomia sul web.

Il caso raccontato in L'AI in azienda lavora con i permessi di chi la accende riguardava proprio Kiro: nel dicembre 2025 un agente con i permessi dell'operatore ha cancellato un ambiente di produzione. Una sandbox sui comandi locali non è la risposta a quell'episodio, ma va nella direzione giusta: togliere all'agente per costruzione quello che non gli serve. Sul perché ha senso restringere gli accessi prima di aumentare l'autonomia ho scritto anche in come isolare un agente AI, e per l'equivalente lato Claude Code c'è l'articolo su Claude Code in un container.

La cosa pratica da fare oggi è una sola. Se usi Kiro su un repository con segreti nell'ambiente, crea un sandbox.json globale con "enabled": true e lascia networkAccess a DEFAULT_BLOCKED, poi apri le porte con regole sandbox_network solo per i registri che il progetto usa davvero. È più lavoro che spegnere un avviso, ma è l'unico modo per sapere cosa può raggiungere un comando scritto da un agente.

Lo stesso tema dei limiti dell'agente è arrivato anche in Codex CLI, dove la 0.163.0 ripristina i permessi dei thread ripresi: i dettagli sono in come correggere Codex CLI mentre risponde e cosa cambia nei permessi.