Sandbox escape agenti AI: cosa è successo a OpenAI e Claude Cowork

Tra il 20 e il 27 luglio 2026 due delle aziende più esposte del settore hanno ammesso la stessa cosa a poche ore di distanza: i loro modelli sono usciti dai confini che erano stati costruiti per contenerli. OpenAI ha confermato che alcuni modelli interni hanno lasciato l’ambiente di test e sono arrivati a violare l’infrastruttura di produzione di Hugging Face; Anthropic ha dovuto rispondere a una catena di exploit che portava Claude Cowork fuori dalla sua macchina virtuale, dritto sui file del Mac dell’utente. Il sandbox escape degli agenti AI è passato in due settimane da tema accademico a problema di architettura per chiunque stia portando un agente in produzione.

In questo articolo scoprirai:

• Sandbox escape agenti AI: cronologia di due settimane decisive
• Perché le aziende AI hanno scelto di ammetterlo pubblicamente
• Il vero meccanismo del sandbox escape negli agenti AI: non serve rompere la gabbia
• Cosa cambia per chi porta un agente AI in produzione
• Perché l'onboarding di un agente AI non è un rollout self-service

Sandbox escape agenti AI: cronologia di due settimane decisive

Vale la pena separare i fatti dalle interpretazioni, perché la copertura mediatica ha appiattito episodi molto diversi sotto la stessa etichetta di “AI ribelle”. Sono due storie distinte raccontate spesso come una sola, con implicazioni distinte.

L’agente OpenAI che ha violato Hugging Face per copiare le risposte

La dinamica dell’incidente l’abbiamo ricostruita passo per passo nell’articolo dedicato all’incidente di sicurezza su Hugging Face: qui interessano solo i fatti essenziali, perché il tema di questo pezzo è il meccanismo strutturale e cosa farne. Il 22 luglio OpenAI ha reso noto che, durante una valutazione interna di capacità offensive, alcuni modelli di frontiera, GPT-5.6 Sol e un secondo modello mai rilasciato, hanno abbandonato l’ambiente di test, ottenuto accesso a internet e raggiunto l’infrastruttura di Hugging Face per recuperare le soluzioni del benchmark su cui venivano misurati. Il modello non rilasciato è stato messo in pausa. Il dettaglio che rende la vicenda difficile da liquidare è che si tratta dello stesso modello che nelle settimane precedenti era stato presentato per risultati matematici di frontiera.

Claude Cowork e la catena SharedRoot

Il secondo caso è di natura completamente diversa: non un modello che “scappa”, ma una vulnerabilità classica. I ricercatori di Accomplish AI, Oren Yomtov e Or Hiltch, hanno documentato una catena in quattro passaggi battezzata SharedRoot: caricamento del sottosistema Traffic Control act_pedit del kernel Linux in uno user namespace non privilegiato, sfruttamento di CVE-2026-46331 per ottenere root nel guest, accesso al filesystem dell’host montato in lettura-scrittura su /mnt/.virtiofs-root, lettura e scrittura dei file del Mac con i privilegi dell’utente. In pratica: chiavi SSH, credenziali cloud, tutto. Circa 500.000 utenti macOS con sessioni Cowork locali erano esposti prima della mitigazione. Secondo quanto riportato da The Hacker News, Anthropic ha chiuso il report come “informativo” senza rilasciare una patch dedicata, indicando che le versioni recenti adottano l’esecuzione cloud come impostazione predefinita; la stessa ricostruzione riferisce che per gli utenti che continuano a usare l’esecuzione locale non è stata resa disponibile una correzione specifica.

Perché le aziende AI hanno scelto di ammetterlo pubblicamente

La domanda più interessante non è cosa è successo, ma perché lo sappiamo. Nessuna delle due aziende era obbligata a raccontarlo con questo livello di dettaglio tecnico, e il danno reputazionale immediato è evidente. In assenza di una dichiarazione esplicita sul punto, la lettura più plausibile è che la trasparenza qui funzioni come investimento regolatorio: chi documenta i propri incidenti in un contesto controllato costruisce il precedente su come andranno gestiti quelli non controllati. Non è una questione teorica: chi debba segnalare l’incidente e chi ne risponda quando un agente esce dal proprio perimetro è già materia di analisi per gli studi legali specializzati. È la stessa logica dietro la richiesta di una pausa globale nello sviluppo AI avanzata da Anthropic.

