Agenti AI per il coding: 4M sviluppatori. Chi controlla?

Cosa è successo

OpenAI ha vissuto una settimana intensa. Codex, il loro agente AI per il coding, è cresciuto da 3 milioni a oltre 4 milioni di sviluppatori settimanali nelle prime due settimane di aprile. Hanno rilasciato GPT-5.5, il loro nuovo modello frontier, che si posiziona come il loro modello di coding più potente di sempre, risolvendo il 58,6% dei problemi reali di GitHub sul benchmark SWE-Bench Pro in un singolo passaggio. Hanno anche lanciato Codex Labs, un programma che integra ingegneri di OpenAI direttamente all'interno dei team enterprise, insieme a partnership con i principali system integrator per spingere Codex dalla sperimentazione ai workflow di produzione.

La stessa settimana, ProjectDiscovery ha pubblicato il loro AI Coding Impact Report 2026. Il 100% dei professionisti della sicurezza intervistati ha segnalato un aumento della produzione ingegneristica nell'ultimo anno, con quasi la metà che attribuisce gran parte di quell'accelerazione agli strumenti di coding AI. Ma ecco il numero che dovrebbe preoccuparci: il 78% degli stessi professionisti ha classificato «l'esposizione di segreti» come la principale sfida di sicurezza introdotta o amplificata dal coding assistito dall'AI. Due terzi di loro trascorrono più della metà del loro tempo a validare manualmente i risultati invece di correggere effettivamente i problemi.

Quindi abbiamo uno strumento di coding AI che aggiunge un milione di nuovi sviluppatori ogni due settimane, e i team di sicurezza sono già sommersi.

Il divario di cui nessuno parla onestamente

Voglio essere chiaro su questo punto. Usiamo strumenti di coding AI anche nel nostro lavoro. Sono genuinamente utili per il codice boilerplate, lo scaffolding dei test e l'esplorazione di codebase non familiari. Quando costruiamo app cloud-native e API per clienti enterprise, gli assistenti AI possono far risparmiare tempo reale sul codice infrastrutturale ripetitivo.

Ma c'è una differenza tra usare questi strumenti con delle protezioni e trattare il loro output come affidabile. In questo momento, il settore sta tendendo fortemente verso quest'ultimo approccio.

La ricerca 2026 di GitGuardian ha rilevato che i commit assistiti dall'AI su repository pubblici di GitHub hanno esposto segreti a un tasso circa doppio rispetto alla baseline umana: circa il 3,2% rispetto all'1,5% dei commit scritti da umani. I test di Veracode su oltre 100 LLM hanno mostrato che il codice generato dall'AI contiene 2,74 volte più vulnerabilità rispetto al codice scritto da umani. Una società di forensica che ha valutato dozzine di applicazioni costruite con AI tra gennaio e aprile 2026 ha rilevato che il 54% dei codebase presentava vulnerabilità di SQL injection e il 91% non aveva alcun logging di sicurezza significativo.

Non sono casi limite. Questo è il risultato mediano quando i team distribuiscono codice generato dall'AI senza una revisione adeguata.

Perché questo è importante per il tuo team adesso

La velocità con cui Codex viene spinto nei workflow enterprise è la vera notizia. Non si tratta più solo di sviluppatori singoli che usano l'autocompletamento. OpenAI sta collaborando con le principali società di consulenza per distribuire Codex in intere organizzazioni di ingegneria. Hanno lanciato plugin enterprise, integrazioni CI/CD e un browser in-app per i server di sviluppo locali. Codex ora può leggere l'output del tuo terminale mentre lavora.

È una superficie d'attacco considerevole. Dal nostro lavoro di penetration testing con studi di gaming e piattaforme di viaggi, continuiamo a vedere lo stesso schema: più velocemente viene distribuito il codice, più creative diventano le vulnerabilità. Non sono sempre le cose ovvie. Sono ruoli IAM eccessivamente ampi nel Terraform generato, token hardcoded in file .env che vengono committati perché nessuno ha revisionato lo scaffold iniziale dell'AI, o endpoint API senza rate limiting perché il modello non ha pensato di aggiungerlo.

