OpenAI Codex è sicuro da usare? Rischi, modalità sandbox e best practice

Cos'è OpenAI Codex e perché cambia il modello di sicurezza?

OpenAI Codex è lo strumento di codice agentico di OpenAI. Funziona ovunque lo sviluppatore già lavori: una Codex CLI nel terminale, un'estensione per l'IDE, una modalità cloud e multi-agente che esegue task in modo asincrono, e un SDK per collegare Codex alla tua automazione. Agisce su istruzioni in linguaggio naturale: analizza un codebase, genera una funzionalità, esegui i test, correggi i fallimenti, apri una pull request. Si connette a GitHub, lavora a fianco di sistemi di build e può essere puntato su un repository e lasciato lavorare.

Prima un chiarimento sui nomi, perché fa inciampare quasi tutti coloro che cercano questo argomento. "Codex" in questo articolo significa l'agente di codice (CLI, estensione IDE, cloud e SDK). Separatamente, OpenAI ha rilasciato una funzionalità letteralmente chiamata Codex Security: un agente che si connette a un repository, costruisce un modello delle minacce specifico per il codebase, scansiona la cronologia dei commit, valida le vulnerabilità candidate in un ambiente isolato e propone correzioni per la revisione umana. I due sono facili da confondere. Questa guida riguarda la protezione dell'agente di codice Codex. Codex Security, la capacità di individuazione delle vulnerabilità di OpenAI, è trattata brevemente più sotto come un input di supporto, non un programma di sicurezza completo.

Quella proprietà agentica è quella che rompe il vecchio modello di sicurezza. Un assistente IDE tradizionale suggerisce completamenti; un essere umano accetta o rifiuta ciascuno di essi. Il raggio d'azione di un suggerimento sbagliato è un singolo blocco di codice che lo sviluppatore deve comunque incollare. Codex invece compie azioni. Legge file che non hai nominato, esegue comandi che non hai digitato, modifica codice in tutto l'albero e in modalità cloud può girare a lungo senza che nessuno guardi. La superficie di attacco non è più "quale codice ha suggerito il modello". È "cosa può fare questo agente con l'accesso che ha, e chi può influenzare le sue istruzioni".

“

Un suggerimento è una bozza che un essere umano sceglie di accettare. Un'azione è una cosa già accaduta. Il modello di sicurezza deve passare dalla revisione di bozze al vincolo delle azioni.

C'è un secondo cambiamento che conta ancora di più, e riguarda la velocità. La pull request è diventata la casa della sicurezza applicativa perché si collocava al ritmo umano: una persona rallentava, leggeva il diff e solo allora faceva il merge. Codex, specialmente in modalità cloud e multi-agente, non lavora al ritmo umano. Una singola sessione può spedire più codice in un pomeriggio di quanto un revisore ne legga in una settimana. Quando ciò accade, il diff smette di essere un punto di controllo e diventa la trascrizione di decisioni già prese. Qualsiasi controllo che agisca solo alla pull request ora sta rivedendo la storia, non prevenendola.

Per la maggior parte dei team la domanda pratica non è se Codex abbia protezioni native. Le ha, e sono progettate con buon senso. La domanda è se quelle protezioni siano sufficienti per l'uso quotidiano. La risposta onesta è no. La guida "Running Codex safely" di OpenAI inquadra sandbox e approvazioni come difesa in profondità, non come confine completo, e nel momento in cui passi alla modalità full-access o abiliti l'accesso di rete nella sandbox, quelle barriere di sicurezza vengono rimosse per progettazione. Un'adozione sicura dipende ancora da permessi, disciplina sulla sandbox, supervisione umana e validazione indipendente su codice, dipendenze e pipeline.

Come funziona il modello di sicurezza di Codex

Il modello di Codex è costruito attorno a tre idee: esegui il lavoro dentro una sandbox, chiedi prima di fare qualcosa che ne sfugge, e mantieni la rete chiusa a meno che tu non la apra. In pratica ciò si traduce in una manciata di controlli.

È una base davvero ben pensata, e gran parte di questo elenco non esisteva negli assistenti IDE di una generazione fa. La trappola è leggerla come un confine di sicurezza definitivo. OpenAI è esplicita sul fatto che la modalità auto è una via di mezzo anziché una garanzia, che full-access e il flag --dangerously-bypass-approvals-and-sandbox rimuovono la sandbox di proposito, e che abilitare l'accesso di rete dentro la sandbox è uno scambio deliberato di sicurezza per capacità. Ogni controllo di questo elenco ha un modo documentato per disattivarlo, e la prossima sezione riguarda cosa succede quando lo fai, o quando un attaccante lo fa per te.

