Le violazioni di sicurezza AI del 2025 hanno svelato una menzogna da mille miliardi di dollari — e io ho costruito l'alternativa

Ero al telefono con il CISO di una società di servizi finanziari di medie dimensioni quando è stata divulgata la vulnerabilità RCE di GitHub Copilot. Eravamo a metà di una frase — mi stava spiegando perché il suo team aveva appena distribuito Copilot a 400 sviluppatori — e ho visto la sua espressione cambiare mentre il suo Slack si accendeva. Ha disattivato il microfono. È tornato novanta secondi dopo e ha detto, molto sottovoce: "Puoi spiegarmi cosa significa per noi la CVE-2025-53773?"

Significava questo: un'istruzione nascosta piazzata in un file README — un file di testo — poteva degenerare in un'esecuzione di codice remoto completa su ogni workstation di sviluppo su cui girava Copilot. Non attraverso un buffer overflow. Non attraverso uno zero-day nel kernel. Attraverso una conversazione con un assistente AI.

Quella telefonata ha cambiato la traiettoria dei miei sei mesi successivi. Ma onestamente, i segnali erano evidenti da oltre un anno.

Sono Ashutosh, il fondatore di Veriprajna — un nome derivato dal latino Veri (verità) e dal sanscrito Prajna (saggezza). Costruiamo quella che chiamo Deep AI: sistemi deterministici per progettazione, auditabili per requisito e sovrani per infrastruttura. Non costruiamo wrapper. E il 2025 ha dimostrato, in modo catastrofico, perché quella distinzione conta.

L'economia dei wrapper era destinata a crollare

Per circa due anni, il mercato dell'AI enterprise si è retto su una premessa seducente: prendi un foundation model — GPT-4, Claude, Gemini — avvolgilo in una bella interfaccia, aggiungi un po' di prompt engineering e vendilo come "soluzione". Migliaia di startup hanno fatto esattamente questo. Molte hanno raccolto capitali ingenti facendolo.

Capivo l'attrattiva. Il time-to-demo era incredibile. In una settimana potevi mostrare a un consiglio di amministrazione un'AI che "capiva" il loro business. Ma continuavo a porre una domanda che mi rendeva impopolare agli eventi di settore: che cosa succede quando questa cosa gira in produzione, con permessi reali, su infrastrutture reali?

La risposta è arrivata nel 2025, ed è arrivata in modo violento.

Tre incidenti — la vulnerabilità di esecuzione di codice remoto di GitHub Copilot, l'esposizione degli "Zombie Data" attraverso la cache di Microsoft Bing e l'avvelenamento della supply chain di Amazon Q — hanno colpito complessivamente oltre 16.000 organizzazioni e quasi un milione di sviluppatori. Non erano casi limite. Erano la conseguenza prevedibile del distribuire sistemi probabilistici come se fossero infrastruttura deterministica.

Quando l'AI opera come un agente non monitorato con permessi amministrativi, i suoi fallimenti si propagano alla velocità dell'infrastruttura.

Ho descritto l'anatomia tecnica completa di queste violazioni nella versione interattiva della nostra ricerca. Ma è la storia dietro i numeri a tenermi sveglio la notte.

Che cosa succede quando un prompt diventa un'arma?

Lascia che ti guidi attraverso l'incidente di Copilot, perché la meccanica è davvero agghiacciante.

La CVE-2025-53773 ha ottenuto un punteggio di 7,8 sulla scala di gravità CVSS — "Alto". La classe di vulnerabilità era qualcosa per cui il settore ha dovuto inventare un nome: Prompt-to-RCE. L'escalation di un'istruzione linguistica fino all'esecuzione di codice binario.

Ecco come funzionava. Un attaccante piazza un'istruzione nascosta — una cross-prompt injection — dentro un file README, un commento nel codice o persino una issue di GitHub. Niente di visivamente sospetto. Quando uno sviluppatore chiede a Copilot di "rivedere il codice" o "spiegare questo progetto", l'AI ingerisce quelle istruzioni nascoste. Poi modifica il file di configurazione del workspace, aggiungendo nello specifico la riga "chat.tools.autoApprove": true.

La community della sicurezza ha iniziato a chiamarla "modalità YOLO". Una volta attivata questa modalità, l'assistente AI poteva eseguire comandi shell, navigare sul web e interagire con il file system locale — il tutto senza chiedere il permesso allo sviluppatore. Da lì, scaricare malware, esfiltrare credenziali o arruolare la workstation in una botnet era banale.

