TL; DR
Il termine "minacce alla sicurezza dell'IA" comprende due aspetti diversi: gli attacchi diretti ai sistemi di IA e gli attacchi che utilizzano l'IA come arma. Richiedono controlli diversi, proprietari diversi e prove diverse, e la maggior parte degli elenchi li mescola, motivo per cui è così difficile intervenire. I primi cinque punti qui sotto prendono di mira la tua IA. Gli ultimi cinque usano l'IA contro la tua catena di fornitura.
- Le minacce ai sistemi di intelligenza artificiale risiedono principalmente nella configurazione, non nel modello. ambito dello strumento, le credenziali con cui viene eseguito un agente, un file di regole, un
.mcp/servers.jsonvoce. Nessuna di esse è raggiungibile dall'endpoint del modello, motivo per cui il solo red teaming non rileva alcun problema. - Gli attacchi basati sull'intelligenza artificiale si verificano principalmente attraverso le dipendenze, non attraverso il perimetro di sicurezza. Nomi di pacchetti fittizi registrati dagli aggressori, worm auto-propaganti che utilizzano le credenziali degli sviluppatori, chiavi di provider di intelligenza artificiale come obiettivo.
- Nove delle dieci domande riguardano argomenti specifici. Quali server MCP, quali agenti, quale ambito, quali credenziali, quale file di regole, quale pacchetto. Un documento di policy non risponde a nessuna di queste domande.
- Ognuno dei dieci condivide una precondizione. Non è possibile difendere una risorsa di intelligenza artificiale che non è mai stata mappata, il che rende la fase di scoperta precedente ai controlli, anziché successiva.
Quali sono i due tipi di minacce alla sicurezza legate all'intelligenza artificiale?
La maggior parte degli elenchi di minacce alla sicurezza legate all'IA confonde i due aspetti, ed è per questo che è difficile intervenire.
- Minacce ai sistemi di intelligenza artificiale Tratta la tua IA come un bersaglio. Qualcuno manipola un modello, altera le istruzioni che esegue o abusa dei permessi concessi a un agente. Il compito del difensore è il contenimento: ridurre ciò che un'IA compromessa può raggiungere.
- Attacchi guidati dall'intelligenza artificiale Trattate l'IA come uno strumento dell'attaccante. L'obiettivo è il software ordinario: dipendenze, credenziali, sistemi di compilazione, sviluppatori. Il compito del difensore è quello di rilevare le minacce rapidamente, perché le dinamiche economiche dell'attacco sono cambiate e il volume è aumentato.
Hanno bisogno di controlli diversi, responsabili diversi e prove diverse. Un team che ha sottoposto il proprio chatbot a un test di sicurezza (red teaming) non ha fatto nulla per contrastare l'abuso di risorse. Un team con un'eccellente gestione delle dipendenze potrebbe comunque eseguire un agente con accesso in scrittura ai repository di produzione e senza limiti di ambito. Entrambe sono minacce alla sicurezza legate all'IA. Nessuna delle due copre l'altra.
Minacce ai sistemi di intelligenza artificiale: le cinque più frequenti
01. Iniezione rapida che raggiunge un lavandino per utensili
Il contenuto non attendibile arriva, viene concatenato in un prompt di sistema e l'agente dall'altra parte può richiamare degli strumenti. Il prompt non è la vulnerabilità. La vulnerabilità risiede nel percorso che va dall'input non attendibile a una funzionalità pericolosa.
Ecco perché il solo filtraggio dei prompt delude. Indurisce un'estremità di una catena, mentre la domanda interessante è se una barriera di protezione si trovi da qualche parte tra l'input e la chiamata dello strumento. OWASP Top 10 per le domande di LLM Mantiene l'iniezione immediata in cima alla lista, ma la associa a un'eccessiva autonomia proprio per questo motivo.
Cosa cercare: input non attendibili che raggiungono un prompt di sistema, contesto di alimentazione del recupero senza sanificazione e sink di strumenti raggiungibili senza alcuna protezione intermedia.
02. Regole e file di abilità dannosi
Un file di regole è un testo semplice. È committed come documentazione e revisionato come documentazione e istruisce l'assistente su cosa fare. I caratteri a larghezza zero rendono le linee invisibili in un pull request differenza pur rimanendo perfettamente leggibile per l'agente.
ATLANTE MITRE Questo viene catalogato come backdoor del file delle regole, caso di studio AML.CS0041. Il revisore approva una convenzione di formattazione. L'agente legge un'istruzione per importare da un pacchetto controllato dall'attaccante e per non dire nulla al riguardo.
Cosa cercare: I file delle regole, i file delle competenze e i modelli di prompt vengono analizzati come codice anziché come testo, con rilevamento dei caratteri invisibili.
03. Configurazione non sicura del server MCP
Configurazione MCP È qui che un agente riceve i suoi ordini e dove si accumulano le credenziali. Entrambe le parti rappresentano un problema. La vulnerabilità CVE-2025-6514, resa nota nel luglio 2025, consisteva in una grave iniezione di comandi del sistema operativo in un bridge MCP ampiamente utilizzato, con un punteggio CVSS di 9.6, che consentiva l'esecuzione di comandi arbitrari sull'host client durante la connessione a un server non attendibile.
La parte relativa alle credenziali è peggiore perché è passiva. Una ricerca del 2026 ha rilevato oltre 24,000 segreti presenti nei file di configurazione di MCP su GitHub pubblico, di cui oltre 2,000 ancora validi.
Cosa cercare: Un inventario dei server MCP in uso, delle loro versioni, degli strumenti dichiarati e del rilevamento di segreti in esecuzione sui file di configurazione.
04. Eccessivo potere di agenzia
Un agente a cui vengono concessi ampi strumenti e credenziali di lunga durata rappresenta una vulnerabilità latente in attesa di un'occasione per escalation dei privilegi. Non è necessario che venga sfruttata alcuna falla perché ciò causi danni. Un agente confuso e uno compromesso possono causare danni simili quando entrambi dispongono di accesso in scrittura che non avrebbero mai dovuto avere.
Questo è l'elemento meno appariscente della lista e il più comune. Ha anche la soluzione più economica, ovvero la riduzione dell'ambito, che però viene applicata raramente perché nessuno è il responsabile della domanda.
Cosa cercare: Quali agenti esistono, cosa può invocare ciascuno di essi, con quali credenziali e se qualcuno ha approvato tale ambito di applicazione.
05. Modelli, set di dati e dipendenze dall'IA compromessi.
Lo stack di intelligenza artificiale è costruito su pacchetti standard e artefatti ospitati su server esterni. I modelli vengono scaricati da piattaforme pubbliche. I set di dati provengono da qualsiasi fonte. Entrambi presentano lo stesso problema di provenienza di qualsiasi dipendenza, con meno strumenti a disposizione e un controllo decisamente inferiore.
Cosa cercare: modelli, framework e set di dati trattati come componenti della catena di approvvigionamento, con la stessa analisi di composizione e lo stesso Tracciamento CVE come per tutte le altre dipendenze.
Attacchi basati sull'intelligenza artificiale: i cinque che stanno rivoluzionando la tua catena di approvvigionamento
06. Slopsquatting
Una ricerca presentata all'USENIX Security nel 2025 ha generato 2.23 milioni di campioni di codice su 16 modelli e ha scoperto che il 19.7% dei pacchetti consigliati non esisteva, producendo oltre 205,000 nomi illeggibili unici. Circa il 43% di questi nomi si è ripetuto in esecuzioni successive dello stesso prompt, rendendoli potenzialmente sfruttabili.
Gli aggressori non hanno più bisogno di compromettere un manutentore. Registrano il nome inventato dal tuo agente e attendono l'installazione. Il pacchetto non ha firma né avviso, perché è nuovo e nessuno l'ha mai visto prima.
Cosa cercare: Sistema di rilevamento malware basato sul comportamento anziché sulla reputazione, applicato a ogni dipendenza aggiunta da un agente.
07. Vermi della catena di approvvigionamento che si auto-propagano
Migliori worm npm di settembre 2025 Questo ha segnato il punto in cui le macchine degli sviluppatori sono diventate il meccanismo di diffusione anziché il bersaglio. Lo schema si è ripetuto su larga scala fino al 2026. Ogni credenziale di sviluppatore compromessa pubblica la successiva serie di pacchetti compromessi, e il raggio d'azione dell'esplosione si amplifica invece di aumentare.
Cosa cercare: attività editoriale anomala, insolita commit modelli e utilizzo delle credenziali che non corrispondono al normale comportamento dello sviluppatore.
08. Targeting delle credenziali di IA da parte degli stati nazionali
Nel marzo 2026, un pacchetto con circa 100 milioni di download settimanali è stato compromesso per un periodo di poche ore, con l'obiettivo di impossessarsi delle chiavi API di un fornitore di intelligenza artificiale. La finestra temporale è stata volutamente breve: sufficientemente lunga per raccogliere le informazioni, ma abbastanza breve da ridurre le possibilità di essere scoperti.
Le credenziali dell'IA sono ormai un obiettivo primario a sé stante, perché consentono di acquistare potenza di calcolo, accesso e un'identità plausibile. Gli attacchi volti a rubarle sono aumentati vertiginosamente tra la fine del 2025 e l'inizio del 2026.
Cosa cercare: Le chiavi dei provider di intelligenza artificiale vengono trattate come segreti, con le stesse procedure di rilevamento e revoca delle credenziali cloud.
09. Malware creato o installato utilizzando un LLM
Entro il 2026, si registrarono casi documentati di un modello linguistico utilizzato come arma per inserire codice dannoso all'interno del flusso di lavoro di un agente. Il punto non è che il malware fosse nuovo, bensì che l'autore ha smesso di rappresentare un collo di bottiglia e, di conseguenza, la quantità di codice dannoso dall'aspetto plausibile a disposizione di un attaccante è aumentata.
Cosa cercare: rivelazione che non dipende dall'aver già visto il campione in precedenza.
10. Revisione del collasso della capacità
Questo non è un attacco, ed è per questo che è l'ultimo e il più importante. Quando un agente produce mille file in una settimana, la revisione del codice smette di essere un controllo e diventa una coda. Ogni altra minaccia in questo elenco diventa più facile quando l'ultimo controllo umano viene sovraccaricato.
Cosa cercare: I risultati vengono classificati in base alla possibilità di sfruttamento piuttosto che alla gravità effettiva, in modo che solo il piccolo numero di vulnerabilità che minacciano la produzione raggiunga effettivamente uno sviluppatore.
Die mappa è composta da dieci minacce. Cosa fare riguardo a ciascuna richiede più di un post del blog, quindi abbiamo avuto una conversazione approfondita. In questo episodio di SafeDev parla, Jesús Cuadrado, CEO di Xygeni, si siede con Atanas Nikolov, esperto di DevSecOps e SSDLC Responsabile tecnico specializzato in malware polimorfico, iniezione di prompt, manomissione di modelli e ciò che effettivamente resiste a tali attacchi. Senza modulo, non c'è porta.
Perché non è possibile difendere risorse di intelligenza artificiale non mappate?
Rileggendo le dieci domande, lo schema diventa evidente. Nove di esse riguardano elementi specifici: quali server MCP, quali agenti, quale ambito, quali credenziali, quale file di regole, quale pacchetto.
Nessuna di queste domande può trovare risposta in un documento di policy. Le risposte si trovano in un inventario, e la maggior parte delle organizzazioni non ne possiede uno. L'IA è arrivata grazie a sviluppatori che hanno agito rapidamente, senza un ticket, un processo di approvvigionamento o una voce nel repository che la identificasse come IA.
Questo rende la mappatura una condizione preliminare piuttosto che il primo passo. Un programma di sicurezza contro le minacce all'IA che inizia con i controlli li applicherà all'IA di cui è a conoscenza, un sottoinsieme che non può quantificare. La fase di scoperta deve venire prima: modelli, framework, set di dati, endpoint di inferenza, agenti, server MCP, competenze, prompt e gli strumenti di programmazione IA effettivamente utilizzati dagli sviluppatori, con le relazioni tra di essi, perché una risorsa isolata fornisce ben poche informazioni e il rischio si concentra nella catena.
Migliori Quadro di gestione del rischio AI del NIST Mette la mappa prima della misura e della gestione per lo stesso motivo. È la funzione meno interessante del framework e quella da cui dipende tutto il resto.
Quali minacce alla sicurezza legate all'intelligenza artificiale dovresti affrontare per prime?
Non la più sofisticata. La più accessibile.
- Questa settimana: Conta i tuoi server MCP ed esegui un'analisi dei segreti sui loro file di configurazione. La minaccia 03 è quella con il più alto rapporto esposizione/sforzo nell'elenco, e quasi nessuno l'ha ancora esaminata.
- Questo mese: Individua i tuoi agenti e annota cosa può fare ciascuno di essi e con quali credenziali. Questo risolve la minaccia 04, che è la più comune e la più economica da contrastare.
- Questo trimestre: Applica la scansione comportamentale del malware a ogni dipendenza aggiunta da un agente. Questo copre contemporaneamente le minacce 06, 07 e 09, poiché tutte e tre eludono i controlli basati sulla reputazione essendo nuove.
Tutto il resto può aspettare dopo quei tre, perché tutto il resto presuppone che tu sappia già cosa hai.
Le organizzazioni che gestiranno bene le minacce alla sicurezza dell'IA nel 2027 non saranno quelle con le migliori valutazioni dei modelli. Saranno quelle in grado di rispondere, in un qualsiasi martedì, a quale IA è in esecuzione nel loro software e a cosa è consentito accedere. Questa è la posizione Xygeni è stato costruito attorno a: scoperta continua di ogni risorsa AI attraverso i repository e pipelines, rischio valutato rispetto ai framework che i vostri revisori già riconoscono e screening della catena di fornitura che individua ciò che non ha ancora una firma.
Dieci minacce, due categorie, una mappa sottostante a entrambe.
FAQ
Le minacce alla sicurezza derivanti dall'intelligenza artificiale sono davvero diverse dalle normali minacce alla sicurezza delle applicazioni?
In parte. Le conseguenze sono note: esecuzione di codice dannoso, furto di credenziali, esposizione dei dati. Ciò che cambia è il punto di ingresso e la velocità. I file di configurazione che prima erano inerti ora contengono istruzioni su cui qualcosa agisce, e il costo per un aggressore di produrre codice dannoso convincente si è ridotto. I controlli esistenti sono ancora validi; semplicemente non coprono più l'intera superficie.
L'analisi dei nostri modelli tramite il metodo del "red teaming" risolve la maggior parte di queste minacce?
Affronta in parte uno di questi problemi. Il red teaming risponde alla domanda se un modello può essere indotto a fare qualcosa che dovrebbe rifiutare, il che è effettivamente utile. Non può visualizzare l'ambito dello strumento, le credenziali, il file delle regole o la configurazione dell'MCP, perché nessuno di questi è raggiungibile tramite l'endpoint del modello. Un report red teaming pulito e un agente con privilegi eccessivamente elevati e pericolosi coesistono senza contraddizione.
Quale di queste minacce alla sicurezza legate all'intelligenza artificiale è la più sottovalutata?
Si tratta di un'eccessiva autonomia, di gran lunga. Non esiste una vulnerabilità CVE, né un exploit da dimostrare, né un fornitore che venda un prodotto dedicato, quindi non genera alcuna urgenza. Rappresenta inoltre la differenza tra un incidente circoscritto e uno non circoscritto, perché è la portata che determina quanto lontano si propaga un evento dopo il primo errore.
In che modo gli attacchi basati sull'intelligenza artificiale modificano ciò che dovremmo misurare?
Spostano la metrica utile dalla gravità al tempo. Quando i pacchetti dannosi vengono generati più velocemente di quanto vengano pubblicate le firme, "quante critici sono aperti" è meno importante di "quanto velocemente viene segnalato qualcosa di nuovo". Misurate il divario tra l'ingresso di una dipendenza nel vostro codice sorgente e la sua analisi, e il divario tra la segnalazione di una vulnerabilità e il momento in cui raggiunge uno sviluppatore in grado di intervenire.
