Sicurezza di OpenAI Codex: rischi, controlli e best practice

Cos'e OpenAI Codex e perche cambia il modello di sicurezza?

OpenAI Codex e lo strumento di codice agentico di OpenAI. Funziona ovunque lo sviluppatore gia lavori: una Codex CLI nel terminale, un'estensione per l'IDE, una modalita 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 funzionalita, esegui i test, correggi i fallimenti, apri una pull request. Si connette a GitHub, lavora a fianco di sistemi di build e puo essere puntato su un repository e lasciato lavorare.

Prima un chiarimento sui nomi, perche 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 funzionalita 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 vulnerabilita 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 capacita di individuazione delle vulnerabilita di OpenAI, e trattata brevemente piu sotto come un input di supporto, non un programma di sicurezza completo.

Quella proprieta agentica e 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 e 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 modalita cloud puo girare a lungo senza che nessuno guardi. La superficie di attacco non e piu "quale codice ha suggerito il modello". E "cosa puo fare questo agente con l'accesso che ha, e chi puo influenzare le sue istruzioni".

“

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

C'e un secondo cambiamento che conta ancora di piu, e riguarda la velocita. La pull request e diventata la casa della sicurezza applicativa perche si collocava al ritmo umano: una persona rallentava, leggeva il diff e solo allora faceva il merge. Codex, specialmente in modalita cloud e multi-agente, non lavora al ritmo umano. Una singola sessione puo spedire piu codice in un pomeriggio di quanto un revisore ne legga in una settimana. Quando cio accade, il diff smette di essere un punto di controllo e diventa la trascrizione di decisioni gia 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 e se Codex abbia protezioni native. Le ha, e sono progettate con buon senso. La domanda e se quelle protezioni siano sufficienti per l'uso quotidiano. La risposta onesta e no. La guida "Running Codex safely" di OpenAI inquadra sandbox e approvazioni come difesa in profondita, non come confine completo, e nel momento in cui passi alla modalita 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 e 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 cio si traduce in una manciata di controlli.

E una base davvero ben pensata, e gran parte di questo elenco non esisteva negli assistenti IDE di una generazione fa. La trappola e leggerla come un confine di sicurezza definitivo. OpenAI e esplicita sul fatto che la modalita auto e una via di mezzo anziche 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 e uno scambio deliberato di sicurezza per capacita. 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 vulnerabilita 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 e ipotetico. BeyondTrust Phantom Labs ha divulgato una vulnerabilita 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. Poiche 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 piu robuste e ambito del token ridotto all'inizio del 2026, classificata infine come Critical Priority 1), quindi questo bug specifico e chiuso. Resta la piu 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 modalita permissiva, perche una catena di comandi singolarmente innocui puo 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 popolarita 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. Poiche il refresh token non scade, una singola installazione compromessa puo concedere accesso persistente e silenzioso.

Quell'incidente si colloca dentro uno schema piu ampio. Per tutto il 2025 e fino al 2026, le campagne di typosquatting e di pacchetti sosia su npm hanno preso di mira sempre piu gli strumenti di codice IA 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 e il rischio distintivo degli strumenti di codice agentici, ed e 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, perche Codex non si limita a rispondere; agisce e scrive codice a livello di sistema. Un agente guidato puo 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 e 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. Poiche un modello linguistico non puo separare in modo affidabile un'istruzione attendibile da una dannosa incorporata nei dati, l'injection puo portare a esecuzione di comandi, esfiltrazione di dati o manipolazione silenziosa del codice.

4. Sandbox e modalita 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 capacita, e OpenAI lo dice chiaramente. Con la sandbox aperta e la rete raggiungibile, lo stesso agente che un momento fa era contenuto puo ora scrivere fuori dal workspace e inviare dati ovunque.

Il meccanismo che erode tutto questo in pratica e 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 e diventata silenziosamente una concessione generale, e nessuno ha deciso che lo fosse. La versione a livello di team e peggiore: uno sviluppatore lavora read-only, un altro lavora full-access perche era piu rapido un venerdi, e nel momento in cui condividono un repository o un workflow automatizzato, la configurazione piu debole stabilisce la postura reale per tutti.

5. Retention dei dati e privacy

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

L'esposizione e spesso indiretta anziche drammatica. Mentre riassume un repository o esegue il debug di un errore, l'agente puo 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 capacita che rende Codex avvincente, esegui un task e torna a una pull request finita, e anche quella che allarga il divario di revisione. In modalita cloud e multi-agente, Codex puo fare modifiche grandi e radicali su molti file con poca attenzione umana nel mezzo. Piu il task e autonomo e a lunga esecuzione, piu grande e il diff, e piu piccola e la quota di esso che un essere umano legge davvero prima di approvare.