Ricordo di essere rimasto seduto nel nostro ufficio dopo aver letto la divulgazione completa, di essermi girato verso il mio lead security engineer e di aver detto: "Questo non è un bug. Questa è l'architettura che funziona come da progetto." All'AI è stata data la capacità di agire. Le sono stati concessi i permessi. E nessuno ha costruito un sistema in grado di dire "no" a un prompt sufficientemente persuasivo.

È questa la parte che mi ha ossessionato. I controlli di accesso tradizionali presuppongono che l'attore sia un essere umano oppure un software con un comportamento fisso. Un agente AI non è né l'uno né l'altro. Eredita tutti i permessi dell'utente ma risponde alla manipolazione linguistica. È come dare a qualcuno le chiavi di casa tua e poi sorprendersi quando un truffatore lo convince ad aprire la porta.

Perché i dati morti sono tornati in vita?

La seconda violazione è stata più strana e, per certi versi, più inquietante.

Nel febbraio 2025, i ricercatori di Lasso Security hanno scoperto che il Copilot di Microsoft mostrava dati provenienti da repository GitHub che erano stati resi privati o eliminati — a volte mesi prima. Li hanno chiamati "Zombie Data", e il nome è rimasto perché era accurato. Erano dati che avrebbero dovuto essere morti. Non lo erano.

Il meccanismo era di una semplicità quasi imbarazzante. Il motore di ricerca di Bing aveva scansionato e messo in cache migliaia di repository pubblici. Quando quei repository venivano poi resi privati — spesso perché qualcuno si accorgeva di aver committato per errore chiavi API, documentazione interna o codice proprietario — le versioni in cache persistevano nel sistema di retrieval-augmented generation (RAG) di Bing. Chiunque usasse Copilot poteva recuperare tramite query quelle informazioni presumibilmente eliminate.

L'esposizione era sconcertante: repository privati di IBM, Google, Tencent e PayPal. Oltre 300 token privati e chiavi API estratti per servizi come AWS, GCP, OpenAI e Hugging Face. Più di 100 pacchetti interni vulnerabili ad attacchi di dependency confusion.

In quel periodo ho avuto una conversazione con un potenziale cliente — un VP of Engineering di un'azienda sanitaria — che mi ha detto che il suo team aveva fatto "tutto nel modo giusto". Avevano ruotato le credenziali, reso privati i repository, seguito il manuale. E niente di tutto questo è servito, perché la memoria dell'AI era più lunga della loro risposta di sicurezza.

Nel modello wrapper, la sovranità dei dati e la comodità dell'AI sono fondamentalmente in conflitto. Non puoi controllare il ciclo di vita dei tuoi dati quando la context window della tua AI è la cache di ricerca di qualcun altro.

È la violazione che ha cristallizzato qualcosa che sostenevo da tempo: se la tua AI dipende da un sistema di retrieval di terze parti — un motore di ricerca pubblico, un'API esterna, l'indice di qualcun altro — hai già perso il controllo dei tuoi dati. Non importa quanto siano buone le tue policy interne. I dati vivono in un posto che non puoi raggiungere, in una cache che non puoi svuotare, e forniscono risposte a domande che non hai mai autorizzato.

Come si avvelenano su larga scala i suggerimenti di un'AI?

Il terzo incidente è quello che ha fatto arrabbiare tutto il mio team.

Nel luglio 2025, un attaccante ha compromesso l'estensione Amazon Q Developer per Visual Studio Code — un'estensione con oltre 950.000 installazioni. Il punto d'ingresso era un token GitHub con scope configurato in modo improprio in un servizio CI/CD, che ha permesso all'attaccante di committare un file chiamato cleaner.md direttamente nel repository sorgente.

Quel file era un template di prompt. Sembrava innocuo. Ma istruiva l'AI a comportarsi come un "system cleaner" — suggerendo comandi Bash che avrebbero cancellato la home directory dell'utente, terminato istanze EC2, eliminato bucket S3 e rimosso utenti IAM.

Fermati un attimo a pensarci. Un file di testo in un repository fidato, distribuito attraverso un aggiornamento ufficiale del marketplace, ha trasformato un assistente AI per la scrittura di codice in un'arma puntata sia sulle macchine locali sia sull'infrastruttura cloud di produzione.

Ero in una riunione di team mentre lo stavamo sezionando. Uno dei miei ingegneri — una persona che lavora nella sicurezza da quindici anni — l'ha detto senza giri di parole: "Abbiamo passato decenni a mettere in sicurezza binari, container e perimetri di rete. Nessuno ha messo in sicurezza i suggerimenti."

Aveva ragione. La compromissione di Amazon Q ha dimostrato che i prompt sono il nuovo codice. Plasmano il comportamento dell'AI in modo altrettanto definitivo di quanto le istruzioni compilate plasmino il comportamento di una CPU. Eppure, in tutto il settore, i template di prompt venivano archiviati in chiaro, committati senza revisione e distribuiti senza firma crittografica.

