Il tuo agente non è mai evaso dalla sandbox. Non ne aveva bisogno.

Che cos'è un'evasione di sandbox in un agente di codice?

Quasi mai è un'evasione. Nei casi divulgati nel 2026 l'agente non ha sfondato il proprio container, non ha battuto un hypervisor e non ha sfruttato un bug del kernel. Ha usato la sua ordinaria e prevista capacità di scrivere file nel progetto su cui stava lavorando, e uno di quei file era l'input di un programma che gira con tutti i privilegi dell'utente.

Questo è l'insieme divulgato. Vale la pena leggerlo come elenco, perché lo schema diventa evidente solo nell'aggregato.

Leggi la terza colonna dall'alto in basso. Quattro delle sette sono una scrittura, non una fuga. L'agente ha prodotto un file, un processo fidato lo ha consumato, e quel processo non era nella scatola.

“

Se un agente può scrivere gli input futuri dei sistemi, non è mai stato dentro una sandbox.

La CSA lo chiama Trust Handoff Flaw e lo definisce con precisione: l'agente «resta nella scatola e rispetta ogni regola», ma scrive un file, una configurazione di hook, un interprete di ambiente virtuale, una voce di config Git, una definizione di task, «che qualche altro strumento non isolato consuma dopo la fine del turno dell'agente».

Quella definizione lavora più di quanto sembri. Sposta il confine di sicurezza, da un posto che puoi configurare a una relazione che con ogni probabilità non hai mai inventariato: l'insieme dei programmi sulla macchina dello sviluppatore che leggono file locali al progetto e ci agiscono sopra senza chiedere nulla.

Perché le sandbox cedono sempre allo stesso modo?

Perché nella progettazione delle sandbox ricompaiono quattro assunzioni, e il comportamento di un agente le invalida tutte e quattro. La nota della CSA le nomina, e conviene enunciarle come errori di progettazione anziché come bug, perché ognuna tornerà nel prossimo prodotto che rilascerà un agente.

Niente di tutto questo è esotico. Sono le modalità di guasto classiche della sicurezza perimetrale, riscoperte in un posto nuovo, da squadre che rilasciano in fretta in una categoria che due anni fa non esisteva.

GitSpawn: la stessa falla, nel file che ogni repository possiede

Se lo schema suona ancora astratto, la divulgazione di Manifold Security a inizio settembre 2026 lo rende concreto, ed è l'illustrazione più pulita dell'intero argomento.

core.fsmonitor è un'impostazione di performance di Git. Il suo valore è un comando, che Git esegue per capire quali file sono cambiati. Git lo legge dal .git/config del repository stesso. Gli agenti di codice chiamano Git all'avvio per sapere il branch e i file modificati, quindi il comando parte subito, con i privilegi dell'utente, prima ancora che esista una finestra di approvazione da mostrare.

Clonare un repository ormai basta. Nessuna dipendenza malevola, nessuno script post-install, nessun codice da rivedere, e niente che uno scanner che legge i file sorgente segnalerebbe. Il payload è in un file di configurazione che la maggior parte degli sviluppatori non ha mai aperto.

Due dettagli meritano enfasi. Primo, le correzioni sono per percorso e non per classe: Manifold ha segnalato una seconda via verso Claude Code ancora viva in 2.1.252 dopo che la prima era stata patchata. Secondo, diversi agenti erano ancora confermati vulnerabili al momento della divulgazione. Se il tuo controllo è «abbiamo aggiornato», il tuo controllo ha un numero di versione e una race condition dentro.

La mitigazione raccomandata da Manifold vale la pena oggi, sta in un comando, ed è una buona illustrazione di quanto sia stretta una correzione per singolo problema:

# Verificare un repository che stai per aprire con un agente
git config --get core.fsmonitor

# Disattivare il meccanismo globalmente
git config --global core.fsmonitor false

# Oppure neutralizzarlo sulle singole chiamate in background
git -c core.fsmonitor=false status

Questo chiude core.fsmonitor. Non fa nulla per core.hooksPath, per .vscode/tasks.json, per un interprete venv, per un hook .claude, né per la prossima chiave di configurazione di cui qualcuno noterà che è eseguibile. Una proprietà di progettazione non si patcha.

Cosa copre davvero una sandbox, e cosa no

Per rendere giustizia alla sandbox, che merita davvero di essere adottata: fa un lavoro reale, e quel lavoro non è poco. È solo più stretto del discorso che le sta intorno.

Le ultime quattro righe sono quelle che contano, e condividono una proprietà: l'agente non fa nulla di proibito. I controlli perimetrali rilevano violazioni di confine. Nessuna di queste lo è.

