Siamo abituati a leggere dell'AI nella sicurezza informatica da un solo punto di vista: un attaccante che usa agenti per muoversi più in fretta. Il secondo punto di vista conta di più per la vostra organizzazione e riceve molta meno attenzione. L'agente che fate girare sulla vostra macchina di sviluppo è esso stesso una nuova superficie di attacco. Nell'arco di due mesi, tre gruppi di ricerca indipendenti hanno pubblicato risultati che puntano tutti nella stessa direzione.

Ciò che questi casi hanno in comune non è un difetto del modello né una risposta sbagliata. L'agente non è mai uscito dalla sua sandbox e non ha mai violato una regola. È successo che l'agente ha letto o scritto un file dentro il progetto, e poi uno strumento fidato che gira fuori dalla sandbox ha eseguito il contenuto di quel file. La sandbox ha retto. La compromissione l'ha aggirata.

Il meccanismo: un'impostazione di prestazioni di Git vecchia di anni

L'esempio più chiaro è stato pubblicato da Manifold Security il 2 settembre 2026 con il nome GitSpawn. Si basa su un'impostazione Git a livello di progetto chiamata core.fsmonitor, un'opzione di prestazioni legittima e documentata il cui valore è un comando che Git esegue per individuare rapidamente i file modificati invece di scansionare l'intera directory.

Ora mettiamo insieme le due metà:

  • Un agente AI di programmazione, quando inizia a lavorare su un progetto, esegue automaticamente comandi Git come git status e git diff per capire lo stato del repository. È un comportamento normale e necessario.
  • Se il repository contiene un valore core.fsmonitor malevolo, la semplice esecuzione di quei comandi esegue il comando dell'attaccante.

Il risultato è che aprire un repository di codice smette di essere un evento di lettura e diventa un evento di esecuzione. Nessun clic, nessuna approvazione, nessuna richiesta mostrata allo sviluppatore. Secondo il rapporto, otto agenti da riga di comando erano esposti, e per diversi sono seguite delle patch: goose nella 1.44.0, Claude Code nella 2.1.196 per il percorso core.fsmonitor, Codex CLI nella 0.131.0, oltre a Cursor. Il rapporto ha segnalato quattro percorsi ancora senza patch al momento della pubblicazione. La classe è stata tracciata con identificativi tra cui CVE-2026-72718, CVE-2026-19592 e CVE-2026-55607.

Non un singolo incidente ma un'intera classe

Sei settimane prima di GitSpawn, i ricercatori di Pillar Security hanno pubblicato il 20 luglio 2026 una serie che hanno chiamato una settimana di evasioni dalla sandbox, documentando sette vulnerabilità in quattro agenti di programmazione di tre fornitori: Cursor, Codex, Gemini CLI e Antigravity. La loro descrizione del meccanismo merita di essere letta due volte. L'agente resta dentro la scatola e segue ogni regola. Si limita a scrivere un file che uno strumento fidato fuori dalla scatola in seguito esegue, carica o analizza.

  • In Cursor, un file di configurazione degli hook controllato dal workspace consentiva l'esecuzione fuori dalla sandbox, tracciato come CVE-2026-48124 e corretto nella versione 3.0.0.
  • In Codex CLI, la lista dei comandi consentiti si fidava di git show solo in base al nome, anche se i parametri passati possono renderlo più che di sola lettura. Corretto nella versione 0.95.0.
  • Un problema con il socket di Docker ha colpito Codex, Cursor e Gemini CLI contemporaneamente.
  • In Antigravity, un aggiramento della denylist di Seatbelt su macOS e un problema nella configurazione dei task dell'editor, entrambi classificati da Google come difficili da sfruttare.

Poi, il 10 settembre 2026, Upstarts Media ha riportato una terza segnalazione, di una startup chiamata Accomplish, riguardante sandbox che perdono in Claude Code, Codex e Cursor. Il dato interessante lì non è la vulnerabilità ma il tempo di correzione: il problema di Cursor è stato risolto in circa una settimana, due problemi di OpenAI ad agosto, mentre il problema di Anthropic ha richiesto circa cinquanta giorni attraverso decine di release. Tre gruppi di ricerca, tre rapporti, due mesi, un solo schema.

Perché vi riguarda anche se non scrivete mai codice

Perché il rischio non ricade sull'agente. Ricade sulla macchina che lo esegue e sulla rete in cui quella macchina si trova. Una workstation di sviluppo è uno dei dispositivi con più privilegi in qualsiasi azienda: contiene le chiavi di accesso ai server, i token di deployment e spesso una connessione aperta a un database di produzione. Eseguire un solo comando su di essa non è un evento da poco.