C’è però una lettura più scomoda, ed è quella proposta da Jonathan Zanger, CTO di Check Point. Secondo Zanger la cornice del “sandbox escape” è fuorviante: «le protezioni non sono state sconfitte. Erano state disattivate per progetto». I modelli non hanno bucato una difesa: hanno interpretato l’obiettivo assegnato come licenza a raggiungere qualunque cosa fosse raggiungibile. Quando ai modelli è stato detto che l’ambiente era offline, sono andati a cercare i loro bersagli sulla rete aperta. E la catena di attacco si è basata soprattutto su credenziali rubate e porte già aperte, non su exploit sofisticati. La conclusione di Zanger è la frase che dovrebbe entrare in ogni policy aziendale: «i controlli si possono esternalizzare. La responsabilità no».

Il vero meccanismo del sandbox escape negli agenti AI: non serve rompere la gabbia

Qui sta la parte che interessa davvero chi costruisce sistemi. La ricerca più lucida sul tema arriva da Pillar Security, che ha analizzato il fenomeno subito dopo gli episodi di luglio e propone un modello a tre strati: esecuzione diretta (cosa il processo dell’agente può eseguire), scritture nel workspace (quali file può creare o modificare) e fiducia dell’host (quali componenti non isolati consumeranno poi quei file). Il punto è che il terzo strato annulla i primi due.

Come hanno sintetizzato i ricercatori su CSO Online, «l’agente non aveva bisogno di rompere la sandbox direttamente. Doveva solo scrivere qualcosa che un componente fidato fuori dalla sandbox avrebbe poi eseguito, caricato, scansionato o trattato come sicuro». Su un endpoint di sviluppo i file di progetto sono infrastruttura eseguibile: hook, task, virtualenv, configurazioni. La formula di Pillar è definitiva: «se un agente può scrivere gli input futuri dei sistemi, non è mai stato in una sandbox».

Configuration-Based Sandbox Escape: quando l’agente riscrive le proprie regole

Il caso più istruttivo è la classe di vulnerabilità documentata dal Cymulate Research Lab (Ilan Kalendarov, Ben Zamir, Elad Beber). Gli strumenti CLI agentici isolano i processi a livello di sistema operativo, ma lasciano scrivibili dall’interno della sandbox i propri file di configurazione, .claude/settings.json, .gemini/settings.json, .codex/config.toml, che contengono hook eseguiti automaticamente all’avvio «senza dialogo di conferma, senza notifica all’utente, senza log di audit». L’innesco tipico è una prompt injection nascosta in un repository. Gli esiti raccontano molto della maturità del settore: Claude Code patchato in 16 giorni (CVE-2026-25725, CVSS 7.7), Gemini CLI senza fix dopo oltre 90 giorni, Codex CLI chiuso come “informativo”.

Quanto sono davvero capaci gli agenti AI di evadere una sandbox

Una misura indipendente esiste. Università di Oxford e AI Security Institute hanno costruito SandboxEscapeBench: 18 scenari su tre strati dello stack container, orchestrazione, runtime, kernel, in forma di capture-the-flag. I risultati vanno letti con attenzione: i modelli di frontiera riescono dove trovano socket Docker esposti, mount dell’host scrivibili e container privilegiati, mentre gli exploit a livello kernel restano fuori portata. E soprattutto: «tutte le evasioni riuscite si sono basate su misconfigurazioni note o vulnerabilità già divulgate». Non è magia: è il vostro hardening mancante, sfruttato a velocità macchina.

Cosa cambia per chi porta un agente AI in produzione

La traduzione operativa è meno drammatica e più noiosa di quanto suggeriscano i titoli: i confini dei tool vanno progettati come confini di rete, non come istruzioni nel prompt. Un permesso scritto in linguaggio naturale è un suggerimento; un egress bloccato è un confine. Il Non-Human Identity Management Group lo inquadra bene definendo il sandbox escape «un fallimento di governance, non solo di modello»: il problema nasce quando un agente può influenzare un componente fidato esterno e quel componente esegue il risultato senza validazione indipendente. È anche il motivo per cui, come è stato osservato commentando gli stessi episodi, agli agenti si applicano le regole di sicurezza di sempre.

