I tuoi modelli di IA sono codice eseguibile. La maggior parte delle aziende li tratta come fogli di calcolo.
La prima volta che ho capito davvero il problema, stavo osservando una traccia di syscall scorrere in un container isolato, aspettando che non facesse nulla.
Avevamo scaricato un modello da un registro pubblico — di quelli che un data scientist scarica cento volte a trimestre senza pensarci. La model card sembrava normale. Aveva superato una scansione di base. L'avevo caricato in una sandbox non perché fossi sospettoso di quello specifico file, ma perché avevo iniziato a caricare tutto in una sandbox. E mentre la deserializzazione procedeva, la traccia mostrava il processo che tentava di aprire una connessione di rete che non aveva alcun motivo di aprire.
Questa è l'intera tesi della sicurezza della supply chain dell'IA in un solo istante: i tuoi modelli non sono file di dati. Sono codice eseguibile che viene eseguito nell'istante in cui li carichi. La maggior parte delle organizzazioni li tratta come fogli di calcolo — cose inerti che scarichi e apri — e quel divario tra ciò che un modello è e come viene trattato è esattamente dove avvengono le violazioni.
Un modello non è un documento che apri. È un programma che esegui con i privilegi di chi lo ha eseguito.
La storia della reverse shell non è nemmeno un aneddoto ipotetico del settore. È stato scoperto che un modello chiamato "baller423" su Hugging Face stabiliva una reverse shell verso un host esterno. Sembrava normale. Aveva superato le scansioni di base. Eseguiva codice arbitrario nel momento in cui qualcuno lo caricava. Quando racconto quella storia a una sala piena di responsabili della sicurezza, il disagio non è che una cosa del genere sia possibile — è che si rendono conto che il loro team carica modelli dalla stessa fonte, nello stesso modo, da due anni.
Il problema di pickle di cui nessuno vuole sentir parlare
Ecco la parte che fa storcere il naso agli ingegneri esperti, perché non è un bug che qualcuno possa correggere con una patch.
Quando chiami torch.load() su un modello PyTorch, può eseguire codice Python arbitrario durante la deserializzazione. Non è una vulnerabilità nel senso consueto. È il comportamento intenzionale del formato di serializzazione pickle di Python — a pickle è consentito ricostruire oggetti eseguendo codice, e un file di modello non è altro che un oggetto serializzato con pickle. Oltre l'80% dei modelli di machine learning in circolazione usa questo formato. Quindi il modo predefinito con cui l'intero settore distribuisce i modelli è anche una primitiva di esecuzione di codice remoto in attesa che qualcuno la riempia.
L'istinto, ragionevolmente, è di scansionarlo. La difesa più diffusa è uno strumento chiamato PickleScan, che cerca pattern noti come dannosi all'interno dei file di modello. E PickleScan ha almeno tre bypass zero-day noti — tra cui CVE-2025-10155 — con i ricercatori di Sonatype che hanno poi trovato altre quattro vulnerabilità nello scanner stesso.
Non lo dico per infierire su un progetto open source che sta facendo un lavoro serio. Lo dico perché mi ha insegnato un principio attorno a cui ora costruisco tutto: quando l'attaccante controlla il formato del file, la scansione basata su blacklist è strutturalmente perdente. La scansione statica chiede "questo file contiene un pattern che so già essere dannoso?" L'attaccante, che può vedere la tua stessa blacklist, usa semplicemente un pattern che ancora non conosci.
Così abbiamo smesso di porci quella domanda. Le pipeline di verifica che il mio team costruisce non partono da "quali stringhe note come dannose ci sono in questo file". Partono dal sandboxing comportamentale: carica il modello in un container isolato, osserva cosa effettivamente fa — le syscall, le connessioni di rete, le scritture su file — e valuta il comportamento, non la firma. La domanda passa da "è presente in un elenco" a "cosa fa questo codice quando viene eseguito". Quella seconda domanda è l'unica che intercetta l'attacco che nessuno ha ancora nominato.
La scansione statica intercetta l'attacco di ieri. Il sandboxing comportamentale intercetta quello che l'attaccante sta scrivendo proprio ora.
Non è gratis, e non è un prodotto che compri già pronto sullo scaffale. Protect AI, ora parte di Palo Alto Networks dopo un'acquisizione da circa $500–700M conclusa a luglio 2025, ha scansionato 4.47 milioni di versioni di modelli e ha trovato 352,000 problemi non sicuri o sospetti in oltre 51,700 modelli. Questa è la dimensione del pagliaio. Gli strumenti possono segnalare l'ovvio. Progettare il gate che si colloca tra un registro pubblico e il tuo store interno di modelli — e renderlo abbastanza veloce da far sì che nessuno lo aggiri — è la parte che non arriva in una scatola.
Il gate che ho costruito e che tutti hanno ignorato
Voglio raccontarti la versione di tutto questo che ho sbagliato, perché il fallimento mi ha insegnato più del successo.
All'inizio, ho costruito per un cliente un gate di verifica dei modelli che era, tecnicamente, eccellente. Ogni modello proveniente da una fonte pubblica veniva portato nella sandbox, analizzato a fondo su tutti i formati, profilato comportamentalmente e solo allora firmato e ammesso al registro interno. In una revisione di sicurezza avrebbe ottenuto un punteggio splendido. Ne ero orgoglioso.
Nel giro di circa una settimana, il team di data science aveva silenziosamente smesso di usarlo.
Non per malizia. Avevano delle scadenze. Il gate aggiungeva minuti reali a un flusso di lavoro in cui l'alternativa — scaricare un modello direttamente da Hugging Face — richiedeva trenta secondi. Così, quando un esperimento aveva bisogno di un modello subito, lo scaricavano grezzo su un account cloud personale e andavano avanti. Il mio splendido gate proteggeva una porta vuota mentre il traffico reale passava dal lato dell'edificio.
Quella settimana ha riformulato l'intero problema per me. Il controllo più difficile nella sicurezza della supply chain dell'IA non è tecnico. È che un gate di sicurezza più lento del percorso insicuro perderà ogni singola volta. Quando un data scientist può scaricare un modello in trenta secondi, qualsiasi processo che richiede trenta minuti viene aggirato — non da malintenzionati, ma da bravi ingegneri sotto pressione. I controlli devono essere abbastanza veloci da rendere la conformità più facile dell'aggiramento. Se non lo sono, non hai un programma di sicurezza. Hai un teatrino della sicurezza con ottime recensioni e nessun pubblico.
Ecco perché i numeri sulla shadow AI non mi hanno mai sorpreso dopo di allora. Il 98% delle organizzazioni ha dipendenti che usano strumenti di IA non autorizzati. Il 62% dei professionisti della sicurezza afferma di non avere un modo affidabile per sapere dove i large language model siano addirittura in esecuzione nel proprio ambiente. Solo circa il 9% delle aziende ha un sistema di governance dell'IA funzionante, anche se un terzo dei dirigenti ti dirà di avere un tracciamento completo. E il costo non è astratto: il report Cost of a Data Breach 2025 di IBM stima la violazione media legata alla shadow AI a $4.63 milioni — circa $670,000 in più rispetto a un incidente standard.
Non puoi proteggere ciò che non puoi vedere, e in questo momento la maggior parte delle organizzazioni non riesce a vedere gran parte della propria IA.
Perché il fine-tuning disarma silenziosamente il tuo modello più sicuro?
Questa è quella che suscita la reazione più forte quando la porto a un team tecnico, perché contraddice qualcosa che tutti danno per scontato.
L'assunto è: ho valutato la sicurezza di questo modello, l'ha superata, quindi è sicuro. La realtà è che l'allineamento alla sicurezza è fragile in un modo che la tempistica della valutazione ignora completamente. In uno studio, la resilienza di Llama 3.1 8B alla prompt injection è scesa da un punteggio di 0.95 a 0.15 dopo un singolo ciclo di fine-tuning — e non un fine-tuning avversario. Un addestramento normale, benigno, specifico per dominio. Si tratta di un crollo di circa l'84% in una proprietà di sicurezza, causato dalla cosa più ordinaria che un'azienda faccia a un modello.
Ho avuto esattamente questa discussione con il team ML di un cliente. Avevano eseguito la loro valutazione di sicurezza, il modello l'aveva superata, l'avevano sottoposto a fine-tuning sui propri dati ed erano pronti al rilascio. Ho chiesto quando pensassero di rieseguire la valutazione. La sala è calata un po' nel silenzio, perché la risposta onesta era "non avevamo intenzione di farlo". Il modello supera il gate prima di ciò che lo rompe. Poi va in produzione con le sue guardrails di fatto rimosse, e i documenti dicono tutti che è sicuro.
Il modello supera il suo controllo di sicurezza prima del passaggio che distrugge la sicurezza. Quasi nessuno controlla di nuovo in seguito.
Così abbiamo spostato la valutazione di sicurezza a dopo il fine-tuning, ne abbiamo fatto un gate di rilascio anziché un gate di ingresso, e abbiamo trattato ogni fine-tuning come un evento che invalida la precedente attestazione di sicurezza. Sembra quasi troppo ovvio una volta detto ad alta voce. Il motivo per cui non è prassi standard è lo stesso del gate che nessuno usava: il momento comodo per valutare è all'ingresso, e rivalutare dopo ogni fine-tuning è attrito. L'attrito è il nemico, ma in questo caso è l'unica cosa che si frappone tra un report che dà esito positivo e un modello indifeso.
Il poisoning dimostra lo stesso punto dalla direzione opposta. La ricerca ha dimostrato che appena 250 documenti avvelenati possono impiantare una backdoor in un modello da 13 miliardi di parametri — circa lo 0.00016% del corpus di addestramento. Non è necessario compromettere i dati su larga scala. Ne basta una quantità pari a un errore di arrotondamento. A febbraio 2026 Microsoft ha pubblicato una contromisura davvero incoraggiante — un metodo di rilevamento "sleeper agent" in grado di identificare un modello avvelenato senza conoscere la frase trigger, individuando un pattern di attenzione distintivo. È la prima vera difesa che io abbia visto contro un attacco che in precedenza era quasi impossibile da rilevare. È anche esattamente il tipo di capacità che vive in un articolo di ricerca, non nella tua pipeline CI/CD, finché qualcuno non fa il lavoro di ingegneria per portarla lì.
Gli agenti hanno trasformato una prompt injection in una kill chain
Per anni, lo scenario peggiore con un modello manipolato o una prompt injection era un cattivo output. Il modello dice qualcosa di sbagliato, rivela qualcosa che non dovrebbe, ti mette in imbarazzo. Limitato. Fastidioso. Sopravvivibile.
L'IA agentica ha eliminato il limite.
Un agente IA ha accesso agli strumenti, credenziali e privilegi di esecuzione che un modello di chat non ha. Quindi, quando inietti un'istruzione malevola in qualcosa che un agente legge, non stai più corrompendo una risposta — stai impartendo un comando a un sistema che può agire. GitHub Copilot aveva una vulnerabilità di esecuzione di codice remoto, CVE-2025-53773, valutata CVSS 7.8 e corretta ad agosto 2025, in cui una prompt injection piazzata nella documentazione di un repository poteva far scivolare l'agente nella sua "YOLO mode" autonoma ed escalare fino alla compromissione totale del sistema. L'agente leggeva un commento malevolo, lo eseguiva come codice, e la macchina era compromessa.
Poi c'è stato l'incidente della supply chain di Amazon Q a luglio 2025: un malevolo cleaner.md template di prompt è stato iniettato tramite un token GitHub configurato male, e una versione rilasciata ha distribuito comandi distruttivi a una base installata molto ampia. E nel 2026, l'ecosistema di agenti OpenClaw è diventato la prima grande crisi di sicurezza degli agenti IA dell'anno — 138 CVE in 63 giorni, più di 135,000 istanze esposte e il 12% delle skill nel suo marketplace risultate malevole. Il threat reporting 2026 di HiddenLayer collega ora circa una violazione IA su otto ai sistemi agentici.
Il filo conduttore di tutti questi casi è lo stesso: gli agenti convertono un singolo input manipolato in una kill chain orchestrata e multi-strumento. Quella che era una sola frase sbagliata diventa una sequenza di azioni reali con credenziali reali. È la frontiera che più mi preoccupa in questo momento, perché si sta espandendo più velocemente di quanto qualsiasi categoria di prodotti riesca a stare al passo, e non esiste ancora un playbook consolidato per metterla in sicurezza.
Quindi, cosa fai concretamente al riguardo?
Le persone mi chiedono sempre una qualche versione di: "Non posso semplicemente comprare uno strumento per questo?" E la risposta onesta è che puoi comprare pezzi, e i pezzi stanno migliorando in fretta.
Il panorama dei vendor è maturato in un vero ecosistema — Protect AI di Palo Alto e Wiz per la scansione e la generazione dell'AI bill-of-materials all'interno delle loro suite cloud e di piattaforma, JFrog per mettere in sicurezza il registro dei modelli e la pipeline degli artefatti, HiddenLayer per il rilevamento e la risposta a runtime, le guardrails open source di NVIDIA per i controlli LLM a livello applicativo, Fortanix che porta il confidential computing alla distribuzione dei modelli. Quest'ultimo è un buon esempio del perché gli strumenti da soli non colmano il divario: le GPU confidenziali che mantengono un modello cifrato anche mentre è in esecuzione (le generazioni Hopper e Blackwell di NVIDIA) esistono davvero, ma integrare quei trusted execution environment in una pipeline di inferenza in produzione è un'ingegneria specializzata che la maggior parte dei team semplicemente non ha in organico. Ogni vendor è davvero bravo nella sua fetta. Nessuno di loro progetta la tua pipeline end-to-end, la mappa sui tuoi obblighi o cambia il modo in cui la tua organizzazione si comporta effettivamente.
E l'altra metà del mercato — le grandi società di strategia — ti venderà il problema opposto: un framework di governance dell'IA da 200 pagine, una presentazione per il consiglio, documentazione pronta per l'audit e un ingaggio che parte da circa $500K per la strategia e sale fino ai milioni per l'implementazione. Quello che di solito non faranno è costruire la pipeline di firma dei modelli, configurare la generazione dell'ML-BOM all'interno del tuo CI/CD o predisporre il rilevamento della shadow AI a livello di rete. Finisci con il raccoglitore e non con la realizzazione.
Questo divario — tra strumenti che scansionano e presentazioni che consigliano — è l'intera ragione per cui Veriprajna fa della sicurezza della supply chain dell'IA un lavoro di ingegneria anziché un report. Ciò che costruiamo è concreto: pipeline automatizzate di verifica dei modelli che sottopongono a sandbox comportamentale ogni modello in ingresso e firmano quelli puliti con la tua PKI aziendale; un ML-BOM — una distinta base di machine learning, l'equivalente per l'IA di un'etichetta degli ingredienti che traccia ogni componente e la sua provenienza — generato e ancorato all'interno della pipeline usando lo standard CycloneDX; provenienza e firma costruite sull'emergente lavoro di attestazione CoSAI; gating di sicurezza post-fine-tuning; e rilevamento della shadow AI che porta alla luce i modelli che i tuoi strumenti di sicurezza attualmente non riescono a vedere.
Gli standard per fare la maggior parte di tutto questo esistono già. CycloneDX ML-BOM, la firma dei modelli CoSAI e la tassonomia aggiornata dell'adversarial ML di NIST (AI 100-2) sono tutti pubblicati e utilizzabili oggi. Il problema non è mai stato un problema di conoscenza. Secondo la misurazione 2025 di Kiteworks, l'83% delle organizzazioni è ancora privo di controlli di sicurezza dell'IA automatizzati — navigano alla cieca non perché manchi il playbook, ma perché nessuno ha la capacità ingegneristica per implementarlo. La lacuna sono le mani, non le idee.
Su questo pesa anche un orologio normativo. L'EU AI Act diventa pienamente applicabile il 2 agosto 2026 e, per i sistemi ad alto rischio, richiede una vera documentazione tecnica — provenienza dei dati di addestramento, valutazione di conformità, il tipo di attestazione della supply chain che un ML-BOM è progettato per produrre. Importatori e distributori di componenti di IA dovranno verificare ciò che trasmettono a valle, e i provider e i loro fornitori di componenti di terze parti devono concordare per iscritto le informazioni e l'accesso tecnico che ciascuno condividerà. Ho iniziato a dire ai clienti la parte silenziosa di quella clausola: una volta che l'Act entra in vigore, la provenienza dei modelli smette di essere solo un tuo problema da assorbire — i tuoi fornitori devono attestarla per iscritto, e quelli che non possono farlo semplicemente smetteranno di essere utilizzabili. Le aziende che trattano la provenienza dei modelli come un optional scopriranno che è un requisito di legge.
La slide che ha davvero smosso il budget
Concluderò dove queste conversazioni di solito finiscono: davanti a un consiglio di amministrazione.
Ho visto molti solidi casi di sicurezza non ottenere finanziamenti perché erano presentati come casi di sicurezza — rischio astratto, attaccanti ipotetici, una categoria che suona come un'assicurazione. La presentazione che ha funzionato è stata quella che ha messo un solo numero sul tavolo: il costo medio di $4.63 milioni di una violazione da shadow AI, contrapposto al costo di costruire i controlli che la prevengono. Non paura. Un delta. Ecco il rischio quantificato, ecco quanto costa colmarlo, ecco la differenza.
Questa impostazione funziona perché è fedele a come questo problema si comporta davvero. La minaccia non è esotica. È il flusso di lavoro predefinito — scarichi un modello, gli fai il fine-tuning, lo distribuisci, non lo guardi mai più — che gira in ogni organizzazione che costruisce con l'IA, che ormai sono quasi tutte. I budget dei CISO lo riflettono: circa l'85% delle organizzazioni ha aumentato la spesa in cybersecurity entrando nel 2026, e la sicurezza dell'IA è la voce di bilancio più discussa.
Un modello è l'unico artefatto nel tuo ambiente che è simultaneamente la cosa più preziosa che possiedi e un pezzo di codice eseguibile non verificato che hai scaricato da uno sconosciuto su internet. Finché non lo tratti come entrambe le cose insieme — verificalo come codice, tracciarlo come una supply chain e ricontrollalo ogni volta che lo modifichi — il report che dice che sei al sicuro sta verificando un controllo che nessuno sta effettivamente usando. Se stai pensando a dove iniziare, inizia da lì: smetti di fidarti della model card e osserva cosa fa il modello quando viene eseguito.