I 6 principali rischi per la sicurezza in OpenAI Codex

I rischi qui sotto non sono teorici. Mappano a vulnerabilità documentate, ricerche pubblicate e alla OWASP Top 10 per le applicazioni LLM. I numeri che li inquadrano sono gli stessi che ogni team AppSec sta ora citando.

1. Command injection ed esecuzione di codice remoto

Codex scrive ed esegue codice a livello di sistema, quindi un difetto nel modo in cui gestisce i propri input diventa un percorso verso l'esecuzione di codice. Non è ipotetico. BeyondTrust Phantom Labs ha divulgato una vulnerabilità critica di command injection in OpenAI Codex che consentiva il furto di GitHub User Access Token, con il payload contrabbandato attraverso un nome di branch GitHub e nascosto all'interfaccia tramite caratteri Unicode invisibili. Poiché risiedeva nella richiesta di creazione del task, ha colpito contemporaneamente il sito ChatGPT, la Codex CLI, il Codex SDK e l'estensione IDE di Codex.

OpenAI l'ha corretta (un hotfix iniziale entro una settimana dalla segnalazione del dicembre 2025, protezioni shell più robuste e ambito del token ridotto all'inizio del 2026, classificata infine come Critical Priority 1), quindi questo bug specifico è chiuso. Resta la più chiara illustrazione della superficie: un agente che esegue comandi shell per tuo conto trasforma qualsiasi input non sanificato che legge, un nome di branch, un nome di file, la risposta di uno strumento, in un potenziale punto di injection. Il pericolo si aggrava quando l'agente gira con ampio accesso shell e una modalità permissiva, perché una catena di comandi singolarmente innocui può installare una dipendenza, alterare una configurazione CI o aprire un meccanismo di persistenza.

2. Supply chain e dipendenze dannose

Codex installa pacchetti, clona repository ed esegue script di setup come parte del normale lavoro, e la sua stessa popolarità lo ha reso un bersaglio. TechRadar e altre testate hanno riportato di un pacchetto npm, codexui-android, che si spacciava per una UI remota per Codex, ha attirato circa 29.000 download e, dopo una release iniziale pulita, ha pubblicato un aggiornamento che esfiltrava silenziosamente il contenuto del file di credenziali di Codex (~/.codex/auth.json), token di accesso, refresh e ID, verso un server controllato dall'attaccante. Poiché il refresh token non scade, una singola installazione compromessa può concedere accesso persistente e silenzioso.

Quell'incidente si colloca dentro uno schema più ampio. Per tutto il 2025 e fino al 2026, le campagne di typosquatting e di pacchetti sosia su npm hanno preso di mira sempre più gli strumenti di codice AI e i loro ecosistemi. Il workflow di sviluppo stesso diventa il vettore di attacco: un package.json avvelenato, un hook post-install dannoso o un helper soggetto a typosquatting possono trasformare un prompt di routine "configura questo repo" in furto di credenziali. L'allucinazione dei pacchetti lo aggrava, un agente che inventa con sicurezza un nome di pacchetto plausibile ma inesistente offre a un attaccante uno slot da registrare e armare.

3. Prompt injection e scrittura di exploit guidata

La prompt injection è il rischio distintivo degli strumenti di codice agentici, ed è il rischio LLM numero uno di OWASP per il terzo anno consecutivo (LLM01). Un attaccante nasconde istruzioni in qualcosa che l'agente legge, un file, una pagina web, una issue, il README di una dipendenza, l'output di uno strumento, e l'agente le segue, scavalcando il comportamento previsto.

Il contesto agentico peggiora la posta in gioco, perché Codex non si limita a rispondere; agisce e scrive codice a livello di sistema. Un agente guidato può essere spinto a scrivere un exploit, indebolire un controllo di autorizzazione, aggiungere un percorso di deserializzazione non sicuro o collegare una backdoor che sembra corretta a un revisore stanco. La forma pericolosa è quella indiretta: non devi incollare un prompt dannoso, ti basta puntare Codex verso un repository avvelenato o lasciargli consumare l'output ostile di uno strumento. Poiché un modello linguistico non può separare in modo affidabile un'istruzione attendibile da una dannosa incorporata nei dati, l'injection può portare a esecuzione di comandi, esfiltrazione di dati o manipolazione silenziosa del codice.