Tre azioni contro il sandbox escape degli agenti AI

Le tre azioni concrete che emergono da quell’analisi sono applicabili a qualsiasi deployment: censire tutti i passaggi di fiducia (file, daemon, registry, connettori, percorsi di uscita) classificando quali componenti possono eseguire o inoltrare l’output dell’agente; sostituire l’accesso proxy generico con allowlist esplicite per pacchetti, API e tool; registrare la provenance al momento dell’esecuzione, cioè quale azione dell’agente ha prodotto un input, quale helper l’ha consumato e con quale account. Il principio guida: ogni passaggio di fiducia è una decisione di controllo accessi, non uno strato di comodità.

Approvazione umana e reti separate per gli agenti AI

Aggiungete due elementi che gli incidenti di luglio rendono non negoziabili: le azioni irreversibili, deploy, cancellazioni, invii, pagamenti, vanno vincolate a un’approvazione umana implementata nel tool, non chiesta nel prompt; e gli ambienti di valutazione vanno separati a livello di rete da qualsiasi sistema reale, perché è lì che girano i modelli più capaci con obiettivi adversariali. Se lavorate con connettori e server MCP, ogni connettore è un confine da inventariare. E se il perimetro tocca dati personali, valgono le considerazioni che abbiamo raccolto sul rapporto tra GDPR, sicurezza e adozione responsabile dell’AI.

Perché l’onboarding di un agente AI non è un rollout self-service

C’è una conseguenza che raramente viene detta in modo esplicito. Se il confine reale di un agente non è la sandbox ma l’insieme dei componenti che si fidano del suo output, allora nessun setup self-service può essere sicuro per definizione: la persona che attiva l’integrazione dovrebbe conoscere quali daemon girano sulla macchina, quali file di configurazione vengono eseguiti all’avvio, quali percorsi di rete sono raggiungibili e quali azioni sono irreversibili.

È una competenza da security engineer, non da utente finale. La domanda posta dai ricercatori di Cymulate, «se un agente AI non riesce a proteggere il proprio confine di esecuzione, come può essere considerato affidabile per proteggere l’ambiente dello sviluppatore?», va girata a chi adotta: chi sta decidendo dove mettere i limiti nel vostro deployment?

Chi definisce i confini di un agente AI in azienda

È esattamente per questo che in MIMIR consideriamo l’onboarding parte del prodotto e non un accessorio. Non consegniamo un agente e un manuale: definiamo insieme quali tool può toccare, dove si fermano i suoi permessi, quali passaggi restano sotto approvazione umana e come vengono tracciati. Gli episodi di luglio hanno dimostrato che la differenza tra un agente utile e un incidente sta nella qualità di quelle decisioni iniziali, non nella potenza del modello, un tema che tocca da vicino anche il motivo per cui l’AI generativa spesso non genera ROI. Se state valutando un agente AI per la vostra azienda e volete affrontare il problema dei confini prima di scoprirlo in produzione, parliamone con MIMIR: una consulenza iniziale serve a capire dove vanno messi i limiti, e quel lavoro non si delega a un wizard di configurazione.

Fonti:

• CNN — OpenAI conferma l’evasione dei modelli interni e l’accesso a Hugging Face
• The Hacker News — la catena SharedRoot su Claude Cowork
• Decrypt — ricostruzione dei due episodi di sandbox escape
• Check Point — Jonathan Zanger: perché la cornice del “sandbox escape” è fuorviante
• HSF Kramer — chi segnala e chi risponde quando un agente AI evade la sandbox
• CSO Online — gli agenti evadono la sandbox senza mai romperla
• Pillar Security — il modello a tre strati della settimana dei sandbox escape
• Dark Reading — agli agenti AI si applicano le vecchie regole di sicurezza
• Cymulate Research Lab — Configuration-Based Sandbox Escape nei CLI agentici
• Help Net Security — SandboxEscapeBench di Oxford e AI Security Institute
• Non-Human Identity Management Group — i controlli di contenimento sono sufficienti?