Nei nostri progetti nativi iOS e Android, abbiamo visto assistenti AI suggerire codice di rete che torna silenziosamente a HTTP quando un certificato fallisce. In un'app sanitaria che gestisce dati dei pazienti, questo tipo di problema non è solo un bug. È un incidente di conformità. Quando costruiamo app mobile per settori regolamentati, trattiamo ogni riga di codice generato allo stesso modo in cui trattiamo il codice di un nuovo sviluppatore junior: viene revisionato, viene testato e non viene distribuito finché qualcuno che conosce il dominio non ha dato il via libera.

Cosa dovresti fare concretamente

Ecco la versione pratica, basata su ciò che abbiamo implementato nei nostri progetti:

Aggiungi oggi stesso un gate di sicurezza per il codice generato dall'AI. Se non hai pre-commit hook che eseguono secret scanning e SAST di base, sei già indietro. Strumenti come Gitleaks e l'edizione open-source di Semgrep sono gratuiti e richiedono meno di un'ora per essere configurati. Questo solo cambiamento intercetta la categoria più pericolosa di errori del coding AI: le credenziali esposte.

Smetti di trattare l'output dell'AI come input affidabile. L'OWASP LLM Top 10 è esplicito su questo. L'output del modello deve essere validato e sanificato nello stesso modo in cui tratteresti l'input di un utente da un form. Se il tuo assistente AI genera una query sul database, deve essere parametrizzata. Se genera un endpoint API, necessita di autenticazione. Se scrive infrastructure-as-code, qualcuno deve verificare che i permessi non siano troppo aperti. Quando configuriamo la sicurezza cloud e la protezione DDoS per i clienti, troviamo regolarmente che gli script infrastrutturali generati dall'AI impostano permessi eccessivamente permissivi come default. Secondo i dati sulle minacce 2026 di CrowdStrike, il 41% del codice backend generato dall'AI include permessi eccessivamente ampi.

Tieni traccia della percentuale del tuo codebase generata dall'AI. Non puoi delimitare i tuoi test di sicurezza se non sai quanto del tuo codice proviene da un modello. Questo è particolarmente importante per i team soggetti a SOC 2, GDPR o HIPAA, dove le audit trail contano e «l'ha scritto un'AI» non soddisfa i requisiti di conformità.

Non saltare le cose noiose solo perché l'AI le ha rese veloci. La code review esiste per un motivo. Il codice generato dall'AI che compila e supera il lint può comunque fare la cosa sbagliata. L'abbiamo visto. Il codice sembra pulito, i test passano, e poi un pen tester trova un percorso di privilege escalation il primo giorno.

Il quadro generale

Non credo che gli strumenti di coding AI spariranno. E non dovrebbero. I guadagni di produttività sono reali. Ma siamo in quella familiare fase in cui l'adozione sta superando la sicurezza, e le organizzazioni che costruiscono protezioni adesso saranno in una posizione molto migliore rispetto a quelle che si affrannano dopo la loro prima violazione assistita dall'AI.

Il mercato assicurativo se ne sta già accorgendo. Le compagnie assicurative stanno iniziando a limitare i risarcimenti per le perdite cyber legate all'uso dell'AI. Se la tua copertura diventa più costosa o più limitata perché il tuo team ha distribuito codice AI non revisionato, è un problema di business, non solo tecnico.

Dalla nostra esperienza combinata di oltre 30 anni nel gaming, nel travel e nel software enterprise, lo schema è sempre lo stesso: ogni grande cambiamento tecnologico, che si trattasse del cloud, dei container o delle API, ha attraversato una fase in cui le capacità hanno superato la sicurezza. I team che ne sono usciti indenni erano quelli che trattavano la sicurezza come parte dell'adozione, non come qualcosa da aggiungere dopo il primo incidente.

Gli agenti AI per il coding non fanno eccezione. Usali. Ma controlla l'output.

Se il tuo team sta distribuendo codice generato dall'AI e non sei sicuro di quale sia la tua reale postura di sicurezza, parliamone.