Resta un guasto che appartiene qui, perché è il più umano di tutti. A marzo 2026 è stata aperta una issue contro Claude Code che segnalava come l'impostazione sandbox di ~/.claude/settings.json non venisse applicata quando l'agente girava dentro l'estensione VS Code o Cursor: l'estensione lanciava il binario nativo senza l'opzione --sandbox, per cui il profilo Seatbelt di macOS non veniva mai applicato, nemmeno con sandbox.enabled: true. Chi ha segnalato lo ha verificato scrivendo un file in ~/Desktop da una sessione di Cursor. La issue è stata chiusa come duplicata, e la soluzione temporanea proposta era eseguire la CLI direttamente o usare hook PreToolUse come guardia sostitutiva.

Qualunque sia il suo stato oggi, la classe di problema è permanente: una sandbox è una configurazione, le configurazioni hanno superfici in cui silenziosamente non si applicano, e un controllo che credi acceso è peggio di uno che sai spento.

E allora, in concreto, cosa si fa?

Tieni la sandbox. Smetti di trattarla come il controllo. Poi chiudi il passaggio di consegne, che è dove sta l'esposizione vera.

È il passo che nessuno fa, ed è quello che la CSA reclama. Elenca i programmi su una macchina di sviluppo che consumano file dalla directory di lavoro e ci agiscono sopra: l'editor e le sue estensioni, il language server, il client Git, il profilo della shell, il runtime dei container, il task runner, il watcher dei test. Quell'elenco è la tua vera superficie d'attacco. La sandbox non ci compare.

Una denylist richiede di aver enumerato il sistema operativo. Una allowlist richiede di aver enumerato il tuo flusso di lavoro, che è un problema che puoi davvero finire. E valida ciò che un comando fa, non come si chiama: git show era su una allowlist per via del nome.

Nessuna sessione di agente dovrebbe poter raggiungere il socket Docker, la config di Kubernetes o qualsiasi endpoint locale più privilegiato di lei. Questo è gratis e ha eliminato un'intera classe in tre prodotti.

Una modifica a .git/config, .vscode/, .claude/, .cursor/, a un interprete virtualenv o a un workflow di CI non è una modifica di codice. È una modifica a ciò che verrà eseguito dopo. Merita un percorso di approvazione diverso da quello di un componente React, e oggi di solito riceve lo stesso.

Le variabili d'ambiente viaggiano con il processo. Una sandbox perfettamente isolata che eredita AWS_SECRET_ACCESS_KEY ha isolato il filesystem e pubblicato la credenziale.

Ogni punto qui sopra è una misura di hardening che un percorso determinato prima o poi aggirerà, perché sono tutte statiche. Ciò che chiude la classe è valutare l'azione nel momento in cui avviene, con la possibilità di rifiutarla.

Quest'ultimo passo è dove sta il nostro prodotto, quindi leggi i tre paragrafi seguenti sapendolo. Se pensiamo che discenda dalle prove e non dalla nostra roadmap è perché la CSA è arrivata alla stessa conclusione strutturale senza vendere nulla, e perché la soluzione temporanea suggerita nell'issue tracker di Anthropic era un hook PreToolUse.

Un hook si colloca dove la sandbox non può. Valuta una chiamata a uno strumento prima che venga eseguita, il che significa che vede la scrittura stessa: questa sessione sta per modificare .git/config, o aggiungere un core.hooksPath, o editare un file di workflow che si attiva sui fork con permessi di scrittura, o invocare uno strumento la cui descrizione è cambiata da ieri. Sono eventi discreti e ispezionabili, con un soggetto e un oggetto. Una sandbox vede un processo che scrive byte in una directory permessa e non ha alcuna base su cui obiettare, perché non sta succedendo niente di proibito.

È una domanda diversa, non un muro più spesso. La sandbox chiede «questo processo può stare qui?». La barriera chiede «questa azione precisa deve avvenire adesso?». Il Trust Handoff Flaw esiste proprio perché la prima domanda ha una risposta soddisfacente mentre la seconda non viene mai posta.

E si degrada onestamente. Le regole nel contesto dell'agente migliorano ciò che propone, il che è un miglioramento reale e probabilistico. I findings nel ciclo fanno sì che una modifica proposta venga ragionata contro lo stato reale del repository. Solo l'hook è deterministico, e preferiamo dire quale dei tre è un controllo piuttosto che lasciar intendere che lo siano tutti e tre. La versione ampia di questo argomento è in la sicurezza degli agenti di codice IA.

Domande frequenti

La sandbox basta a proteggere un agente di codice IA?

