Quattro fallimenti. Quattro livelli. L’architettura stessa è la vulnerabilità.

Un recente episodio del 10 aprile 2026 del podcast Hard Fork del New York Times ha esaminato le implicazioni sulla sicurezza informatica dei sistemi AI avanzati e ha sollevato una domanda che l’industria ha cercato di evitare: cosa succede se la sicurezza informatica non è sottovalutata, ma fondamentalmente mal concepita?

L’episodio è stato trasmesso settimane dopo una serie di incidenti che hanno reso difficile ignorare la risposta. In un solo mese, un agente AI autonomo ha violato la piattaforma AI interna di McKinsey in due ore. Un attacco alla catena di approvvigionamento a una libreria AI open-source ampiamente utilizzata si è propagato alle imprese a valle. I ricercatori hanno dimostrato che il hardware destinato a essere l’ultima linea di difesa può essere violato con componenti facilmente reperibili a un prezzo inferiore a mille dollari. E Anthropic ha rivelato che un modello di frontiera aveva autonomamente trovato migliaia di vulnerabilità zero-day nel codice che l’industria considerava stabile.

Quattro incidenti. Quattro livelli della pila AI: applicazione, orchestrazione, hardware e sistema operativo. Ognuno ha rivelato limitazioni significative nei controlli progettati per proteggerli.

La fine del pensiero perimetrale

La sicurezza informatica tradizionale si basa su un unico presupposto: con controlli sufficienti, monitoraggio e investimenti, i sistemi possono essere protetti. Quel presupposto ha plasmato decenni di architettura, compresi firewall, gestione delle identità, sicurezza degli endpoint e piattaforme SIEM, tutte costruite sull’idea che la visibilità e la gestione stretta equivalgano alla sicurezza.

L’industria sta spostando l’attenzione verso l’architettura Zero Trust, che riflette la crescente consapevolezza che i confini di rete tradizionali non possono più essere considerati attendibili. Tuttavia, anche mentre i modelli di fiducia evolvono, i sistemi AI introducono una sfida diversa: i dati sensibili vengono aggregati, elaborati e condivisi regolarmente attraverso多 livelli di infrastruttura.

Questo approccio aveva senso quando i sistemi erano relativamente centralizzati e i dati rimanevano all’interno di confini chiaramente definiti. Diventa molto meno efficace quando i dati si muovono continuamente attraverso cloud, API, fornitori di terze parti e pipeline AI, mentre gli utenti e le risorse di calcolo sono distribuiti a livello globale. Il perimetro non è più un confine. È una superficie in continua evoluzione, e stiamo ancora applicando un pensiero basato sul controllo a sistemi che non possono realisticamente essere controllati.

Fallimento del livello di applicazione: Lilli di McKinsey

Il 9 marzo 2026, la startup di sicurezza CodeWall ha pubblicato una disclosure che ha evidenziato i rischi che le organizzazioni che distribuiscono AI internamente devono affrontare. .

L’agente offensivo autonomo di CodeWall, senza credenziali, senza conoscenza interna e senza guida umana, ha ottenuto accesso in lettura e scrittura al database di produzione dietro Lilli, la piattaforma AI interna di McKinsey, in meno di due ore. Lilli viene utilizzata da oltre 40.000 dipendenti per lavori di strategia, ricerche sui clienti e analisi dei documenti, generando centinaia di migliaia di prompt al mese.

Il punto di ingresso non era sofisticato. L’agente ha trovato la documentazione dell’API pubblicamente esposta che elencava oltre 200 endpoint, 22 dei quali non richiedevano autenticazione. Le vulnerabilità coinvolte riflettono i rischi evidenziati nel OWASP Top 10 per le applicazioni LLM, in particolare intorno a interfacce esposte, integrazioni non sicure e eccessiva fiducia nei sistemi connessi.

Uno di quegli endpoint conteneva una vulnerabilità di iniezione SQL nascosta nei nomi dei campi JSON piuttosto che nei valori di input, dove la maggior parte degli scanner automatici cerca. Da lì, l’agente ha iterato attraverso l’iniezione SQL cieca fino a quando i dati di produzione non sono diventati accessibili.

Cosa ha accesso: decine di milioni di messaggi di chat in testo normale, centinaia di migliaia di file, decine di migliaia di account utente e milioni di chunk di documenti RAG che rappresentano anni di ricerche proprietarie. Ha anche identificato i prompt del sistema che governavano il comportamento di Lilli per ogni utente.

La scoperta più allarmante non è stata il volume. È stato che i prompt del sistema erano scrivibili. Un attaccante avrebbe potuto silenziosamente riscritto le istruzioni che governavano le uscite di Lilli, avvelenando i consigli strategici, incorporando dati confidenziali nelle risposte o rimuovendo completamente le barriere di sicurezza, con un solo aggiornamento del database. Nessun deployment. Nessun cambio di codice. Nessuna traccia nei log dell’applicazione.

