Il tuo modello è diventato più intelligente. Il tuo codice non è diventato più sicuro.

La capacità si accumula. La sicurezza è ferma.

Partiamo da ciò che è davvero notevole, perché l'argomento non tiene se finge che i modelli siano scarsi.

Su FrontierBench v0.1, Claude Opus 5 segna 43,3 % a sforzo massimo, contro 18,7 % di Opus 4.8, 33,7 % di Fable 5 e 37,5 % di GPT-5.6 Sol. Tra due versioni di Opus il punteggio è più che raddoppiato. Su SWE-bench Verified, Fable 5 sta intorno al 95 %, e intorno all'80 % su SWE-bench Pro, il set difficile. Quello che un agente non sapeva fare diciotto mesi fa, oggi probabilmente lo fa.

Ora metti la curva della sicurezza sullo stesso asse. Diverse misurazioni indipendenti, accademiche e industriali, disegnano la stessa forma: correttezza sintattica sopra il 95 %, successo sui compiti negli ottanta e novanta, e la quota di codice generato che supera un controllo di sicurezza bloccata a metà scala, più o meno dove stava due anni fa. Le due linee divergono.

“

Ogni generazione di modello ti compra capacità. Nessuna generazione di modello ti ha comprato sicurezza.

Il motivo non ha niente di misterioso appena guardi come vengono addestrati questi modelli. La correttezza funzionale ha un segnale pulito: i test passano o non passano, il benchmark sale o non sale. Quello si ottimizza, con discesa del gradiente e una classifica pubblica. La sicurezza non ha un equivalente. È una proprietà non funzionale, costosa da etichettare, in cui l'assenza di vulnerabilità è indistinguibile dall'assenza di controllo, e il cui fallimento emerge mesi dopo, in un incidente che nessuno collega all'addestramento. Qualunque sia la pressione di ottimizzazione, non punta lì.

C'è una seconda ragione, più sottile, visibile nei dati di addestramento. Alcune classi di vulnerabilità si portano dietro decenni di fix documentati e ripetuti all'infinito in codice pubblico: SQL injection, crittografia debole, path traversal. I modelli le gestiscono relativamente bene, perché il pattern sicuro è anche il pattern statisticamente dominante. Le classi che richiedono di conoscere il runtime, il sistema operativo, il modello dei tenant o la regola di business non hanno alcun corpus di quel tipo. Non sono sottorappresentate nei dati: sono assenti.

Lo stato generale del problema lo abbiamo trattato in il codice generato dall'IA è sicuro?. Questo articolo affronta la domanda più stretta e più azionabile: dato quello stato, cambiare modello o cambiare prompt serve a qualcosa?

Perché cambiare modello non è un controllo di sicurezza

Un modello più recente aiuta un po', e non dove la gente immagina.

Quello che migliora con un salto di versione è la capacità di produrre codice che funziona, e la capacità di ragionare sulla sicurezza quando glielo chiedi direttamente. Su questo secondo punto conviene fermarsi, perché è lì che il meccanismo del guasto diventa visibile. I modelli individuano spesso la misura difensiva corretta quando la poni come domanda. Poi scrivono il codice finale e la omettono. Il divario non è di conoscenza, è di esecuzione. Il modello non è in dubbio sul fatto che una query vada parametrizzata; sta ottimizzando, nel momento della generazione, per ciò che somiglia a un compito concluso.

Questa distinzione ha conseguenze commerciali dirette, perché prevede quali acquisti ti deluderanno. Comprare un modello più intelligente per abbassare la densità di vulnerabilità significa puntare sulla variabile sbagliata. Otterrai più codice funzionante all'ora, quindi più codice all'ora, quindi più di quello che è il tuo tasso di vulnerabilità all'ora. Se il tasso è piatto e il volume triplica, la tua esposizione assoluta triplica. Capacità senza un controllo corrispondente è portata, e la portata non è sicurezza.

La scelta del modello ha un effetto reale, su un solo asse: quanto carico di verifica resta a te. Un modello che azzecca le classi di injection nella maggior parte dei casi te ne lascia meno da recuperare. È un guadagno di efficienza autentico. Non è un controllo, perché è probabilistico, non auditato, e cambia in silenzio a ogni nuovo checkpoint pubblicato dal fornitore.

Perché nemmeno dire al modello di essere sicuro è un controllo

