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, pubblicato da Pillar al ritmo di un post al giorno. 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, citando i ricercatori di Pillar, 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.

È sulla consegna che bisogna essere precisi, e Manifold lo è: «clonare un URL ostile non fa nulla, e nemmeno un fetch o un pull». Un normale git clone non trasporta il .git/config del repository di origine. Il repository deve arrivare sotto forma di file, con la sua cartella .git già dentro: un archivio .zip condiviso, una cartella sincronizzata, un disco condiviso, una chiavetta USB. A quel punto basta aprire quella cartella con un agente. 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.

Tre dettagli meritano enfasi. Primo, le correzioni sono per percorso e non per classe: Manifold ha segnalato una seconda via verso Claude Code, attraverso un'altra impostazione di Git, ancora viva in 2.1.252 dopo che la prima era stata patchata. Secondo, diversi agenti erano ancora confermati vulnerabili al momento della divulgazione: Manifold conta otto falle su sette agenti, quattro delle quali ancora senza patch alla pubblicazione. Terzo, con gli identificativi serve attenzione. Manifold non cita alcun CVE per la sua falla di Claude Code, e l'identificativo di Claude Code con cui è facile confonderla, CVE-2026-55607, descrive un'altra falla: un'evasione dalla sandbox per confusione di percorsi nei worktree di Git, presente dalla 2.1.38 e corretta nella 2.1.163, ben prima della 2.1.193 su cui Manifold ha confermato la propria. Se il tuo controllo è «abbiamo aggiornato», il tuo controllo ha un numero di versione e una race condition dentro.

Ciò che protegge davvero è più stretto di quanto sembri, quindi conviene essere esatti. Manifold dà due consigli. Se ricevi un repository sotto forma di file, ispeziona .git/config prima di aprire la cartella con un agente, perché «qualsiasi impostazione che nomina un programma può eseguirlo». Se pubblichi un agente, o un semplice script che chiama Git in background, ripulisci la configurazione di Git su quelle chiamate, per esempio con git -c core.fsmonitor=false status. Il terzo passo è nostro: aggiorna l'agente, la tabella qui sopra indica le versioni che contengono la correzione.

# Un repository ricevuto sotto forma di file: leggi la sua config prima che un agente lo apra
cat .git/config

# In uno strumento o uno script che chiama Git in background, sovrascrivi la chiave sulla chiamata stessa
git -c core.fsmonitor=false status

L'impostazione globale che spesso viene consigliata al suo posto, git config --global core.fsmonitor false, non ti protegge. La documentazione di Git elenca i file di configurazione in ordine, sistema, poi globale, poi il .git/config del repository, e precisa che vengono letti «nell'ordine indicato sopra, e l'ultimo valore trovato ha la precedenza su quelli letti prima». Il valore del repository viene letto dopo il tuo valore globale, quindi un .git/config trappola vince. L'opzione -c è l'eccezione: secondo il manuale di Git, il suo valore «prevale sui valori dei file di configurazione».

Anche fatto bene, questo sistema core.fsmonitor e nient'altro. 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 quattro giorni dopo, e l'unica soluzione temporanea messa a verbale è quella di chi l'ha segnalata: 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.

1. 01

   Inventaria ciò che legge i file di progetto senza chiedere

   È 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.

2. 02

   Preferisci le allowlist alle denylist, e modella gli argomenti

   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.

3. 03

   Taglia i daemon privilegiati

   Nessuna sessione di agente dovrebbe poter raggiungere il socket Docker, la config di Kubernetes o qualsiasi endpoint locale più privilegiato di lei. Questo è gratis. Cursor lo ha chiuso in una release e Gemini CLI ha seguito nella 0.58.0; OpenAI non ha pubblicato alcuna correzione per Codex.

4. 04

   Tratta le scritture di configurazione come operazioni privilegiate

   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.

5. 05

   Ripulisci l'ambiente prima del filesystem

   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.

6. 06

   Metti la decisione sulla scrittura, non sul perimetro

   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 che un utente ha lasciato 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 AI.

Domande frequenti

La sandbox basta a proteggere un agente di codice AI?

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 riprende il riassunto in una riga di Pillar: 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, secondo il conteggio della CSA. A parte, la divulgazione GitSpawn di Manifold Security del 1° settembre 2026 ha coperto goose (CVE-2026-72718, corretto in 1.44.0), Claude Code (nessun CVE citato: il percorso core.fsmonitor è stato corretto in 2.1.196, un secondo percorso era ancora aperto in 2.1.252), Hermes Agent (CVE-2026-71963), Qwen Code e Grok Build, questi ultimi tre ancora senza patch al momento della divulgazione. Manifold ha trovato vulnerabili anche Codex e Cursor, entrambi nel frattempo patchati; la scheda che la stessa OpenAI ha pubblicato per la falla di core.fsmonitor in Codex CLI è CVE-2026-19592, corretta in 0.131.0.

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

Sì, se ti è arrivato sotto forma di file e non tramite git clone. 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. È la scoperta di GitSpawn, e Manifold è preciso sulla consegna: un clone normale non trasporta il .git/config dell'origine, quindi il repository deve arrivare con la sua cartella .git già dentro, come archivio .zip condiviso, cartella sincronizzata, disco condiviso o chiavetta USB. Leggi .git/config prima di aprire una cartella del genere con un agente. git config --global core.fsmonitor false non serve, perché Git legge il file del repository dopo quello globale e vince l'ultimo valore; solo git -c core.fsmonitor=false, sul comando stesso, passa davanti.

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.