Lo scenario non è teorico nel mercato saudita. Confrontate questi casi con la vostra azienda:

  • Un collaboratore esterno o un'agenzia di sviluppo consegna codice che il vostro team poi apre con un agente AI su una macchina all'interno della vostra rete.
  • Un progetto open source che uno sviluppatore scarica per provare una libreria o una correzione rapida.
  • Un file inviato via email o WhatsApp da un fornitore, decompresso e aperto direttamente nell'editor.
  • Un candidato a un posto di lavoro che invia un progetto di esempio aperto da un revisore tecnico.
  • Un vecchio branch o un repository trasferito consegnato durante un'acquisizione o un passaggio di progetto.

In ognuno di questi casi, il presupposto implicito è che aprire i file per leggerli sia un atto sicuro. È proprio questo presupposto che si è rotto.

Cosa fare questa settimana

Cinque passi, e il primo non richiede budget:

  1. Aggiornate oggi gli strumenti degli agenti in tutto il team. Esistono patch per la maggior parte di questi strumenti, e il valore sta nel fatto che tutti siano su una versione corretta, non una sola persona. Cominciate sapendo chi usa cosa e in quale versione, perché quell'inventario di solito manca.
  2. Trattate il codice in arrivo come contenuto non fidato. Il codice di un collaboratore o di una fonte aperta non è un documento da leggere, è qualcosa che viene eseguito. Apritelo la prima volta su una macchina o un container separato dalla rete di lavoro.
  3. Separate la macchina di sviluppo dalle chiavi di produzione. Non tenete token di server in produzione sulla macchina in cui si aprono progetti di provenienza esterna. La perdita resta così confinata a quel dispositivo.
  4. Fate passare il deployment da una pipeline centrale, non da un portatile personale. Quando il deployment passa da un'unica pipeline di build con permessi limitati, compromettere una singola macchina smette di essere una strada verso la produzione.
  5. Aggiungete una clausola ai contratti di sviluppo in outsourcing. Avete diritto di specificare come viene consegnato il codice e da quale repository, e di richiedere al fornitore di mantenere aggiornati i suoi strumenti. È una clausola contrattuale, non un dibattito tecnico.

A livello locale, niente di tutto questo è una buona pratica facoltativa. I Controlli Essenziali di Sicurezza Informatica emanati dall'Autorità Nazionale per la Sicurezza Informatica (NCA) includono domini espliciti per la sicurezza degli endpoint, la sicurezza della gestione delle modifiche e dello sviluppo e la sicurezza delle terze parti, mentre la responsabilità della protezione dei dati personali resta in capo all'organizzazione ai sensi della Legge sulla protezione dei dati personali (PDPL). Se la porta si è aperta tramite una macchina di sviluppo che ha aperto il progetto di un fornitore, questo non riduce la responsabilità.

Il punto di vista di Origami

Leggiamo questi tre rapporti come una correzione a un'idea che si è diffusa rapidamente: che una sandbox basti finché l'agente vi è rinchiuso. Queste vulnerabilità non hanno rotto l'isolamento. Hanno usato un ponte legittimo che porta qualcosa scritto dentro la scatola a uno strumento che gira fuori. Il che significa che la domanda giusta non è se l'agente sia in una sandbox, ma quali strumenti leggono ciò che l'agente produce, e con quali privilegi girano quegli strumenti.

Un'osservazione pratica da ciò che vediamo presso i clienti: l'adozione di strumenti AI nei team di sviluppo è mesi avanti rispetto a qualsiasi policy che la governi. Uno sviluppatore prova uno strumento, gli piace, e diventa parte del flusso di lavoro quotidiano senza decisione, senza revisione e senza inventario. Il problema non è lo strumento. Il problema è che è entrato da una porta che nessuno sorveglia. Quando esaminiamo gli ambienti dei clienti partiamo proprio da qui: quali strumenti girano davvero sulle macchine del team, con quali privilegi, e cosa succede se stanotte un comando viene eseguito su una di esse. Se volete una revisione da questa prospettiva, ci trovate nella pagina dei contatti.

In sintesi

Tre segnalazioni indipendenti in due mesi dicono la stessa cosa: un agente AI di programmazione trasforma l'apertura di un progetto da lettura a esecuzione, e basta che un soggetto esterno inserisca una riga in un file di configurazione. Sono state rilasciate patch per la maggior parte degli strumenti e alcuni percorsi sono rimasti aperti, ma la lezione sopravvive a qualsiasi release. Qualsiasi strumento che fate girare su una macchina con molti privilegi fa parte della vostra superficie di attacco, che le vostre policy lo elenchino o no. Cominciate da una domanda: chi nel vostro team sta usando un agente AI in questo momento, su quale macchina e in quale versione?

Fonti