Questa è la parte che la maggior parte dei contenuti dei vendor salta, compresa, a essere onesti, la versione pigra del nostro stesso discorso. Se hai letto in giro che basta mettere istruzioni di sicurezza nel contesto, i dati non lo sostengono.

La misurazione più netta a oggi si intitola "An Empirical Evaluation of LLM-Generated Code Security Across Prompting Methods", di Mohammed Kharma, Ahmed Sabbah, Mohammad Alkhanafseh, Mohammad Hammoudeh e David Mohaisen, depositata su arXiv il 22 maggio 2026. Cinque LLM, quattro linguaggi (Java, C++, C e Python), diversi metodi di prompt engineering, incluso uno costruito appositamente per favorire la tesi della sicurezza: una catena di pensiero zero-shot attenta alle debolezze, che arricchisce il prompt di contesto di sicurezza a partire da mappature CWE per guidare il ragionamento del modello.

Il risultato, sostenuto da test del chi quadrato, sta in una frase dell'abstract: nessuna riduzione statisticamente significativa nella frequenza né nella densità delle vulnerabilità, con nessun metodo di prompt. Quello che quelle strategie cambiano è la composizione delle categorie di CWE, con un effetto che varia col linguaggio. Detto altrimenti, il prompt attento alla sicurezza ridistribuisce le carte delle debolezze che ottieni. Non riduce quante ne ottieni.

Il risultato gemello è probabilmente ancora più imbarazzante per la teoria del prompt come controllo. "Minimal Prompt Perturbations Lead to Code Vulnerabilities: Prompt Fragility and Hidden-State Signals in Coding LLMs", arXiv, 29 maggio 2026, mostra che modifiche minime e del tutto innocue di un prompt, aggiungere un commento, riformulare un'istruzione, inserire testo inoffensivo, riportano in modo affidabile i modelli di codice verso generazione vulnerabile. Non jailbreak avversari. Ritocchi ordinari, del tipo che capita cento volte al giorno in una sessione vera.

Lette insieme, queste due misurazioni impongono un vincolo di progettazione. Non puoi mettere la tua postura di sicurezza nello stesso canale della cosa che stai provando a vincolare. Se la policy vive nel prompt, compete con il compito, con le convenzioni del repository, con il file che l'agente ha appena letto e con quello che un contributor ha scritto in un file Markdown. Se la policy vive in una barriera che valuta l'azione, non compete con niente.

Cosa misurano i benchmark e cosa non possono misurare

Prima di trarre conclusioni da numeri di benchmark conviene sapere di cosa sono fatti, perché la lettura onesta è più stretta dei titoli.

I benchmark accademici seri sono buoni e stanno migliorando. CWEval propone un benchmark di codice multilingue e critico per la sicurezza che copre 31 tipi di CWE su cinque linguaggi, e il suo contributo è la valutazione orientata ai risultati: giudica funzionalità e sicurezza insieme invece di fare pattern matching. RealSec-bench è costruito su repository Java reali ad alto rischio, 105 istanze su 19 tipi di CWE, un allontanamento deliberato dagli snippet sintetici. SecureAgentBench va oltre e valuta la generazione di codice sicuro in scenari di vulnerabilità realistici anziché su prompt isolati.

Tutti condividono tre limiti strutturali che nessuna copertura CWE aggiuntiva risolve.

Niente di tutto questo è un argomento contro i benchmark. È un argomento contro il prendere un tasso di superamento per un modello di rischio. Un modello può guidare tutte le tabelle della sezione precedente e restare la causa immediata del tuo prossimo incidente, perché il tuo prossimo incidente sarà probabilmente nella terza colonna di quella griglia.

I tre guasti che un salto di versione non tocca

Concretamente, ecco cosa resta esattamente rotto come prima dopo essere passato al modello più recente e meglio classificato che esista.

La logica di business, che non ha né benchmark né firma

Le classi di vulnerabilità ricche di fix pubblici sono quelle che i modelli gestiscono meglio. Le tue regole di business, al contrario, non hanno un solo fix pubblico, perché esistono solo nella tua codebase e, spesso, solo nella testa di chi le ha specificate. Un agente capace di scrivere una query parametrizzata impeccabile lascerà volentieri una quantità diventare negativa se niente nel repository gli ha detto che le quantità sono positive. È il guasto che consideriamo strutturalmente fuori portata dei modelli migliori, e lo abbiamo documentato in le falle di logica di business nel codice generato dall'IA.