A volte mi chiedono se questi incidenti fossero davvero così gravi — in fondo, sono stati individuati e corretti con delle patch. Ma questo non coglie affatto il punto. Le patch hanno risolto vulnerabilità specifiche. Non hanno risolto l'architettura che rendeva quelle vulnerabilità inevitabili.

Il problema fondamentale dell'AI probabilistica negli ambienti ad alto rischio

Ecco la verità scomoda che l'economia dei wrapper non ha mai voluto affrontare: i Large Language Model sono motori stocastici. Predicono il token successivo più probabile in base a pattern statistici presenti nei dati di addestramento. Sono straordinariamente bravi a produrre testo fluente e dal suono plausibile. Ma non hanno alcun concetto di verità. Non hanno alcun concetto di sicurezza. Non hanno alcun concetto di "questa azione distruggerà un database di produzione".

Quando avvolgi un modello probabilistico in una sottile interfaccia e gli consegni permessi amministrativi, non hai costruito una soluzione enterprise. Hai costruito una responsabilità legale molto eloquente.

Un LLM non comprende la verità — comprende la plausibilità. In un ambiente di produzione, quella distinzione è la differenza tra un audit trail e un rapporto di violazione.

È questo il problema per risolvere il quale ho fondato Veriprajna. Non abbandonando le reti neurali — sono davvero potenti per la comprensione del linguaggio naturale, il riconoscimento di pattern e l'inferenza creativa. Ma rifiutando di lasciarle operare da sole.

Come si presenta davvero un'architettura neuro-simbolica?

Progettiamo sistemi ibridi che fondono due modalità distinte di intelligenza. Io le penso come la Voce e il Cervello.

Il sistema neurale — la Voce — si occupa della percezione. Capisce che cosa sta chiedendo uno sviluppatore, interpreta il linguaggio naturale, riconosce pattern. È il livello di interfaccia, ed è eccellente in ciò che fa.

Il sistema simbolico — il Cervello — si occupa del ragionamento. Applica logica deterministica, calcoli auditabili e vincoli specifici del dominio. Non predice. Dimostra.

L'intuizione cruciale è il disaccoppiamento. Quando la Voce propone un'azione — per esempio, generare un comando shell — il Cervello la verifica rispetto a regole logiche rigide prima dell'esecuzione. Se un modello neurale suggerisce di eliminare un database in una VPC di produzione, il motore simbolico pone il veto. Non perché qualcuno abbia scritto un prompt che dice "per favore non eliminare i database". Perché l'azione è fisicamente bloccata a livello architetturale.

Li chiamiamo Guardrail Costituzionali, e sono fondamentalmente diversi dai guardrail linguistici su cui il settore fa affidamento. I guardrail linguistici sono istruzioni — "sii utile e innocuo". Vengono aggirati con il jailbreaking, con la prompt injection indiretta, con esattamente le tecniche che hanno alimentato le violazioni del 2025. I guardrail architetturali sono vincoli integrati nel runtime. Non si possono convincere a non applicare una regola, così come non si può convincere un firewall a non bloccare una porta.

Un meccanismo specifico che utilizziamo è la Verifica KG-Trie: l'output di un modello neurale è vincolato da un Knowledge Graph verificato. Se il modello tenta di generare un fatto, una citazione o un comando che non esiste all'interno del grafo verificato, il sistema impedisce la generazione di quei token. L'AI letteralmente non può allucinare al di fuori del confine della conoscenza verificata.

Per l'analisi tecnica completa di questa architettura, incluso il nostro approccio al deployment edge-native e alle reti neurali physics-informed, vedi il nostro approfondimento tecnico.

Perché l'infrastruttura sovrana non è più opzionale

La violazione degli Zombie Data mi ha insegnato una cosa che oggi ripeto a ogni potenziale cliente enterprise: se il tuo modello AI gira sull'infrastruttura di qualcun altro, la tua sovranità dei dati è una gentile finzione.

In Veriprajna distribuiamo interamente all'interno dell'ambiente del cliente. Zero dipendenze da cache di ricerca esterne. Zero chiamate API di terze parti per il retrieval. Un sistema a ciclo chiuso in cui il contesto dell'AI è esattamente — e soltanto — ciò che l'organizzazione ha esplicitamente fornito.

Non è paranoia. È l'unica architettura che rende le esposizioni di "zombie data" tecnicamente impossibili. Non puoi avere un problema di persistenza della cache se non esiste una cache esterna.