In una dichiarazione pubblica, McKinsey ha affermato di aver risolto il problema entro poche ore e, dopo un’indagine condotta da una società di forensi di terze parti, non ha trovato prove che i dati confidenziali dei clienti siano stati accessi. Quella risposta è importante. Ma non cambia la lezione strutturale: una classe di vulnerabilità vecchia di decenni ha esposto la memoria operativa di un moderno sistema AI perché i dati dietro di esso esistevano in forma leggibile.

Fallimento del livello di orchestrazione: L’attacco LiteLLM

Tre settimane dopo, lo stesso modello è apparso da un’altra angolazione e attraverso un altro livello.

LiteLLM è un gateway AI open-source utilizzato da migliaia di aziende per instradare le richieste ai provider AI. La sua posizione nella pila è critica: si trova al livello di orchestrazione, detenendo le chiavi API per ogni provider a cui si connette. Qualsiasi compromissione a questo livello espone le credenziali in tutti i servizi integrati.

Secondo un rapporto di incidente PyPI, il gruppo di attaccanti TeamPCP ha sfruttato le credenziali legate a una dipendenza nella pipeline CI/CD di LiteLLM e ha utilizzato l’accesso del maintainer per pubblicare due versioni compromesse del pacchetto LiteLLM direttamente su PyPI. . Le versioni contaminate sono state live per meno di un’ora prima di essere rimosse. L’operazione è stata scoperta solo perché il malware conteneva un bug che ha fatto crashare la macchina di un ricercatore.

La catena di approvvigionamento è stata il vettore. Il livello di orchestrazione era il bersaglio. Compromettendo una sola dipendenza a monte, gli attaccanti hanno raggiunto il livello in cui vivevano le chiavi dei provider di ogni azienda a valle.

Il team LiteLLM ha successivamente dettagliato l’incidente e gli sforzi di mitigazione in una disclosure pubblica su GitHub.

La portata dell’esplosione è diventata visibile quasi immediatamente. TechCrunch, Fortune e The Register hanno riferito che Mercor, una startup di recruiting AI da 10 miliardi di dollari che lavora con aziende come OpenAI, Anthropic, Meta, Google, era tra le aziende colpite. Gli attaccanti hanno affermato di aver ottenuto grandi volumi di dati, tra cui profili di candidati, informazioni personali, interviste video dei contractor, codice sorgente e chiavi API. Meta ha sospeso il lavoro con Mercor in attesa di indagine. Rapporti successivi hanno indicato modelli di malware simili apparsi in altri strumenti di sviluppo e pacchetti, suggerendo che l’operazione potrebbe essersi estesa oltre un singolo progetto.

L’incidente LiteLLM non è stato un’anomalia. È il sistema che si comporta come progettato. Ogni componente in una pipeline AI richiede l’accesso ai dati utilizzabili per funzionare, il che significa che ogni componente è anche un potenziale punto di estrazione. Pinning le dipendenze e ruotando le credenziali sono risposte necessarie, ma affrontano l’incidente, non l’architettura.

Fallimento del livello hardware: TEE.fail

Se la violazione di McKinsey ha dimostrato che il livello di applicazione non può essere considerato attendibile, e l’attacco LiteLLM ha dimostrato che la catena di approvvigionamento non può essere considerata attendibile, la ricerca TEE.fail ha dimostrato che il hardware destinato a compensare entrambi non può essere considerato completamente attendibile.

Il 28 ottobre 2025, i ricercatori della Georgia Tech, Purdue University e Synkhronix hanno pubblicato TEE.fail, un attacco side-channel che estrae chiavi crittografiche da Ambienti di Esecuzione Attendibili utilizzando l’interposizione del bus di memoria fisica su server DDR5. L’attacco colpisce Intel SGX, Intel TDX e AMD SEV-SNP, compresi su sistemi completamente aggiornati con lo stato di attendibilità e con l’abilitazione di AMD Ciphertext Hiding. Queste sono le tecnologie ampiamente promosse come fondamento del calcolo confidente.

I ricercatori hanno estratto le chiavi di attestazione: il materiale crittografico utilizzato per verificare che i carichi di lavoro siano in esecuzione all’interno di ambienti sicuri. Con quelle chiavi, un sistema compromesso può presentarsi come attendibile mentre opera interamente al di fuori delle protezioni previste. I ricercatori hanno dimostrato questo direttamente: hanno forgiato attestazioni TDX su BuilderNet di Ethereum per accedere a dati di transazioni confidenziali e hanno falsificato attestazioni Intel e NVIDIA per eseguire carichi di lavoro al di fuori di qualsiasi TEE mentre apparivano legittimi.