Le azioni dell'agente, che sono una superficie d'attacco a parte

Nel momento in cui l'agente può eseguire comandi, la domanda di sicurezza smette di essere solo "questo codice è corretto" e diventa "di chi sono le istruzioni che sta seguendo". File del repository come AGENTS.md e CLAUDE.md vengono caricati come policy di progetto fidata, il che li rende un canale di pilotaggio per chiunque possa fare commit. Abbiamo descritto quel meccanismo e gli incidenti con nome del 2026 in instruction file injection. Un modello più capace peggiora la cosa invece di migliorarla, perché esegue il piano ostile con più competenza.

Le dipendenze che sceglie

I modelli continuano a inventare nomi di pacchetti, e gli attaccanti continuano a preregistrarli. Un modello migliore allucina meno spesso, il che riduce la frequenza senza cambiare la forma del rischio, e basta una allucinazione accettata. Vedi che cos'è lo slopsquatting.

Va aggiunto un quarto punto, anche se non riguarda la qualità del codice, perché è la prova più chiara che la capacità taglia da entrambi i lati. La safety card di Anthropic per Opus 5 riporta che il modello ha compromesso con successo reti aziendali in otto test governativi su dieci. Intorno a Fable 5, ricercatori di Amazon hanno trovato il modo di fargli produrre codice dimostrativo di exploit per una vulnerabilità software, cosa che ha portato Anthropic a ridistribuire il modello con misure di sicurezza rafforzate il 30 giugno 2026, e il Fable 5 pubblico ora instrada verso un altro modello i rilevamenti di uso improprio cyber, biologico, chimico e di distillazione. Separatamente, segnalazioni della comunità descrivono il classificatore di sicurezza aggirato in Claude Code inquadrando una richiesta vietata come domanda laterale /btw, sfruttando il divario tra la logica di instradamento e il contesto principale della sessione.

Ognuno di questi punti difende la stessa cosa: la frontiera avanza da entrambi i lati dello steccato nello stesso momento. Nessuno difende il restare su un modello vecchio. Tutti difendono che la barriera stia fuori dal modello.

Salto di versione contro enforcement, fianco a fianco

La riga che pesa di più in una decisione d'acquisto è la seconda. Piatto è brutto, ma instabile è peggio, perché instabile significa che non riesci nemmeno a misurare la tua postura. Se un ritocco innocuo di un prompt cambia le proprietà di sicurezza dell'output, allora qualunque numero produci sulla qualità del tuo codice generato è la fotografia di un sistema che domani sarà diverso per ragioni che nessuno ha registrato.

Cosa funziona davvero: imporre invece di istruire

Accetta i due risultati di ricerca e il progetto viene fuori quasi da sé. Se l'istruzione non è affidabile né stabile, allora il controllo deve essere una cosa che agisce, nel momento dell'azione, e che può rifiutare. In pratica sono tre componenti, e vale la pena essere precisi su chi fa cosa, perché la tentazione è sostenere che il primo faccia tutto.

Le regole nel contesto alzano il pavimento. Non lo fissano. Mettere le regole della tua organizzazione e lo stato reale del repository nel contesto del modello migliora davvero la prima bozza, e mette la tua policy davanti a quello che il repository sostiene. Ma alla luce dei dati sopra, il contesto da solo è un miglioramento probabilistico, non una garanzia. Chi ti dice il contrario sta vendendo oltre quello che dice la ricerca.

Gli hook sono la parte deterministica. Un hook valuta una chiamata a tool prima che venga eseguita. Leggere un file di credenziali, mandare un dump dell'ambiente in curl, lanciare una migrazione distruttiva, invocare un tool la cui descrizione è cambiata da ieri: sono eventi discreti e ispezionabili, e una barriera su di essi scatta o non scatta. Non si fa convincere da un prompt riformulato. È tutta la ragione della sua presenza nel progetto.

I finding nel ciclo eliminano l'indovinello. L'agente ha accesso live a quello che gli scanner hanno trovato su codice, dipendenze, secret, infrastruttura e pipeline, quindi una modifica proposta viene ragionata contro lo stato reale del repository e non contro un'ipotesi. È anche questo che gli permette di notare problemi di secondo ordine, per esempio che la pipeline che gli hanno appena chiesto di modificare gira su eventi di fork con permessi di scrittura.