No, e le divulgazioni del 2026 mostrano perché con una chiarezza insolita. Delle sette evasioni riprodotte su Cursor, Codex CLI, Gemini CLI e Antigravity, la maggior parte non è consistita nell'uscire dalla sandbox. L'agente ha scritto un file dentro il proprio workspace permesso, e un processo fidato fuori dalla sandbox lo ha eseguito più tardi. La sandbox limita il danno di un processo che si comporta male dentro il confine, e vale la pena averla. Non può nulla contro un agente che si comporta perfettamente e passa il proprio payload a qualcosa che nella scatola non è mai stato.

Che cos'è il Trust Handoff Flaw?

È il nome che la Cloud Security Alliance ha dato, in una nota di ricerca del 22 luglio 2026, allo schema dietro le evasioni di sandbox degli agenti di codice del 2026. L'agente resta dentro il proprio confine e rispetta ogni regola, ma scrive un file, una configurazione di hook, un interprete di ambiente virtuale, una voce di config Git o una definizione di task, che qualche altro strumento non isolato consuma dopo la fine del suo turno. La nota lo riassume così: se un agente può scrivere gli input futuri dei sistemi, non è mai stato dentro una sandbox.

Quali agenti di codice hanno avuto evasioni di sandbox nel 2026?

La ricerca di Pillar Security ha riprodotto evasioni su Cursor, sul Codex CLI di OpenAI, sul Gemini CLI di Google e su Antigravity di Google, sette in totale, di cui almeno quattro hanno ricevuto una patch dal produttore. A parte, la divulgazione GitSpawn di Manifold Security a settembre 2026 ha coperto goose (CVE-2026-72718), Codex (CVE-2026-19592), Claude Code (CVE-2026-55607) e Hermes Agent (CVE-2026-71963), con Qwen Code e Grok Build anch'essi confermati vulnerabili in quel momento.

Un repository Git può eseguire codice solo per il fatto di essere aperto?

Sì, ed è la scoperta di GitSpawn. core.fsmonitor è un'impostazione di performance di Git il cui valore è un comando che Git esegue per determinare quali file sono cambiati, e Git lo legge dal .git/config del repository stesso. Gli agenti di codice chiamano Git all'avvio, quindi il comando gira con i privilegi dell'utente prima che compaia qualsiasi finestra di approvazione. Verificarlo è un comando, git config --get core.fsmonitor, e disattivarlo globalmente è git config --global core.fsmonitor false.

MicroVM, gVisor o container per il mio agente di codice?

Scegli in base ai tuoi vincoli di performance e di GPU, perché per questa classe di minaccia la scelta conta poco. Firecracker dà l'isolamento più forte, gVisor è una via di mezzo ragionevole con un kernel in user space, e i container sono il pavimento. Nessuno dei tre cambia il fatto che un'estensione Python non isolata esegua un interprete che l'agente ha modificato. Spendi lo sforzo decisionale su cosa l'agente può scrivere e su quali programmi locali si fidano di lui, e tratta la primitiva di isolamento come un'impostazione di raggio di danno.

Attivare l'impostazione sandbox del mio agente lo isola davvero?

Verificalo invece di darlo per scontato. A marzo 2026 una issue contro Claude Code segnalava che sandbox.enabled: true in ~/.claude/settings.json non aveva effetto quando l'agente girava dentro l'estensione VS Code o Cursor, perché l'estensione lanciava il binario nativo senza l'opzione --sandbox e il profilo Seatbelt di macOS non veniva mai applicato. Chi ha segnalato lo ha confermato scrivendo in ~/Desktop da una sessione di Cursor. Testa la tua configurazione tentando una scrittura fuori dal workspace e osservando se viene rifiutata.

Che cos'è la sicurezza agent-time e in cosa differisce dalla sandbox?

La sandbox pone una domanda perimetrale: questo processo può stare in questo posto? La sicurezza agent-time pone una domanda sull'azione: questa operazione precisa deve avvenire adesso?, e sa rifiutare. La differenza è decisiva di fronte al Trust Handoff Flaw, perché la scrittura che causa l'esecuzione successiva non è una violazione perimetrale e a uno strato di isolamento appare del tutto legittima. Una barriera che valuta la chiamata allo strumento vede che la destinazione è .git/config e la rifiuta, cosa che nessuna forza di isolamento farà.

Vuol dire che le sandbox per agenti sono inutili?

Per niente, e abbandonarle sarebbe la lezione sbagliata. Una sandbox limita in modo affidabile il danno di una dipendenza malevola, di un comando distruttivo o di un ciclo impazzito, e sono casi frequenti. La correzione è smettere di descriverla come contenimento di fronte a un agente avversariale. È un riduttore di raggio di danno, che sta accanto al controllo dell'uscita di rete, all'igiene delle credenziali e a un punto di applicazione sulle azioni stesse.