4. Sandbox e modalità di approvazione troppo permissive

La sicurezza di Codex poggia sulla sua sandbox e sui suoi prompt di approvazione, ed entrambi possono essere abbassati con un singolo flag. Scegliere full-access (danger-full-access), o abilitare l'accesso di rete in uscita dentro la sandbox workspace-write, baratta la barriera di sicurezza per capacità, e OpenAI lo dice chiaramente. Con la sandbox aperta e la rete raggiungibile, lo stesso agente che un momento fa era contenuto può ora scrivere fuori dal workspace e inviare dati ovunque.

Il meccanismo che erode tutto questo in pratica è la stanchezza da approvazioni. Quando l'agente si ferma ripetutamente, le persone ricorrono a --ask-for-approval never, o al preset full-auto, per far sparire i prompt. Nel giro di una settimana l'impostazione predefinita prudente è diventata silenziosamente una concessione generale, e nessuno ha deciso che lo fosse. La versione a livello di team è peggiore: uno sviluppatore lavora read-only, un altro lavora full-access perché era più rapido un venerdì, e nel momento in cui condividono un repository o un workflow automatizzato, la configurazione più debole stabilisce la postura reale per tutti.

5. Retention dei dati e privacy

Codex è utile perché ha contesto, e quel contesto include regolarmente più del file che hai davanti: codice adiacente, configurazione, variabili d'ambiente e talvolta credenziali. Gli agenti generano e trasmettono grandi quantità di codice privato in serie, prompt dopo prompt, task dopo task. Per i codebase sensibili o regolamentati, la domanda giusta non è solo "la connessione è cifrata" ma "cosa viene memorizzato, per quanto, dove e chi può raggiungerlo".