Cio conta per la sicurezza perche la finestra entro cui una modifica insicura o dannosa puo 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 piu 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 vulnerabilita tanto quanto rimuove l'attrito naturale che le coglieva, ed e proprio per questo che i controlli qui sotto si appoggiano cosi 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 cio che gestiscono e cio 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 cio che trasforma "Codex e installato" in "Codex e 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 e 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 puo 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 e la barriera di sicurezza piu preziosa che Codex include, perche 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 anziche 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 anziche aspettare un incidente. La divulgazione di BeyondTrust e un promemoria del fatto che un singolo token GitHub trapelato puo raggiungere ogni repository per cui era stato concesso, quindi l'ambito del token e 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, e proprio li 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 e la sfiducia nel modello; e che un agente che produce migliaia di righe al giorno, specialmente in modalita cloud, generera difetti sottili piu 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 piu economica e 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, e se un segreto compare mai in una trascrizione o in un output, ruotalo immediatamente e indaga su come ci e arrivato.

8. Vincola l'autonomia in modalita 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. Piu grande e il diff autonomo, piu deliberata deve essere la revisione, quindi imposta aspettative (e regole di protezione dei branch) che corrispondano al volume che Codex puo produrre.

9. Imposta la policy per sensibilita di repository e ambiente. Classifica i repository (pubblici, interni, regolamentati, di produzione) e applica controlli piu rigidi a quelli sensibili: modalita read-only o strettamente limitate, rete chiusa, nega l'accesso ai segreti, richiedi una revisione piu robusta. Esegui Codex contro sistemi critici solo in ambienti senza percorso diretto verso le credenziali di produzione, e documenta la policy cosi che gli sviluppatori sappiano dove l'aiuto dell'IA e 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 modalita di approvazione e il passo di revisione agiscono tutti su cio che l'agente ha gia deciso di fare, o su codice che ha gia scritto. Si raggruppano attorno alla pull request, perche e li che l'AppSec ha sempre vissuto. Ma la PR e stata un punto di controllo solo perche un essere umano la leggeva, e al ritmo dell'agente, specialmente in modalita cloud, nessuno la legge piu dall'inizio alla fine.

Il luogo dove imporre una regola non e piu il diff; e 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 e gia su disco e l'agente e gia passato al compito successivo.

E questo il livello che aggiunge VibeDefend. E 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 gia 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, cosi il requisito del framework diventa parte del codice anziche 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) e live nel contesto dell'agente, cosi non si limita a scrivere codice sicuro, smista e corregge le vulnerabilita che hai gia.

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 e scattata, il percorso del file, la severita, un timestamp) raggiungono il backend. I tenant EU e US sono fisicamente separati, e scegli la regione al momento dell'installazione. Quel modello di privacy e cio che permette a un controllo di stare cosi vicino al codice senza diventare a sua volta un rischio di esfiltrazione dei dati, il che conta ancora di piu per un agente il cui stesso file di credenziali e gia stato bersaglio di furto.

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

Domande frequenti

OpenAI Codex e sicuro?

OpenAI Codex e sicuro da usare quando e in sandbox e limitato nell'ambito, e rischioso quando non lo e. La sua sandbox a livello di OS, le modalita 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 (modalita 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 e la differenza tra Codex e "Codex Security"?

Sono due cose diverse di OpenAI che condividono un nome. Codex e lo strumento di codice agentico: la CLI, l'estensione IDE, la modalita cloud e l'SDK che leggono il tuo repo, modificano file, eseguono comandi e aprono pull request. Codex Security e un agente separato di individuazione delle vulnerabilita 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 e un input di supporto alla code review, utile come un paio di occhi in piu, non un programma di sicurezza completo.

Codex esegue il codice in una sandbox?

Si. 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 e 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 e esplicita sul fatto che farlo rimuove la protezione di proposito.

Codex puo far trapelare il mio token GitHub o le credenziali?

Puo, se non stai attento, e c'e un precedente. BeyondTrust Phantom Labs ha divulgato una vulnerabilita 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 puo 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 modalita 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 puo raggiungere la produzione o i segreti. Adatta la modalita alla sensibilita del repository: piu il sistema e critico, piu stretta la sandbox, piu approvazione, e meno rete dovrebbe avere l'agente.

In cosa la sicurezza di Codex e 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 piu la via di fuga full-access, i suoi incidenti di command injection e supply chain npm, e il divario di revisione della modalita 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.