L’implicazione NVIDIA è importante per l’AI in particolare. Poiché l’attestazione GPU dipende dall’attestazione CPU, una catena di fiducia CPU compromessa può minare le garanzie fornite dagli ambienti di inferenza AI confidenti. La base hardware dell’inferenza AI confidente è, in questo modello di minaccia, condizionata da una TEE CPU che è stata dimostrabilmente rotta.

I vendor di hardware hanno risposto con avvisi formali. AMD ha affermato che gli attacchi di accesso fisico rientrano al di fuori del loro modello di minaccia standard e ha indicato che non avrebbe rilasciato aggiornamenti del firmware. Intel e NVIDIA hanno riconosciuto i risultati e hanno indicato lavori di mitigazione in corso. Queste risposte sono ragionevoli all’interno dei loro modelli di minaccia. Evidenziano anche un importante confine: le garanzie della sicurezza basata su hardware dipendono da assunzioni, compreso il controllo fisico, che le distribuzioni sovrane, regolamentate e che affrontano gli avversari non possono sempre fare.

TEE.fail non rende l’isolamento hardware irrilevante. Dimostra che è condizionale.

Fallimento del livello OS: La rivelazione Mythos

Se i primi tre incidenti hanno messo in discussione il livello di applicazione, il livello di orchestrazione e il livello hardware, una quarta disclosure nell’aprile 2026 ha messo in discussione il livello sotto di tutti loro: i sistemi operativi e le librerie di base che ogni altro livello esegue.

Il 7 aprile 2026, Anthropic ha annunciato Claude Mythos Preview, un modello di frontiera che non ha rilasciato pubblicamente a causa delle sue capacità di sicurezza offensiva, e ha lanciato contemporaneamente Project Glasswing, un consorzio con AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, la Linux Foundation, Microsoft, NVIDIA e Palo Alto Networks. Anthropic ha riferito che, nel giro di poche settimane, Mythos aveva autonomamente identificato migliaia di vulnerabilità precedentemente sconosciute in importanti sistemi operativi e browser web e era in grado di produrre exploit funzionanti per molte di esse.

Le scoperte specifiche sono più difficili da ignorare di quanto suggerisca qualsiasi riassunto. Un bug di 27 anni in OpenBSD. Un bug di esecuzione remota di 17 anni nel server NFS di FreeBSD, ora tracciato come CVE-2026-4747, che concede l’accesso root a un attaccante non autenticato. Una vulnerabilità di 16 anni in FFmpeg, una delle librerie multimediali più ampiamente distribuite su Internet. In un caso, un ingegnere Anthropic senza formazione formale in sicurezza ha chiesto al modello di cercare vulnerabilità di esecuzione remota e si è svegliato con un exploit funzionante completo.

Queste sono scoperte a livello di sistema operativo. OpenBSD e FreeBSD sono kernel. NFS è un sottosistema di rete del kernel. FFmpeg è una libreria di sistema che viene fornita con la maggior parte delle distribuzioni Linux e sostiene le pipeline multimediali in tutta la rete. Il livello OS era considerato sicuro non perché era stato provato sicuro, ma perché trovare vulnerabilità profonde in esso richiedeva una competenza umana rara e costosa. Quella limitazione era l’euristica migliore disponibile. Non era una garanzia.

Quella limitazione si è ora allentata. Anthropic stesso ha inquadrato questo come un cambiamento duale: le stesse capacità che consentono a un modello di frontiera di trovare e correggere vulnerabilità su larga scala consentono anche, nelle mani sbagliate, di trovare ed sfruttare vulnerabilità su larga scala. La decisione di Anthropic di limitare l’accesso attraverso Project Glasswing riflette quella realtà. Non la risolve. Capacità simili, secondo la valutazione della società, si diffonderanno. Il costo dell’auditing del codice legacy è crollato, e con esso la difesa implicita che tale codice fosse troppo oscuro, troppo vecchio o troppo ampiamente esaminato per contenere ancora vulnerabilità critiche.

Questo è anche il punto in cui i quattro incidenti si sommano. Le protezioni di calcolo confidente del livello hardware non funzionano in isolamento. Funzionano come codice del kernel. Intel TDX funziona nel kernel. I driver GPU NVIDIA funzionano come moduli del kernel. La catena di attestazione CPU dipende da un sistema operativo attendibile per riferire fedelmente cosa sta facendo. Se il livello OS sotto la tua TEE ha decenni di vulnerabilità latenti, e un modello di frontiera può ora trovarle a velocità di macchina, allora la sicurezza condizionale del livello hardware dipende da un livello OS le cui garanzie di sicurezza sono appena state indebolite dalla stessa disclosure.