L'esposizione è spesso indiretta anziché drammatica. Mentre riassume un repository o esegue il debug di un errore, l'agente può far emergere un token o un endpoint interno in un output che poi finisce in una pull request, un ticket o una chat, dove sopravvive a lungo dopo la fine della sessione. Le organizzazioni che adottano Codex su larga scala dovrebbero rivedere i termini di gestione dei dati e di retention di OpenAI per la superficie che usano (l'API, i livelli business ed enterprise differiscono), tenere segreti e dati regolamentati fuori dalla portata dell'agente e trattare qualsiasi cosa l'agente emetta come potenzialmente registrata.

6. Autonomia su larga scala

La capacità che rende Codex avvincente, esegui un task e torna a una pull request finita, è anche quella che allarga il divario di revisione. In modalità cloud e multi-agente, Codex può fare modifiche grandi e radicali su molti file con poca attenzione umana nel mezzo. Più il task è autonomo e a lunga esecuzione, più grande è il diff, e più piccola è la quota di esso che un essere umano legge davvero prima di approvare.

Ciò conta per la sicurezza perché la finestra entro cui una modifica insicura o dannosa può finire dentro cresce con la dimensione del diff non letto. Una regressione di autorizzazione sottile, una dipendenza iniettata o una validazione silenziosamente indebolita sono molto più facili da mancare in una modifica autonoma di 2.000 righe che in una di 20 righe che uno sviluppatore ha digitato deliberatamente. L'autonomia non crea nuove classi di vulnerabilità tanto quanto rimuove l'attrito naturale che le coglieva, ed è proprio per questo che i controlli qui sotto si appoggiano così pesantemente su revisione, limitazione dell'ambito e governance al momento del prompt.

Cosa copre la sicurezza nativa di Codex, e cosa no

I controlli nativi sono reali, e conviene essere precisi sulla linea tra ciò che gestiscono e ciò che lasciano a te.

Leggi la colonna di destra come il lavoro vero e proprio. I controlli nativi sono il pavimento: la sandbox e il default di rete impediscono che un errore in buona fede, o un singolo comando guidato, diventi un disastro su tutta la macchina. Non sono stati progettati per fermare un avversario determinato che controlla gli input dell'agente, e OpenAI non sostiene che lo siano. Tutto ciò che trasforma "Codex è installato" in "Codex è governato" vive nelle pratiche che seguono.

Best practice per proteggere OpenAI Codex

Queste nove pratiche colmano il divario tra la base nativa e una postura di sicurezza reale. Nessuna di esse è esotica; la disciplina sta nell'applicarle in modo coerente in un team che si muove in fretta.

1. Tieni la sandbox attiva e il full-access disattivato. Usa di default read-only per l'esplorazione e auto (workspace-write) per il lavoro reale, e tratta full-access (danger-full-access) e --dangerously-bypass-approvals-and-sandbox come riservati solo ai container usa e getta. Conferma che la sandbox OS sia davvero attiva su ogni piattaforma su cui esegui, e non disattivarla mai su una macchina che può raggiungere credenziali reali o host di produzione.

2. Lascia la rete chiusa a meno che un task non ne abbia davvero bisogno. Il default cloud di nessun accesso in uscita è la barriera di sicurezza più preziosa che Codex include, perché l'esfiltrazione di solito ha bisogno della rete. Abilita l'accesso di rete nella sandbox workspace-write solo per il task specifico che lo richiede, limitalo a destinazioni note dove puoi, e riportalo a disattivato dopo anziché lasciarlo aperto per abitudine.

3. Applica il privilegio minimo a repository e token. Dai a Codex accesso solo ai repository di cui un task ha bisogno, preferisci token GitHub effimeri e a portata ristretta rispetto a quelli ampi e persistenti, e ruotali secondo una pianificazione anziché aspettare un incidente. La divulgazione di BeyondTrust è un promemoria del fatto che un singolo token GitHub trapelato può raggiungere ogni repository per cui era stato concesso, quindi l'ambito del token è l'ambito della violazione.

4. Governa dipendenze e pacchetti. Limita le installazioni a registry attendibili o mirror interni, richiedi l'approvazione per i nuovi pacchetti e analizza tutto con la software composition analysis. Non lasciare che l'agente installi automaticamente pacchetti oscuri o non verificati per quanto sicuro li suggerisca, verifica che un pacchetto suggerito esista davvero prima che venga aggiunto, e diffida specialmente degli strumenti helper che avvolgono Codex stesso, è proprio lì che viveva il ladro di token codexui-android.

5. Mantieni un essere umano nel ciclo sul codice generato. Tratta l'output di Codex come una bozza, non come un'implementazione finale, e dimensiona la revisione alla dimensione della modifica. Indirizza il codice generato e modificato attraverso la revisione delle pull request e i test automatizzati, con scrutinio extra su autenticazione, validazione degli input e percorsi privilegiati. Il punto non è la sfiducia nel modello; è che un agente che produce migliaia di righe al giorno, specialmente in modalità cloud, genererà difetti sottili più in fretta di quanto emergano da soli.

6. Esegui il lavoro non attendibile in isolamento. Quando punti Codex verso un repository sconosciuto, una issue di terze parti o qualsiasi cosa che non hai scritto, eseguilo in un container o una VM senza segreti dell'host montati e senza percorso verso la produzione. La prompt injection indiretta arriva proprio attraverso questo tipo di contenuto, quindi la difesa più economica è assicurarsi che un agente guidato non abbia nulla di prezioso a portata.

7. Tieni i segreti fuori portata. Tieni i segreti in chiaro completamente fuori dal contesto dell'agente: usa un vault e iniettali a runtime, oscura i valori sensibili nei log, e non lasciare che l'agente legga file di credenziali o contenuti .env di cui non ha bisogno. Proteggi il file di credenziali di Codex stesso (~/.codex/auth.json) come il bersaglio di alto valore che è, e se un segreto compare mai in una trascrizione o in un output, ruotalo immediatamente e indaga su come ci è arrivato.

8. Vincola l'autonomia in modalità cloud e multi-agente. Limita strettamente l'ambito dei task a lunga esecuzione e asincroni, preferisci diverse modifiche revisionabili a una sola radicale, e richiedi l'approvazione umana prima che un branch creato da Codex venga fuso in qualcosa di protetto. Più grande è il diff autonomo, più deliberata deve essere la revisione, quindi imposta aspettative (e regole di protezione dei branch) che corrispondano al volume che Codex può produrre.

9. Imposta la policy per sensibilità di repository e ambiente. Classifica i repository (pubblici, interni, regolamentati, di produzione) e applica controlli più rigidi a quelli sensibili: modalità read-only o strettamente limitate, rete chiusa, nega l'accesso ai segreti, richiedi una revisione più robusta. Esegui Codex contro sistemi critici solo in ambienti senza percorso diretto verso le credenziali di produzione, e documenta la policy così che gli sviluppatori sappiano dove l'aiuto dell'AI è consentito e sotto quali vincoli. Usa Codex Security e il SAST tradizionale come input di supporto a quella revisione, non come sostituto di essa.

Dove si fermano i controlli nativi: proteggere l'agente al momento del prompt

Ripercorri i rischi ed emerge uno schema. La sandbox, le modalità di approvazione e il passo di revisione agiscono tutti su ciò che l'agente ha già deciso di fare, o su codice che ha già scritto. Si raggruppano attorno alla pull request, perché è lì che l'AppSec ha sempre vissuto. Ma la PR è stata un punto di controllo solo perché un essere umano la leggeva, e al ritmo dell'agente, specialmente in modalità cloud, nessuno la legge più dall'inizio alla fine.

Il luogo dove imporre una regola non è più il diff; è il prompt, prima che la riga insicura venga scritta. Qualunque regola tu voglia che l'agente segua deve essere nelle sue mani nel momento in cui scrive, non in attesa in uno scanner che arriva quando il codice è già su disco e l'agente è già passato al compito successivo.

È questo il livello che aggiunge VibeDefend. È una CLI npm gratuita che si installa in circa cinque secondi e collega OpenAI Codex (oltre a Claude Code, Cursor, Windsurf e VS Code Copilot) a quattro livelli di governance che girano dentro il loop dell'agente.

Regole di business Le convenzioni del tuo repo che non sono mai state messe per iscritto (usa Decimal128 per il denaro, l'autorizzazione passa per requireOwner). VibeDefend le estrae dal modo in cui il tuo team già scrive codice e le carica nel contesto dell'agente prima di ogni modifica. Regole di sicurezza OWASP Top 10, SOC 2, GDPR e ISO 27001, caricate il giorno in cui installi. L'agente legge il promemoria applicabile prima di scrivere, così il requisito del framework diventa parte del codice anziché una casella da spuntare al momento dell'audit. Action Guard Le chiamate distruttive (un sudo rm -rf, una lettura grezza di una variabile d'ambiente che sembra un segreto, un psql ad hoc contro un host di produzione) vengono intercettate prima che partano. Avvisa o blocca per regola, con ogni intercettazione nell'audit trail. Live Findings Ogni risultato dei suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) è live nel contesto dell'agente, così non si limita a scrivere codice sicuro, smista e corregge le vulnerabilità che hai già.

In modo cruciale, nulla del tuo codice attraversa la rete. Le decisioni avvengono localmente accanto all'agente; solo metadati di governance strutturati (la regola che è scattata, il percorso del file, la severità, un timestamp) raggiungono il backend. Le regioni EU e US sono fisicamente separate, e scegli la regione al momento dell'installazione. Quel modello di privacy è ciò che permette a un controllo di stare così vicino al codice senza diventare a sua volta un rischio di esfiltrazione dei dati, il che conta ancora di più per un agente il cui stesso file di credenziali è già stato bersaglio di furto.

Questo non sostituisce le pratiche di cui sopra. È il livello mancante che esse danno per esistente: quello che mette le tue regole nelle mani dell'agente al momento del prompt, così che la riga insicura venga riscritta prima ancora di essere suggerita, anziché colta tre fasi più tardi da uno scanner che legge un diff che nessuno ha avuto tempo di leggere. La sandbox impedisce all'agente di fare ciò che non deve fare; VibeDefend modella ciò che scrive in primo luogo.

Domande frequenti

OpenAI Codex è sicuro?

OpenAI Codex è sicuro da usare quando è in sandbox e limitato nell'ambito, e rischioso quando non lo è. La sua sandbox a livello di OS, le modalità di approvazione a livelli e il comportamento di rete disattivata per impostazione predefinita nel cloud prevengono un'ampia classe di incidenti e contengono la maggior parte dei comandi vaganti. Il rischio residuo viene dalla configurazione (modalità full-access, rete abilitata, approvazioni disabilitate), dagli input (prompt injection, repository e pacchetti dannosi) e dall'autonomia su larga scala (grandi modifiche cloud che vengono sotto-revisionate). Trattalo come un agente potente che ha bisogno di privilegio minimo, isolamento e revisione umana, non come uno strumento sicuro pronto all'uso.

Qual è la differenza tra Codex e "Codex Security"?

Sono due cose diverse di OpenAI che condividono un nome. Codex è lo strumento di codice agentico: la CLI, l'estensione IDE, la modalità cloud e l'SDK che leggono il tuo repo, modificano file, eseguono comandi e aprono pull request. Codex Security è un agente separato di individuazione delle vulnerabilità che si connette a un repository, costruisce un modello delle minacce, scansiona la cronologia dei commit, valida le questioni candidate in isolamento e propone correzioni per la revisione umana. Questa guida riguarda la protezione dell'agente di codice Codex. Codex Security è un input di supporto alla code review, utile come un paio di occhi in più, non un programma di sicurezza completo.

Codex esegue il codice in una sandbox?

Sì. Codex esegue i comandi dentro una sandbox a livello di sistema operativo: Seatbelt su macOS, Landlock e seccomp su Linux, e una sandbox dedicata su Windows. Per impostazione predefinita, le scritture sono limitate al workspace attivo e, nell'ambiente cloud, l'accesso di rete in uscita è disabilitato. Quei default sono il cuore del suo modello di sicurezza. Possono essere abbassati deliberatamente con full-access (danger-full-access) o abilitando l'accesso di rete dentro la sandbox workspace-write, e OpenAI è esplicita sul fatto che farlo rimuove la protezione di proposito.

Codex può far trapelare il mio token GitHub o le credenziali?

Può, se non stai attento, e c'è un precedente. BeyondTrust Phantom Labs ha divulgato una vulnerabilità di command injection che permetteva agli attaccanti di rubare GitHub User Access Token tramite un nome di branch costruito ad arte attraverso il sito ChatGPT, la Codex CLI, l'SDK e l'estensione IDE; OpenAI l'ha da allora corretta. Separatamente, un pacchetto npm dannoso che si spacciava per un helper di Codex ha esfiltrato il file di credenziali di Codex (~/.codex/auth.json) da circa 29.000 installazioni. Difendi il token limitandone strettamente l'ambito, ruotandolo, verificando qualsiasi strumento helper e proteggendo il file di credenziali come un segreto di alto valore.

Codex invia il mio codice a OpenAI?

Codex invia il contesto di cui ha bisogno ai modelli di OpenAI per generare risposte, il che può includere codice, contenuti dei file e il contesto circostante del tuo compito. Cosa viene memorizzato e per quanto dipende dalla superficie che usi e dal tuo livello (i termini API, business ed enterprise differiscono su retention e addestramento). Per il codice sensibile, scegli un livello e una configurazione che corrispondano ai tuoi requisiti di gestione dei dati, tieni segreti e dati regolamentati fuori dalla portata dell'agente e rivedi le policy di retention. I metadati di governance di un livello aggiunto come VibeDefend restano separati e non trasmettono codice sorgente.

Quale modalità di sandbox/approvazione di Codex dovrei usare?

Per la maggior parte del lavoro, read-only per esplorare e auto (la sandbox workspace-write con approvazione su richiesta) per fare modifiche, con la rete lasciata chiusa. Riserva full-access (danger-full-access) e --dangerously-bypass-approvals-and-sandbox ai container usa e getta senza credenziali reali, ed evita --ask-for-approval never su qualsiasi macchina che può raggiungere la produzione o i segreti. Adatta la modalità alla sensibilità del repository: più il sistema è critico, più stretta la sandbox, più approvazione, e meno rete dovrebbe avere l'agente. Che cosa disattiva esattamente ogni flag è spiegato in Codex danger-full-access, --yolo e la "modalità unsafe".

In cosa la sicurezza di Codex è diversa da Claude Code, Cursor o GitHub Copilot?

I fondamentali sono condivisi (privilegio minimo, gestione dei segreti, revisione umana, scansione delle dipendenze), ma le superfici differiscono. Le superfici distintive di Codex sono la sua sandbox OS più la via di fuga full-access, i suoi incidenti di command injection e supply chain npm, e il divario di revisione della modalità cloud autonoma. Claude Code si appoggia alla profonda integrazione con MCP e shell; Cursor ha avuto il Workspace Trust disabilitato per impostazione predefinita; GitHub Copilot ha combattuto suggerimenti insicuri e fuoriuscita di segreti su larga scala. Copriamo ogni agente nella sua guida.