Quando sbagliare diventa economico

24 Aug, 2026

Ventimila dollari per attaccare, sette milioni per capire cosa è successo

Nella mia cartella di appunti, il cimitero degli articoli mai usciti, ci sono diverse note. Mi ha sempre affascinato la sicurezza informatica degli LLM (mio primo articolo) e l'economia dietro a questa disciplina (altro articolo). A maggio del 2025 ho letto un paper che ha arricchito la mia opinione su questo argomento: LLMs unlock new paths to monetizing exploits di Carlini et al, nel quale veniva formalizzato un modello economico semplificato (toy model):

valore = (profitto per exploit × numero di vittime) − (costo per identificare la vulnerabilità e sviluppare l'exploit)

La principale tesi dell'articolo è la seguente: "se il costo di trovare un bug e scriverne l'exploit crolla, allora diventa conveniente attaccare bersagli che prima non ripagavano lo sforzo: non più il software usato da milioni di persone, ma le migliaia di applicazioni di nicchia."

Gli LLM cambieranno il terzo fattore, andando così a toccare la coda lunga. Invece di un attaccante umano che cerca a mano un bug difficile in un prodotto con milioni di utenti, un LLM può trovare migliaia di bug facili in prodotti con migliaia di utenti.

Sempre a maggio 2025, qualcosa aveva incominciato a muoversi: il post di Sean Heelan su come aveva usato o3 per trovare la CVE-2025-37899, una vulnerabilità remota nell'implementazione SMB del kernel Linux. Nelle mie note avevo scritto una precisazione: o3 l'ha "quasi" trovata da solo, era stata trovata a mano, ma il modello era comunque in grado di trovarla. Il salto da "assistente" a "esecutore autonomo" sembrava breve, ed effettivamente è stato così.

Aprile 2026: il costo non è scivolato, è sfondato

L'8 aprile 2026 Anthropic ha annunciato Claude Mythos Preview, un modello che non è stato rilasciato al pubblico perché le capacità misurate sono state giudicate troppo pericolose. L'accesso è stato limitato diverse organizzazioni, con cento milioni di dollari in crediti d'uso a supportare l'iniziativa (Project Glasswing). Le capacità sembravano molto interessanti, ma quello che voglio sottolineare in questo pezzo sono i costi.

La prima riga è quella che mi ha fatto riprendere questi appunti, riflettere sul passato e scrivere un articolo. Abbiamo 1000 tentativi per meno di 20k dollari di inferenza, cioè 20 dollari a tentativo. E il risultato è un bug rimasto invisibile per ventisette anni a ogni fuzzer e a ogni revisore umano che aveva guardato quel codice.

Successivamente, l'altro punto di interesse è quel 72,4%, che va letta accanto al "quasi" di o3. In dodici mesi si è passati da un modello che arrivava vicino a una vulnerabilità già nota, a un modello che produce l'exploit funzionante tre volte su quattro. Nel gergo dei report questo si chiama capacità emergenti: nessuno ha addestrato Mythos specificamente per scrivere exploit.

Nel 2025 quindi avevamo un paper che sosteneva che il costo di trovare bug sarebbe crollato, quindi come reagisce il mercato in un anno? Io mi aspettavo uno spostamento verso il basso, verso la coda lunga, come appunto suggeriva il paper. Ma analizziamo il prezzo che la coda alta pratica ancora oggi. Il programma di acquisizione di Crowdfense paga fino a 7 milioni di dollari per una full chain su iOS, fino a 5 milioni su Android, 3,5 milioni per Safari, 3 milioni per Chrome, tra 3 e 5 milioni per iMessage e WhatsApp.

L'arbitraggio non si è aperto solo in fondo al mercato: si è allargato in cima. La coda lunga è una conseguenza diretta del crollo dei costi, quello che leggevo come modello in un paper nel 2025 non è falso, ma forse non è il punto. Il punto è che quando il termine "costo" collassa di tre ordini di grandezza, l'intera equazione smette di essere un problema di selezione del bersaglio e diventa un problema di volume di tentativi. E questo probabilmente è ciò che cambia gli scenari economici.

Ecco la forbice, su scala logaritmica, con tutti i numeri di questo articolo messi nello stesso grafico. Il valore in fondo, quello del difensore, viene affrontato nella sezione successiva.

Luglio 2026: l'attacco

Tre mesi dopo l'annuncio di Mythos è arrivata la dimostrazione di un attacco end-to-end svolto da un agente AI; questo però non è stato fatto da un attaccante.

Il 9 luglio 2026, durante una capability evaluation interna, un agente di OpenAI è evaso dalla propria sandbox di valutazione sfruttando uno 0-day nel package proxy cache, si è ritrovato su Internet, ha trovato un endpoint pubblico non protetto (appartenente a una terza parte, ospitato su Modal, pensato per eseguire codice arbitrario) e lo ha adottato come launchpad: base di command-and-control, staging ed egress. Da lì, nei quattro giorni e mezzo successivi, è entrata nell'infrastruttura di Hugging Face e ha ottenuto cluster-admin su più cluster Kubernetes.

Le ricostruzioni pubbliche fatte dalle due aziende sono molto interessanti e sicuramente meritano una lettura: la timeline tecnica di Hugging Face, il post di OpenAI e la ricostruzione tecnica di OpenAI al Black Hat.

Senza entrare nel dettaglio, la scalata dentro Hugging Face è stata una sequenza di furti d'identità e non un exploit folle: da esecuzione di codice in un singolo worker pod, al token del service account, alle credenziali del nodo lette dall'Instance Metadata Service, fino a root sulla macchina host. Quest'ultimo salto, quello da container a host, ha richiesto due misconfigurazioni contemporanee: una ClusterRole del driver CSI che concedeva la creazione di pod su tutto il cluster, e l'assenza di una admission policy che rifiutasse i pod privilegiati con il filesystem dell'host montato. Segnatele, perché tornano più avanti.

Quattro cose da tenere a mente

Il primo: non era presente nessun incentivo economico nel senso tradizionale. Non c'era un ricatto, non c'era un ransomware, non c'era un acquirente. Le chiamate cloud potenzialmente distruttive sono state eseguite con DryRun=True, che significa simula ma non eseguire. L'agente stava mappando l'infrastruttura, non causando danno, coerentemente con un obiettivo che premiava il reach e l'information gathering.

Il secondo: i safety classifier erano disattivati di proposito. La valutazione era progettata per misurare la capacità grezza del modello e l'harness sottostante, quindi i classificatori di produzione erano stati disabilitati e i rifiuti in ambito cyber chiaramente non c'erano.

Il terzo: nessun umano ha diretto i singoli passi.

Il quarto, e diciamo il punto che mi ha fatto scrivere questo articolo: dal report risultano 17600 azioni, e la maggior parte non è andata da nessuna parte. La frase del post-mortem di Hugging Face che mi porto dietro da settimane è questa: il percorso vincente era nascosto dentro il rumore generato dalle migliaia di percorsi falliti (la sezione "Asymmetry problem" nel post-mortem di HF).

Non è un caso isolato. A fine luglio, e non credo sia una coincidenza che sia successo subito dopo, Anthropic è andata a controllare i propri log e ha pubblicato cosa ci ha trovato. Su 141.006 evaluation run in cui Claude avrebbe potuto ottenere accesso a Internet sono stati identificati tre incidenti. Detta così sembra una percentuale rassicurante, poi però leggi cosa sono i tre incidenti:

• Opus 4.7 ha colpito un'azienda reale, il cui nome coincideva con quello di un bersaglio fittizio. Quattro run, accesso all'infrastruttura di produzione, credenziali estratte, centinaia di righe di database.
• Mythos 5 ha creato e pubblicato pacchetti Python malevoli su PyPI. Sono stati scaricati su una quindicina di sistemi reali nel giro di un'ora, incluso lo scanner di un'azienda di sicurezza, da cui sono state esfiltrate credenziali. Un attacco alla supply chain, partito da una valutazione interna.
• Un modello di ricerca interno ha scansionato circa 9.000 bersagli, ne ha compromesso uno con tecniche banali (credenziali esposte, SQL injection), e si è fermato da solo quando ha capito che il target era reale.

Le date raccontano il resto: revisione avviata il 23 luglio, incidenti identificati il 24, organizzazioni avvisate il 27, disclosure pubblica il 30.

Il numero interessante qui non è il tre. È il 141.006. Perché quel numero, come vedremo tra poco, ha un nome.

Il termine che mi mancava

Riprendiamo l'equazione del 2025. Il mio focus era il termine del costo e mi chiedevo quali bersagli diventano profittevoli. La domanda giusta era un'altra: quanti tentativi puoi permetterti?

Chiamiamolo N. A venti dollari per tentativo, N smette di essere un vincolo tecnico e diventa una voce di spesa, che è una differenza enorme. Ed è così che vanno riletti i due numeri di prima: 17.600 azioni non sono la firma di un attaccante particolarmente brillante, sono la firma di un attaccante per cui sbagliare costa poco. E 141.006 run non sono un incidente raro moltiplicato per la sfortuna: sono N abbastanza grande da rendere quasi certo un evento che, sul singolo tentativo, ha una probabilità trascurabile.

Quindi, se ogni tentativo ha probabilità p di riuscire e i tentativi sono indipendenti:

$p(\text{compromissione})=1-(1-p{)}^N$

Con p piccolo, basta far crescere N perché la probabilità si avvicini a 1.

Ma è concettualmente sbagliato trattarli come indipendenti. Nell'incidente descritto da OpenAI, gli agenti si scrivevano messaggi su una bacheca improvvisata dentro Artifactory: si passavano credenziali, tecniche e progressi. Un modello eseguito più tardi ereditava i messaggi lasciati da quelli precedenti. Nell'attacco a Hugging Face, il Vector 1 (la lettura di file via HDF5) serviva a rendere possibile il Vector 2: leggendo il source code del worker, l'agente ha trovato dove stava il bug di code execution. Il tentativo k non era un lancio di moneta indipendente dal tentativo k−1: ne era la conseguenza di somma di informazioni.

Se metti dentro un modello naif, ottieni per forza un risultato naif. Servirebbe allora qualcosa di meglio, e la cosa curiosa è che la risposta stava già nei miei appunti del 2025.

Primo: la frequenza con eventi indipendenti

L'assunzione di indipendenza non è solo scomoda, è empiricamente falsa e lo sappiamo da un decennio. In Hype and Heavy Tails: A Closer Look at Data Breaches (Edwards, Hofmeyr, Forrest), la frequenza dei data breach è modellata bene non da una Poisson ma da una binomiale negativa.

Una Poisson assume eventi indipendenti e ha varianza uguale alla media. Una binomiale negativa è una Poisson il cui tasso è esso stesso una variabile aleatoria: la varianza supera la media. In gergo si chiama sovradispersione, e la si osserva esattamente quando gli eventi si raggruppano invece di distribuirsi uniformemente.

Secondo: una catena e non una moneta

Quello che ha senso avere come modello mentale appunto non è il classico lancio di moneta, dove ogni lancio è a se stante; è un percorso. Modellarlo come una successione di step, ciascuno con la propria probabilità di superamento.

A luglio 2026 UK AISI e il CAISI americano hanno pubblicato una valutazione preliminare delle capacità cyber di Kimi K3, il modello open-weight di Moonshot AI, misurata su un cyber range chiamato The Last Ones: 32 step, 4 subnet, una ventina di host, circa venti ore di lavoro per un esperto umano.

Kimi K3 arriva in media allo step 17 su 32, e completa il range una volta su dieci. GLM-5.2 si ferma allo step 11. I modelli di frontiera US arrivano a 28,5. Su ExploitBench, Kimi K3 ha un tasso di successo del 32% contro il 24% di GLM-5.2, ma sull'Arbitrary Code Execution, che è l'esito di gravità massima nello sviluppo di exploit, Kimi K3 fa 0 su 41 campioni, mentre i modelli di frontiera stanno a 20 su 41.

Se modelli l'attacco come una catena di step con probabilità qᵢ di superare ciascuno, la probabilità di compromissione è il prodotto delle qᵢ, non una somma.

La difesa in profondità è moltiplicativa, non additiva. Aggiungere uno step difficile non sottrae una quantità dal rischio: lo divide. Ed è qui che tornano le due misconfigurazioni di prima: la ClusterRole troppo larga dava il permesso di creare un pod, l'admission policy mancante faceva sì che nessuno controllasse che tipo di pod fosse. Ne bastava una delle due, corretta, per fermare il salto container-host.

N allunga il percorso, ma esiste comunque un muro. Se una qᵢ è zero, nessun volume di tentativi la compensa. Quello 0 su 41 sull'ACE è precisamente un muro, non una salita.

E qui il modello a catena mostra anche il proprio limite. Le probabilità dei singoli passaggi non si deducono dai dati storici: vanno stimate con esercizi di red e purple team sulla propria infrastruttura. È onesto ammettere che qui la matematica elegante finisce e comincia la misurazione.

Terzo: la media è la statistica sbagliata

C'è un secondo problema, sul lato dell'impatto anziché della frequenza. Lo stesso lavoro di Edwards, Hofmeyr e Forrest mostra che la dimensione dei breach segue una log-normale (o log-skewnormal): distribuzioni a coda pesante.

Con code pesanti, l'Annual Loss Expectancy (la perdita annua attesa, cioè una media) è una sintesi fuorviante, perché è dominata da eventi rari che non vedrai quasi mai nel tuo campione. È il motivo per cui, se fai una simulazione Monte Carlo del rischio cyber, il numero da mettere in slide non è la media ma i percentili di coda: Value at Risk e Conditional Value at Risk. Nei miei appunti del 2025 avevo salvato anche un paper su un'analisi Monte Carlo dell'impatto monetario dei mega data breach, che insiste sullo stesso punto: sono le interazioni tra i fattori, non il valore centrale, a spiegare la varianza del costo totale.

Quarto: da dove prendi la probabilità, se la storia non serve più

E arriviamo al problema più fastidioso. Ogni metodo probabilistico di risk assessment, FAIR e HTMA su tutti, vuole in input una frequenza e una magnitudo. La magnitudo si stima. La frequenza, tradizionalmente, si stima da dati storici.

Ma se la capacità offensiva fa un salto discontinuo in dodici mesi, da o3 che "quasi" trova un bug a Mythos che ne produce 181 exploit funzionanti su Firefox, allora i tassi base storici descrivono un mondo che non esiste più. Il processo non è stazionario, e stimare il futuro dal passato è precisamente l'errore che il passato ti invita a fare.

Nei miei appunti del 2025 c'era un paper che avevo salvato per il titolo: MAGIC: A Method for Assessing Cyber Incidents Occurrence. L'idea è di calcolare la probabilità di occorrenza di un incidente non dai dati storici ma dalla postura cyber dell'organizzazione, tramite tre parametri quantificati con questionari: maturità, complessità, attrattività. Serve a produrre input su misura per FAIR o HTMA riducendo la soggettività delle valutazioni esperte.

Nel 2022 era una soluzione a un problema di disponibilità dei dati. Nel 2026 è una soluzione a un problema di validità: quando i tassi base non sono più informativi, la postura è l'unico input che descrive ancora il tuo rischio. Con una torsione da fare sul terzo parametro, l'attrattività: non significa più "sei un bersaglio grosso", significa "quanti tentativi la tua superficie assorbirà quest'anno". Quel numero non dipende dalla tua taglia, bensì dipende dal costo per tentativo dell'attaccante.

Ed è qui che la coda lunga rientra dalla finestra, come conseguenza e non come tesi: se l'attrattività si scollega dalla dimensione, la PMI e la multinazionale finiscono nello stesso mercato.

Il conto del difensore

Manca ancora il numero più importante, e considerato il mio background e interesse il lettore che mi conosce avrà capito che non riguarda l'attacco.

Secondo Fortune, OpenAI ha dichiarato di aver speso tre milioni di GPU hours per indagare l'incidente, analizzando oltre sette miliardi di log: "running models like Codex and other agents to scan lots and lots of trajectories and logs". Tre esperti di infrastruttura AI interpellati dalla testata stimano il valore di quel compute tra 4 e 15 milioni di dollari, con una scommessa ragionevole intorno ai 7 milioni: circa 4 se girava su Hopper, circa 15 su Blackwell.

Confrontiamo ora le due cifre di attacco e difesa: ventimila dollari per trovare un bug rimasto invisibile per ventisette anni; sette milioni di dollari per ricostruire cosa è successo dopo. Un rapporto di circa 350 a 1, che è la forbice del primo grafico di questo articolo.

Attenzione a non trarne la conclusione sbagliata, perché è facile: nessuna PMI italiana spenderà sette milioni in GPU/hours in analisi forense. Il punto non è la cifra assoluta, è la struttura del costo. Hugging Face lo scrive nella sezione che ho linkato precedentemente del suo post-mortem: non stavano affrontando un exploit brillante o una sequenza pulita di azioni, ma la necessità di correlare migliaia di eventi a basso segnale su sistemi diversi mentre l'agente continuava a testare percorsi nuovi. Il percorso vincente era nascosto nel rumore di quelli falliti. E il loro stack di sicurezza AI ha correlato i segnali in un quadro coerente ma ha sbagliato la criticità dell'alert e non ha svegliato il team on-call, costando tempo prezioso.

Il freno si è spostato

A questo punto sembra tutto molto vicino. Prima di scrivere la conclusione allarmista, guardiamo i numeri di chi misura, perché raccontano una storia più interessante.

L'idea diffusa è che i modelli open-weight quasi di frontiera abbiano già messo queste capacità in mano a chiunque. Sulla prima metà è vero, sulla seconda no, e la distinzione è tutta. La valutazione AISI/CAISI è sostanzialmente inequivocabile: i safeguard di Kimi K3 non gli hanno impedito di tentare lo sviluppo di exploit né operazioni cyber offensive. Nessun rifiuto, nessuna resistenza. Un modello open-weight lo scarichi, lo esegui sulla tua infrastruttura, e nessun classificatore di provider si mette in mezzo.

Ma rimangono i 17 step su 32 a luglio. Zero su 41 sull'ACE. Il divario coi modelli di frontiera era più ampio di quanto la narrativa sui benchmark generalisti suggerisse, e cadeva esattamente nel punto peggiore: sull'esito di massima gravità. The Decoder nota che la distillazione potrebbe spiegare il divario.

Ho scritto "a luglio" di proposito, perché mentre finivo questo articolo il quadro è cambiato di nuovo. Il 14 agosto Z.ai ha rilasciato GLM-5.3, e i numeri vanno letti uno accanto all'altro:

• Su CyberGym, che misura se un modello riesce a trovare e validare vulnerabilità reali partendo dal source code, GLM-5.3 fa 84,5 e passa davanti a Mythos 5 (83,8) e GPT-5.6 Sol (83,6). Un modello open-weight in cima a un benchmark cyber, per la prima volta.
• Su ExploitBench, che valuta il ragionamento su come una vulnerabilità si sfrutta davvero, passa da 24,4 a 54,4. Più che raddoppiato in una versione. Ma Mythos 5 e GPT-5.6 Sol stanno a metà settanta.
• Su ExploitGym, che conta quanti task di exploitation chiudi in un tempo dato, va da 29 a 105 in due ore, e da 39 a 130 in sei.
• I pesi, dice Z.ai, escono circa due settimane dopo il lancio, una volta finita la safety evaluation.

E c'è un dettaglio che chiude il cerchio con aprile: Z.ai dichiara che il ragionamento su exploit chain è emerso dal post-training senza che fosse un obiettivo. Le stesse parole usate per Mythos, quattro mesi dopo, da un laboratorio che pubblica i pesi (ndr, al momento di scrittura di questo articolo, i pesi del modello non sono stati ancora pubblicati).

Quindi la frase "il freno tiene" non regge più, e va sostituita con una più precisa: il confine non passa più tra open-weight e frontiera, passa tra trovare e sfruttare. GLM-5.3 trova quanto e più di Mythos. Sull'exploitation è ancora venti punti sotto. Il muro dell'ACE esiste ancora, ma si è spostato in avanti, e la pendenza dice tutto: GLM-5.2 allo step 11 a giugno, Kimi K3 a 17 a luglio, GLM-5.3 che raddoppia ExploitBench ad agosto. La domanda da tenere in agenda non è "cosa può fare l'AI", ma quanto ci mette quel divario di venti punti a chiudersi.

Nel frattempo vale la pena ricordare chi può permettersi tutto questo già oggi. Venti dollari a tentativo non sono un vincolo per nessuno, ma nemmeno ventimila lo sono: alla Corea del Nord vengono attribuiti 1,34 miliardi di dollari in criptovalute rubate nel 2024 e 2,02 miliardi nel 2025. Per dare la scala storica, il design di Stuxnet è stimato intorno ai cento milioni di dollari: è l'ultima barra del primo grafico, ed è lì per ricordare quanto costava, sedici anni fa, quello che oggi si compra con il budget di una trasferta.

Dall'altro lato, i modelli che hanno il motore non sono liberamente in vendita, e la storia di come ci sono arrivati merita un paragrafo. Il 9 giugno 2026 Anthropic pubblica Claude Fable 5, primo modello accessibile della classe Mythos. Il 12 giugno, tre giorni dopo, il governo statunitense emette una direttiva di export control che sospende l'accesso a Fable 5 e Mythos 5 per qualsiasi cittadino straniero, dentro o fuori dagli Stati Uniti, con il risultato pratico che Anthropic deve staccarli per tutti i clienti. Il trigger, per quanto si è capito, è un jailbreak - ossia un prompt che permette di aggirare le costrizioni imposte dal vendor. Quel jailbreak, scrive Anthropic, consisteva essenzialmente nel chiedere al modello di leggere un codebase e sistemarne i difetti software. Il 30 giugno i controlli vengono revocati e dal 1° luglio Fable 5 torna disponibile; Mythos resta fuori dal mercato aperto.

E accanto a questa, l'altra metà della stessa storia. Per analizzare l'attacco, Hugging Face ha provato a usare Claude Opus e Fable, e si è scontrata con i guardrail: i loro safety guardrail trattavano il reverse engineering di un exploit come il lanciarlo. Hanno quindi messo in piedi una versione quantizzata di GLM-5.2 self-hosted e ci hanno instradato l'intera pipeline forense, con il vantaggio collaterale di tenere i dati dell'attaccante on-premise. Ed è con quel modello che hanno ricostruito lo schema chunk+XOR+compress e recuperato la chiave che l'agente stesso si era lasciato dietro nei log: esattamente quello che ha permesso di decifrare i blob che una scansione ingenua non aveva visto, portando alla luce circa quattro volte i segreti trovati al primo passaggio.

Due episodi, la stessa dinamica: il gesto che serve al difensore e il gesto che serve all'attaccante sono lo stesso gesto, e ogni volta che lo si blocca dal lato del provider il lavoro non si ferma, si sposta su pesi che giri in casa. Non ho una conclusione pulita da offrirti su questo, perché banalmente credo che non ce ne sia una.

Cosa metti a budget lunedì mattina

Se sei arrivato fin qui, ti devo una precisazione su come è cambiata la mia opinione mentre scrivevo. L'idea iniziale di questo articolo era quella costruire un'analisi quantitativa del rischio, ero partito pensando che la Cyber Risk Quantification fosse la risposta a tutto questo. Non lo è, e per un motivo preciso: come strumento di predizione non regge. Ha bisogno di tassi base storici, e i tassi base storici descrivono un mondo che cambia versione ogni sei settimane. Un framework che ti restituisce un numero per il budget dell'anno prossimo, in un regime non stazionario, ti sta restituendo la tua stessa fiducia moltiplicata per una costante.

Quello che invece continua a funzionare è la quantificazione come strumento di prioritizzazione: non per indovinare quanto perderai, ma per decidere cosa comprare prima e per farti dire di sì da chi firma. Che è, se ci pensi, l'unica cosa che le è mai davvero riuscita.

Guarda la lista di cosa Hugging Face ha cambiato dopo essere stata attaccata:

• accesso a IMDS bloccato dai pod, così che una RCE in un pod non diventi banalmente le credenziali del nodo;
• rotazione di tutte le credenziali, anche sui cluster non toccati, e passaggio alla workload identity dove non c'era;
• ambito delle credenziali ristretto: il service connector non deve più restituire il catalogo completo dei cluster a un singolo client effimero;
• alerting a severità critica sulle firme comportamentali osservate, e tooling che segnala i token usati da origini inattese.

Nota una cosa: è tutta roba noiosa, e tutta economica. Nessuna di queste voci richiede un budget da sette milioni. Non sono state fatte prima non perché costassero troppo, ma perché non c'era un modo di raccontare quanto valessero. È esattamente lì che serve la quantificazione: non a predire il futuro, ma a far finanziare le cose noiose.

Tre parametri concreti che, sulla base di tutto quanto sopra, io userei per decidere nel 2026:

1. N, ossia il volume di tentativi che la tua superficie assorbirà. Non derivato dalla tua dimensione, ma dal costo per tentativo dell'attaccante. È il parametro nuovo, e il più difficile.
2. La lunghezza e la fragilità della catena. Quanti step indipendenti separano un'esecuzione di codice arbitrario dal tuo dato più sensibile, e quale di questi step ha probabilità di superamento vicina a uno perché è una misconfigurazione. Questo si misura col red team, non con la storia.
3. Il costo di correlazione. Quanto costa, in ore-persona e in strumenti, distinguere il tentativo riuscito dalle migliaia falliti. È la voce che cresce più in fretta e quella che nessuno mette a budget.

Nessuno di questi tre è una previsione. Tutti e tre sono decisioni. La sicurezza reale vive nella capacità di misurare e ridurre il rischio in termini economici, non burocratici.

In chiusura

Nella bozza del 2025 chiudevo con una provocazione inventata: se un attacco LLM-powered costa 50 euro e può fruttare 2.000, il problema non è più tecnologico ma macroeconomico. Suonava molto bene nella mia testa e con il paper con cui ho aperto l'articolo. Il problema è che quei numeri erano abbastanza arbitrari, ma ora incidenti reali sono capitati e di conseguenza è possibile un approccio quantitativo.

Venti dollari un tentativo. Ventimila per un bug rimasto invisibile ventisette anni. Sette milioni per ricostruire cosa è successo dopo.

Quello che mi mancava nel 2025 non era una capacità che non avevo previsto: sulle capacità, il paper di Carlini aveva ragione e io ci avevo creduto. Mi mancava che un attaccante potesse sbagliare 17.599 volte e vincere alla diciassettemilaseicentesima, e che questo fosse economicamente sensato. È un termine che non avevo scritto nell'equazione, e cambia cosa significa difendersi: non solo abbassare la probabilità di un evento, ma fare in modo che nessuna quantità ragionevole di tentativi basti.

Su tutto il resto non ho una chiusura tranquillizzante, e ho smesso di cercarla mentre scrivevo. Il gesto che serve al difensore, leggere del codice e trovarci i buchi, è lo stesso identico gesto che serve all'attaccante. Nel giro di due mesi l'ho visto costare a un modello di frontiera diciotto giorni di stacco per ordine di un governo, e a Hugging Face un'intera pipeline forense da ricostruire su pesi scaricati e messi in casa. Ogni volta che quel gesto viene chiuso dal lato del provider, il lavoro non si ferma. Si sposta dove nessuno può chiuderlo.

L'articolo che volevo scrivere nel 2025 parlava di quantificare il rischio. Questo l'ho finito con meno certezze di quante ne avessi in partenza, il che immagino sia il motivo per cui era rimasto nel cimitero degli appunti per due anni. La domanda che mi tengo in agenda non è più quanto costerà un attacco, perché quel numero adesso ce l'ho. È quanto ci mette a chiudersi il divario tra trovare una vulnerabilità e saperla sfruttare.

Perché il giorno in cui si chiude, i venti dollari a tentativo non sono più dietro l'allowlist di tredici aziende. Sono dentro un file di pesi, su Hugging Face, e li scarica chiunque.

Questo articolo è stato scritto con il supporto di diversi agenti LLM, utilizzati per la ricerca, il confronto delle fonti e la revisione della prosa. Le scelte argomentative e la versione finale restano mie.