Tre ricercatori hanno passato mesi a non attaccare la sandbox

Eilon Cohen, Dan Lisichkin e Ariel Fogel di Pillar Security si sono posti una domanda molto stretta sulle sandbox che accompagnano gli agenti di codice con IA. Non se le mura reggono, ma se le mura stanno nel punto giusto. Il 20 luglio 2026 hanno iniziato a pubblicare la risposta come una serie che chiamano Week of Sandbox Escapes, un contributo al giorno, su Cursor, la CLI di OpenAI Codex, la CLI di Google Gemini e Google Antigravity.

In ogni caso l'agente si è comportato bene. È rimasto dentro lo spazio di lavoro che gli era stato dato e non ha violato alcuna regola imposta dalla sandbox. Ha scritto un file. Un processo fuori dalla sandbox ha poi letto quel file, gli ha creduto ed ha eseguito quanto vi era scritto. La fuga è avvenuta senza che l'agente toccasse mai il confine.

Pillar riassume il rilievo in una riga: il raggio d'azione di un agente non è il processo dell'agente, è tutto ciò che l'agente può scrivere e a cui l'host poi si affida. Quella frase è la notizia, ed è il motivo per cui correggere i singoli difetti non chiude la questione.

Un socket spiega tre dei quattro prodotti

Il rilievo più chiaro è anche il meno esotico. Codex CLI, Cursor e Gemini CLI potevano raggiungere il socket Docker locale dall'interno delle proprie sandbox. Un demone privilegiato sull'host avvia volentieri un container per chiunque riesca a parlargli, e quel container gira interamente fuori dalla sandbox. Un unico avviso, GHSA-v4xv-rqh3-w9mc, copre tre dei quattro prodotti esaminati. È risolto.

Codex aveva un secondo problema di natura diversa. La sua lista di comandi consentiti si fidava dei comandi in base al nome. Permetteva git show come operazione di sola lettura senza modellare che cosa possano davvero fare gli argomenti pericolosi passati a git show. È corretto nella versione 0.95.0, e la segnalazione ha ottenuto un premio per severità alta.

Leggendo i due insieme, lo schema si vede. Sono entrambe liste di permessi. Entrambe sono state scritte contro ciò che un operatore riesce a vedere, un percorso di socket e un nome di comando, e non contro ciò che quelle cose sanno fare una volta raggiunte.

Le fughe sono passate da file di cui il suo editor già si fida

Cursor ne ha prodotti tre. Un agente poteva riscrivere l'interprete dentro un ambiente virtuale Python e attendere che la stessa estensione Python dell'editor, che gira senza sandbox, lo eseguisse. Poteva creare una directory Git con un nome non standard perché le regole di sandbox basate sui percorsi non corrispondessero, e lasciare che fsmonitor la raccogliesse. E poteva depositare una configurazione di hook nello spazio di lavoro che lo strumento eseguiva senza sandbox. Quest'ultima porta il CVE-2026-48124 e l'avviso GHSA-pc9j-3qc2-95wv, e tutte e tre sono corrette in Cursor 3.0.0.

I due rilievi di Google vengono dalla stessa famiglia. Il profilo Seatbelt di macOS dietro Antigravity era scritto come denylist, che consente tutto ciò che non è esplicitamente nominato, e una configurazione di task .vscode poteva aggirare le protezioni del Secure Mode. Google ha detto ai ricercatori che il rapporto era di qualità eccezionale, poi ha classificato i rilievi come difficili da sfruttare perché richiedono ingegneria sociale, e li ha declassati su questa base.

La classificazione regge nella propria logica ed è irrilevante per chi usa questi strumenti. Per un agente, ingegneria sociale significa una frase in un README, un commento su una issue o un paragrafo nella documentazione di una dipendenza. Leggere testo non attendibile è la normale giornata di lavoro dell'agente.

Il confine che ha comprato non è il confine che possiede

Ognuno di questi prodotti presenta la sandbox come il controllo che rende accettabile la programmazione autonoma. È la risposta che riceve una revisione di sicurezza ed è il motivo per cui le approvazioni sono state concesse. La ricerca mostra che la sandbox governa una cosa sola, il processo dell'agente. Non è mai stata un'affermazione sullo spazio di lavoro.

Lo spazio di lavoro è la superficie vera, perché è letto da una lunga lista di processi progettati anni prima che gli agenti esistessero e che danno per scontato che a scrivere sia stato un essere umano. L'estensione Python. Il demone Git. Il socket Docker. L'hook di pre-commit. L'installatore di dipendenze. Il runner di CI che clona il ramo. Nessuno è stato costruito per trattare il contenuto di un repository come input ostile, e ognuno di essi ora fa esattamente questo.

Quindi l'oggetto della governance è sbagliato. I titolari hanno approvato agenti. Ciò che ha bisogno di una policy è lo spazio di lavoro, e la regola è breve: un repository in cui un agente IA può scrivere è input non attendibile per ogni processo a valle, allo stesso titolo di un file caricato da uno sconosciuto.

Che cosa cambiare questa settimana

Cominci dal socket, perché un solo avviso copriva tre dei quattro prodotti. Nessun agente di codice ha bisogno di accedere a un socket Docker, e toglierlo è una modifica di configurazione, non un progetto. Poi sposti le versioni. Cursor 3.0.0 e Codex CLI 0.95.0 sono le linee corrette, e gli strumenti di sviluppo si aggiornano per utente e non per flotta, quindi una patch rilasciata dal fornitore non equivale a una patch in mano ai suoi ingegneri.

Il cambiamento duraturo riguarda dove girano gli agenti. Un ramo toccato da un agente dovrebbe arrivare alla CI come non attendibile, il che in pratica significa che la pipeline non esegue hook, task o interpreti provenienti da quel ramo finché una persona non ha approvato il diff. È una decisione sulla pipeline e non sullo strumento, e sopravvive alla prossima divulgazione.

Con NIS2 un incidente che parte dall'editor di uno sviluppatore e finisce nella sua pipeline di produzione è notificabile con lo stesso orologio di qualunque altro. Il dovere non distingue fra un attaccante che ha ingannato un ingegnere con il phishing e un agente che ha letto un README avvelenato, perciò il controllo deve stare dove la pipeline può imporlo.

Da leggere ora: La patch nginx è uscita, l'exploit arriva ad agosto  |  ServiceNow ha corretto prima il proprio cloud, voi 103 giorni più tardi