Il riassunto onesto della nostra posizione: il primo componente fa comportare meglio il modello la maggior parte delle volte, il secondo rende impossibile un insieme preciso di esiti, e il terzo rende accurati i primi due. Solo il secondo è un controllo in senso stretto. Preferiamo dirlo chiaramente piuttosto che lasciar intendere che un prompt sia una garanzia, perché due lavori sostengono ormai il contrario.

E il corollario per la tua roadmap: questo problema non si risolve aspettando. Qualunque sia il punteggio della prossima release, mettiti in conto una curva di sicurezza piatta e un volume di codice in aumento.

Domande frequenti

Un modello più recente scrive codice più sicuro?

Appena, e non abbastanza da cambiare i tuoi controlli. La correttezza funzionale migliora molto tra generazioni mentre il tasso di superamento sulla sicurezza resta quasi piatto. Un modello più recente tende a gestire meglio le classi ben documentate come la SQL injection o la crittografia debole, perché il pattern sicuro è anche il pattern comune nei suoi dati di addestramento, e non migliora sulle classi che richiedono di conoscere il tuo runtime o le tue regole di business. Ottieni più codice, con più o meno lo stesso tasso di difetti.

Quale modello scrive il codice più sicuro?

I confronti pubblicati producono una classifica, e quella classifica si muove a ogni release, che è esattamente il motivo per non costruirci sopra un programma di sicurezza. La lettura utile di quegli studi è l'aggregato: la distanza tra il modello migliore e la media è molto minore della distanza tra qualunque modello e "abbastanza sicuro da andare in produzione senza verifica". Scegli un modello per capacità e costo, poi mettici un controllo davanti.

Serve dire al modello di scrivere codice sicuro?

Non in modo misurabile, alla luce dei dati disponibili. La valutazione di maggio 2026 di Kharma e coautori ha testato più metodi di prompt su cinque LLM e quattro linguaggi, inclusa una catena di pensiero arricchita di mappature CWE, e non ha trovato riduzioni statisticamente significative nella frequenza né nella densità delle vulnerabilità. Il prompt ha cambiato quali categorie di CWE comparivano, non quante vulnerabilità c'erano.

Se il prompt non funziona, a cosa servono le regole nel contesto dell'agente?

A due cose che una teoria solo-prompt sottovaluta. Migliorano la prima bozza, che è un guadagno di efficienza reale anche se probabilistico, e mettono la policy della tua organizzazione nel contesto del modello davanti a quello che sostiene un file di repository non revisionato. Quello che non possono fare è garantire un esito. Per questo l'hook esiste accanto a loro, e per questo non presentiamo il contesto come la risposta intera.

Ci si può fidare dei benchmark di sicurezza?

Quelli accademici sono rigorosi e stanno migliorando. CWEval copre 31 tipi di CWE su cinque linguaggi con valutazione orientata ai risultati, RealSec-bench è costruito su repository Java reali ad alto rischio, e SecureAgentBench punta a scenari di vulnerabilità realistici. I loro limiti sono strutturali più che metodologici: valutano una generazione singola e non sessioni lunghe di agente, possono testare solo debolezze con una classe nominata, e non dicono niente sulle azioni dell'agente in contrapposizione al suo codice.

Conviene restare su un modello vecchio per motivi di sicurezza?

No. I modelli vecchi non sono più sicuri, sono solo meno capaci, quindi ottieni lo stesso tasso di difetti con meno produzione. I rischi propri dei modelli di frontiera, un agente che esegue un piano ostile con competenza, si affrontano vincolando le azioni, non mettendo un tetto alla capacità.

Vuol dire che il codice generato dall'IA non si può portare in produzione in sicurezza?

Si può, a condizione che verifica ed enforcement facciano parte del ciclo e non di una fase successiva. Il guasto non è "l'IA scrive codice cattivo", è "l'IA scrive codice più in fretta della review che doveva controllarlo". Per la versione ampia di quell'argomento, vedi sicurezza degli agenti di codice IA.

Quale singola metrica seguire invece del punteggio di sicurezza di un modello?

Segui la quota di azioni insicure che sono state rifiutate anziché revisionate. Un tasso di superamento ti parla del checkpoint di un fornitore. Un tasso di rifiuto ti parla del tuo controllo, si misura nei tuoi log, e a differenza di un punteggio di benchmark non si azzera quando qualcuno pubblica un modello nuovo.