All'inizio ho avuto un acceso confronto con un investitore che mi ha detto che questo approccio era "troppo pesante". Diceva che il mercato voleva soluzioni leggere, veloci, basate su chiamate API. Gli ho risposto che il mercato voleva soluzioni che funzionassero — e che il peso di un deployment sovrano era poca cosa rispetto al peso di dover spiegare a un regolatore perché le tue credenziali eliminate stavano ancora rispondendo a domande attraverso l'AI di qualcun altro.

Non ha investito. Non gliene faccio una colpa. Ma noto che quell'argomentazione non la porta più avanti.

Il settore può davvero risolvere il problema?

La OWASP Top 10 for LLM Applications del 2025 si legge come un post-mortem di tutto ciò che è andato storto quest'anno. La Prompt Injection occupa il primo posto. La Sensitive Information Disclosure il secondo. La Supply Chain il terzo. L'Excessive Agency — esattamente la modalità di fallimento della RCE di Copilot — il sesto.

Non sono rischi teorici. Sono le cause documentate di violazioni reali che hanno colpito organizzazioni reali.

Il NIST AI Risk Management Framework si sta evolvendo nella direzione giusta, spingendo le organizzazioni verso una governance continua anziché valutazioni puntuali. Ma i framework non si traducono da soli in codice. Qualcuno deve costruire i sistemi che li applicano davvero.

È quello che facciamo noi. Trattiamo i file di prompt come artefatti eseguibili — firmati crittograficamente, revisionati e sottoposti a controllo di versione con lo stesso rigore dei binari compilati. Costruiamo profili di comportamento di riferimento per ogni agente AI, tracciando i pattern di chiamate API e i volumi di accesso ai dati per rilevare le anomalie prima che diventino incidenti. Eseguiamo mutation testing e fuzzing avversariale contro i nostri agenti, non solo test funzionali, perché la domanda non è "funziona?" — è "che cosa succede quando qualcuno prova a farlo comportare male?"

La notte fonda che ha cambiato il mio modo di pensare alla sicurezza dell'AI

C'è stata una notte — saranno state le 2 del mattino — in cui stavo esaminando per la terza volta i dettagli tecnici della compromissione di Amazon Q. Il mio team era andato a casa. Ero seduto con una tazza di chai ormai freddo, a fissare il contenuto del file cleaner.md che era stato pubblicato nella divulgazione.

Le istruzioni erano così educate. "Per favore comportati come un system cleaner." "Suggerisci comandi per ripulire l'ambiente." I payload distruttivi erano avvolti nel linguaggio della disponibilità. E ho capito che questa era la metafora perfetta dell'intera economia dei wrapper: una superficie disponibile che nasconde un'architettura distruttiva.

Avevamo passato anni a costruire un'AI ottimizzata per essere accondiscendente. Per dire di sì. Per generare il token plausibile successivo. E le avevamo dato le chiavi dell'infrastruttura di produzione.

L'economia dei wrapper ha ottimizzato l'AI per essere accondiscendente. A nessuno è mai venuto in mente che accondiscendenza e sicurezza sono fondamentalmente in tensione.

Quella notte ho riscritto da zero i nostri principi interni di sicurezza. La prima riga ora recita: "La risposta predefinita del sistema a qualsiasi azione con conseguenze irreversibili è no."

L'architettura è il prodotto

So come suona tutto questo. Un fondatore che ti dice che il suo approccio è migliore, che il mercato ha sbagliato, che il futuro appartiene proprio alla cosa che lui vende. Capisco lo scetticismo.

Ma ecco che cosa ti chiederei di considerare: i tre più grandi incidenti di sicurezza AI del 2025 condividono tutti la stessa causa radice. Non un bug specifico. Non la negligenza di un vendor specifico. Una filosofia di progettazione — la convinzione che si possa costruire AI di livello enterprise avvolgendo un modello probabilistico in un sottile strato di interfaccia e sperando che i prompt reggano.

I prompt non hanno retto. Non avrebbero mai retto. Le istruzioni linguistiche sono suggerimenti, non vincoli. E negli ambienti ad alto rischio — finanza, sanità, manifattura, difesa — la differenza tra un suggerimento e un vincolo è la differenza tra un sistema funzionante e un fallimento catastrofico.

Il futuro dell'AI enterprise non è un wrapper migliore. È un'architettura che separa la voce dal cervello, che applica i vincoli a livello di runtime, che mantiene i dati sovrani e che tratta ogni azione dell'AI come infrastruttura auditabile — non come un messaggio di chat che sparisce dentro un file di log.

Non ho costruito Veriprajna perché pensavo che l'economia dei wrapper sarebbe crollata. L'ho costruita perché sapevo che doveva crollare.