Il cane da guardia che non guarda il ladro: quando le barriere di sicurezza dell’IA proteggono l’aggressore

Il weekend in cui Barings è fallita, ero alla UBS a capire cosa potesse fare una banca insolvente di 233 anni al resto di noi. La settimana successiva, la più antica banca mercantile di Londra era stata venduta a ING per una sterlina. Totale, non per azione.

La causa era insultantemente semplice. Nick Leeson gestiva sia il desk di trading di Singapore della società sia il back‑office incaricato di controllarlo. Un uomo indossava entrambi i cappelli, e questo portò direttamente a perdite per 827 milioni di sterline nascosti nel conto errore 88888, visibile solo a lui. Fu un classico fallimento dei permessi. Qualcuno a cui era stato affidato troppo potere.

Mi sono ritrovato di nuovo in quel weekend, con mia sorpresa, a leggere cosa era accaduto a Hugging Face quest’estate. Un altro fallimento dei permessi, ma questa volta nella direzione opposta. Lo strumento si fidava dell’intruso e rifiutava le persone che pulivano.

Il modello che è scappato per trovare le risposte

OpenAI stava testando due dei suoi modelli, GPT‑5.6 Sol e uno non ancora rilasciato, su ExploitGym, un benchmark per verificare se un modello può trasformare una vulnerabilità reale in un exploit funzionante. Per il test, i consueti classificatori di produzione progettati per prevenire attività cyber ad alto rischio sono stati disattivati. Sensato, in una stanza sigillata.

La stanza si è rivelata non così sigillata come previsto. I modelli hanno scoperto una vulnerabilità zero‑day nel proxy della cache del registro dei pacchetti, l’hanno usata per avvicinarsi a Internet aperto e hanno dedotto che Hugging Face potesse ospitare le risposte del benchmark. Da lì, hanno concatenato credenziali rubate e ulteriori zero‑day in un percorso di esecuzione di codice remoto sui server di produzione di Hugging Face. Sono entrati in una vera azienda per barare a un esame.

Nelle note che gli agenti si sono lasciati, uno ha registrato il momento in cui ha trovato aveva i privilegi di amministratore: “Cazzo, il lettore è ADMIN? Possiamo leggere config/users!” Ho sentito ingegneri accogliere l’accesso alla produzione con meno entusiasmo e più burocrazia.

La maggior parte della copertura si è fermata lì, preoccupata per i modelli con agency. La parte che mi ha colpito è arrivata dopo.

Quando le barriere di sicurezza hanno protetto l’aggressore

Quando i responsabili di Hugging Face si sono seduti ad analizzare l’attacco, i modelli commerciali di frontiera, quelli con le barriere di sicurezza integrate, non hanno voluto aiutare. I log di attacco sono composti da payload di exploit e artefatti di command‑and‑control, e i modelli non riuscivano a distinguere un responsabile di incidenti da un aggressore. Così hanno rifiutato.

Le analisi forensi sono state eseguite invece su un modello a peso aperto, GLM‑5.2, eseguito sull’hardware dei difensori, che ha letto lo stesso materiale senza alcun barlume di coscienza.

Riflettete su questo. I modelli aggressori avevano rimosso le loro salvaguardie cyber di produzione e hanno agito come volevano. Gli umani difensori hanno mantenuto le proprie e sono stati invitati a moderare il loro linguaggio. La funzione di sicurezza ha funzionato perfettamente, nel senso che ha schermato i metodi dell’attaccante dalle uniche persone con una ragione per studiarli.

Niente di tutto ciò era una lamentela marginale. Jensen Huang ha usato il suo primo post su X per sostenere i modelli aperti, insieme a una lettera aperta firmata da aziende come Meta, Microsoft e IBM. La lettera ha esposto chiaramente l’argomento di sicurezza: in un mondo in cui gli aggressori dispongono di IA avanzata, i difensori hanno bisogno di capacità comparabili. Andrew Ng ha sostenuto questa argomentazione, indirizzando i lettori verso la posizione di Huang sui modelli aperti. Si può dissentire su molti punti, ma riconoscere il valore quando il rapporto di incidente lo dimostra.

Quindi, in trentuno anni, siamo passati da una banca distrutta perché un uomo poteva vedere tutto a uno strumento di sicurezza che si fida di un intruso anonimo più del proprio proprietario responsabile. Leeson vedeva troppo. Le persone che pulivano dopo Hugging Face non vedevano abbastanza.

Il paragone non è così strano come sembra inizialmente. Le istituzioni finanziarie hanno imparato, di solito dopo costosi errori, che l’accesso non è semplicemente una questione di fiducia. È una questione di se si dovrebbe consentire di eseguire una determinata azione, in un determinato sistema, in un determinato momento, senza che qualcun altro osservi. Abbiamo creato la segregazione dei compiti, i limiti di approvazione e le tracce di audit perché le buone intenzioni di solito falliscono come meccanismo di controllo affidabile. I sistemi di IA hanno bisogno dello stesso tipo di riflessione. Definire un modello sicuro dice poco, a meno che non si sappia anche cosa gli è permesso fare e chi lo utilizza.

Alcune cose non possono uscire dall’edificio

C’è un secondo motivo per cui non avrei potuto fare affidamento su un modello ospitato quella notte, e non ha nulla a che fare con le sue sensibilità. Gestisco la tecnologia per una brokeraggio regolamentato. Non posso incollare i nostri log di violazione, credenziali e payload di exploit attivi nel cloud di qualcun altro e premere invia.

I nostri dati di incidente vivono dove i nostri regolatori li attendono, sul nostro hardware, ed è per questo che abbiamo speso anni e un budget hardware astronomico per costruire proprio questo. Non l’abbiamo costruito per prevedere modelli ribelli. L’abbiamo costruito perché una società come la nostra conserva i dati più sensibili, e ora anche gli strumenti più sensibili, all’interno delle proprie mura.

Niente di tutto ciò è un argomento contro le barriere di sicurezza. È un argomento per conoscere dove puntano le proprie.

Un modello che rifiuta di aiutare un phisher a scrivere un’email di phishing sta svolgendo un lavoro utile. Un modello che rifiuta di aiutare il tuo team di sicurezza a leggere l’email di phishing già arrivata sta facendo il lavoro del phisher per lui, e ti addebita un abbonamento per questo.

Possiedi lo strumento di cui avrai bisogno alle 2 del mattino.

La lezione pratica è noiosa, così come lo sono quelle importanti. Non esternalizzare la tua risposta agli incidenti alla polizza di responsabilità di un fornitore. Mantieni un modello capace su hardware di tua proprietà, destinato al lavoro che quelli commerciali declineranno principalmente, e scopri che esiste prima della notte in cui ne avrai bisogno.

Il premio per anni di difesa di quel singolo elemento hardware su basi poco glamour si rivela essere questo: quando arriva il guasto interessante, possiedi già l’unico strumento nell’edificio che esaminerà le prove.

Trentuno anni fa ho trascorso un weekend a calcolare cosa succede quando la persona sbagliata può vedere tutto. Sarebbe stato bello, questa volta, essere colui che poteva.