I tre incidenti precedenti descrivono come i sistemi AI vengono violati oggi. Mythos descrive la velocità con cui tutto ciò che si trova sotto di essi, compresi i sistemi operativi, i moduli del kernel e le librerie di sistema, sta per essere riesaminato dalle macchine. La violazione di McKinsey ha sfruttato una classe di vulnerabilità di iniezione SQL che esiste da più di due decenni. Vulnerabilità di quel tipo sono esattamente quelle che i modelli della classe Mythos sono dimostrabilmente in grado di trovare su larga scala.

Il modello

In ogni caso, i dati erano in testo normale nel momento in cui contavano.

Il livello di applicazione li ha elaborati in chiaro. Il livello di orchestrazione li ha instradati in chiaro. Il livello hardware, nonostante le sue protezioni, ha alla fine richiesto la decrittazione nel punto di esecuzione. Il livello OS sotto di tutti loro ha operato su di essi in chiaro per definizione. Quattro livelli, quattro fallimenti, e a ogni livello la stessa condizione si è verificata: quando si è verificata la violazione, i dati erano leggibili.

Questo non è un insieme di fallimenti isolati. È l’architettura stessa.

I moderni sistemi AI sono progettati per funzionare con dati leggibili. Ogni livello, compresa la raccolta, l’instradamento, l’inferenza e l’esecuzione degli strumenti, richiede l’accesso in testo normale per funzionare. Quella scelta di progettazione significa che qualsiasi violazione a qualsiasi livello espone i dati dietro di esso.

La domanda non è se un livello verrà compromesso. È cosa trova l’attaccante quando lo è.

Dal presupposto di violazione alla zero esposizione

L’industria ha già iniziato a spostarsi da “prevenire la violazione” a “presupporre la violazione”. Ma la maggior parte delle architetture non ha seguito le implicazioni.

Se la violazione è inevitabile, allora la vera domanda non è come tenere gli attaccanti fuori. È cosa succede quando entrano. Al momento, la risposta è semplice: ottengono i dati. Perché nonostante tutti gli investimenti nella sicurezza, i dati sono ancora esposti nel momento esatto in cui diventano preziosi, quando vengono utilizzati.

La risposta dell’industria è stata prevedibile: più monitoraggio, rilevamento più rapido, ulteriori livelli di calcolo confidente. Questi sono miglioramenti. Ma non risolvono il problema di base. Continuano a presumere che alcuni livelli – software, hardware o operativo – possano essere considerati attendibili per mantenere i dati in testo normale al sicuro.

L’alternativa è rimuovere completamente i dati in testo normale. Non proteggere i livelli intorno ai dati, ma rendere i dati stessi inaccessibili a chiunque li raggiunga. Il calcolo su dati crittografati, dove i prompt, i pesi del modello e le uscite rimangono crittografati in tutta la pipeline, affronta l’esposizione che ognuno di questi incidenti ha sfruttato.

I progressi nel calcolo omomorfico completamente crittografato e in altre tecniche di calcolo che preservano la privacy stanno rendendo sempre più pratiche le architetture che minimizzano o eliminano l’esposizione dei dati in testo normale per i carichi di lavoro AI reali. Sebbene rimangano sfide significative in termini di prestazioni, scalabilità e implementazione, l’obiettivo è fondamentalmente diverso dai controlli di sicurezza tradizionali: ridurre il valore di una compromissione di successo piuttosto che semplicemente renderla meno probabile.

Il passaggio non è da uno strumento di sicurezza all’altro. È dalla sicurezza dei sistemi alla riduzione dell’esposizione. Dall’infrastruttura attendibile alla zero-trust dei dati. Dalla gestione del rischio alla minimizzazione della superficie di attacco stessa.

Cosa viene dopo

La discussione Hard Fork ha sollevato la domanda se la sicurezza informatica sia fondamentalmente mal concepita. Le prove degli ultimi settimane suggeriscono che la risposta è sì, almeno per l’AI.

Il vecchio modello presumeva che i sistemi potessero essere protetti, le violazioni potessero essere contenute e l’esposizione potesse essere gestita. La realtà emergente è che le violazioni devono essere presupposte e l’esposizione minimizzata. Gli incidenti descritti qui suggeriscono che proteggere i sistemi AI potrebbe dipendere sempre più dalla riduzione della quantità di dati sensibili disponibili quando i controlli falliscono.

Le vulnerabilità esposte in questi quattro incidenti non sono confinate in un singolo livello. Sono sistemiche. Affrontarle richiederà più che miglioramenti incrementali. Richiederà un passaggio dalla sicurezza dei sistemi alla riduzione dell’esposizione, dalla difesa del perimetro intorno ai dati alla rimozione dei dati in testo normale che il perimetro era stato costruito per proteggere.

La sicurezza AI non è più questione di tenere gli attaccanti fuori. È questione di assicurarsi che, quando entrano, e lo faranno, non ci sia nulla di leggibile da trovare.