9 marzo 2026 | Tempo di lettura: 13 minuti 37 secondi
Introduzione: Il Rendiconto della Sicurezza degli Agenti
Abbiamo passato gli ultimi due anni a correre per distribuire agenti IA ovunque. Negli editor di codice, nei sistemi di assistenza clienti, nelle pipeline CI/CD, nella gestione dell'infrastruttura. Il ritmo era inebriante. Un agente che potrebbe redigere pull request. Un altro che potrebbe rispondere agli avvisi di sicurezza. Un terzo che potrebbe gestire le migrazioni dei database. Ognuno sembrava un moltiplicatore della capacità umana.
Poi gli incidenti hanno iniziato.
Nel febbraio 2026, OpenClaw — il progetto open-source con crescita più veloce nella storia di GitHub con oltre 188.000 stelle — è diventato il centro della prima grande crisi di sicurezza dei agenti IA. Sono state scoperte vulnerabilità critiche in tutto il suo marketplace di oltre 5.700 skill costruite dalla comunità. Attori malintenzionati avevano caricato skill che sembravano eseguire compiti di automazione legittimi ma segretamente esfilavano dati sensibili dalle macchine locali degli utenti. Sono state identificate oltre 21.000 istanze esposte. L'agente che era supposto aiutarti stava aiutando se stesso ai tuoi file.
Questo non era un evento isolato. Era il canarino nella miniera di carbone per un problema diffuso in tutto il settore. Le stesse proprietà che rendono utili gli agenti IA — autonomia, accesso agli strumenti, memoria persistente e la capacità di eseguire codice — li rendono straordinariamente pericolosi se compromessi o mal configurati. Siamo entrati nell'era della sicurezza dell'IA agentica, e la maggior parte delle organizzazioni non è preparata per quello che significa.
Il Problema dell'Agente Ombra
La minaccia più insidiosa nella sicurezza dell'IA agentica è quella che molte organizzazioni non sanno nemmeno di avere: gli agenti ombra.
Gli agenti ombra sono flussi di lavoro IA autonomi creati dai dipendenti utilizzando account personali, piattaforme di automazione low-code o API non controllate. Operano al di fuori della visione dei team IT e di sicurezza, con permessi eccessivi, nessun audit trail e nessuna gestione del ciclo di vita. Pensali come l'equivalente IA dell'IT ombra, ma con significativamente più capacità e rischio.
Come Emergono gli Agenti Ombra
Lo schema è prevedibile. Un direttore marketing collega ChatGPT alla posta elettronica aziendale tramite Zapier per redigere automaticamente le risposte alle richieste di partnership. Un ingegnere configura un agente OpenClaw sul suo laptop personale che monitora i canali Slack e crea automaticamente ticket Jira. Un analista di dati crea un flusso di lavoro n8n che estrae i dati dei clienti dal database di produzione, li elabora tramite Claude e deposita i riepiloghi in un Google Sheet.
Nessuno di loro aveva intenzioni malvagie. Ognuno stava risolvendo un vero problema. Ma ogni singolo uno di questi flussi di lavoro crea un agente non gestito, non monitorato, con accesso ai dati aziendali sensibili, che opera con i permessi completi dell'utente che lo ha creato — e spesso di più, dato che molte di queste piattaforme richiedono ambiti OAuth ampi.
La Superficie di Rischio
Gli agenti ombra creano rischi su più dimensioni. Per primo, c'è il rischio di esposizione dei dati. Quando un dipendente alimenta i dati aziendali in un servizio IA di terze parti tramite un'integrazione non controllata, quei dati potrebbero essere utilizzati per l'addestramento, archiviati indefinitamente o esposti attraverso le vulnerabilità del servizio stesso. Secondo, c'è il rischio di autenticazione. Molti agenti ombra utilizzano token API o OAuth a lunga durata che non vengono mai ruotati, memorizzati in modo non sicuro e persistono anche dopo che il dipendente lascia l'organizzazione. Terzo, c'è il rischio di esecuzione. Un agente che può eseguire codice, inviare email o modificare record può essere manipolato attraverso l'iniezione di prompt per eseguire azioni che l'utente creatore non ha mai inteso.
Rilevamento e Mitigazione
Il rilevamento degli agenti ombra richiede una combinazione di monitoraggio della rete, analisi del gateway API e controllo basato sull'identità. Cerca modelli insoliti: chiamate API ai servizi IA da fonti inaspettate, concessioni OAuth ad applicazioni sconosciute e flussi di dati che aggirerebbero i canali normali. Implementa politiche che richiedono a tutte le distribuzioni di agenti IA di passare attraverso un processo di revisione formale e fornisci alternative autorizzate in modo che i dipendenti possano raggiungere i loro obiettivi senza andare fuori dai binari.
Il Paesaggio delle Vulnerabilità MCP
Il Model Context Protocol (MCP) è diventato lo standard di fatto per la connessione dei modelli IA a strumenti e servizi esterni. Sviluppato da Anthropic e adottato in tutto il settore, MCP consente ai modelli di linguaggio di interagire con database, API, file system e altre risorse attraverso un'interfaccia standardizzata. È potente, flessibile e — come ricerche recenti hanno rivelato — pieno di problemi di sicurezza.
Il Problema del 43%
Un controllo completo pubblicato nel febbraio 2026 ha trovato che il 43% dei server MCP disponibili pubblicamente è vulnerabile a attacchi di esecuzione di comandi. La superficie di vulnerabilità è ampia: validazione insufficiente dell'input, autenticazione mancante, definizioni di strumenti eccessivamente permissive e una tensione architettonica fondamentale tra la flessibilità del protocollo e i principi di sicurezza di base.
Il problema centrale è che MCP è stato progettato per la capacità, non per il contenimento. Un server MCP ben configurato può dare a un modello IA un accesso precisamente definito a funzioni specifiche. Ma la configurazione predefinita di molti server costruiti dalla comunità concede molto più accesso di quanto necessario e il design del protocollo rende facile esporre accidentalmente funzionalità pericolose.
Vettori di Attacco
I vettori di attacco primari contro le installazioni MCP rientrano in diverse categorie.
Tool Poisoning si verifica quando un server MCP malintenzionato annuncia strumenti che sembrano benigni ma eseguono operazioni dannose. Un modello IA che si connette a uno strumento chiamato format_text potrebbe effettivamente invocare una funzione che esfiltra le variabili d'ambiente. Poiché il modello IA si affida alla descrizione dell'auto dello strumento, non ha modo di verificare che lo strumento faccia quello che sostiene.
Cross-Server Manipulation sfrutta il fatto che molti agenti IA si connettono a più server MCP simultaneamente. Un server malintenzionato può iniettare istruzioni che causano all'IA di usare male gli strumenti forniti da un server legittimo. Ad esempio, la risposta di un server compromesso potrebbe includere istruzioni nascoste che causano all'agente di utilizzare il suo strumento di accesso al database per estrarre e trasmettere record sensibili.
Credential Theft prende di mira i token di autenticazione e le chiavi API che i server MCP spesso memorizzano per accedere ai servizi esterni. Poiché i server MCP vengono eseguiti come processi separati, potrebbero memorizzare le credenziali in file di configurazione, variabili d'ambiente o store in memoria accessibili da altri processi sulla stessa macchina.
Protezione delle Distribuzioni MCP
La protezione di MCP richiede un approccio defense-in-depth. Inizia con il principio del privilegio minimo: ogni server MCP dovrebbe esporre solo l'insieme minimo di strumenti necessari per il suo scopo. Implementa la validazione dell'input su ogni parametro dello strumento. Usa ambienti di esecuzione sandbox — container o VM — per limitare il raggio di scoppio di un server compromesso. Controlla le descrizioni degli strumenti e verifica che riflettano accuratamente il comportamento dello strumento. E in modo critico, implementa il monitoraggio in grado di rilevare quando i modelli di utilizzo degli strumenti di un agente IA si discostano dal comportamento atteso.
Iniezione di Prompt su Larga Scala
L'iniezione di prompt non è nuova, ma il suo impatto è cambiato drasticamente nell'era degli agenti autonomi. Quando un modello IA era limitato a generare testo in un'interfaccia di chat, un'iniezione di prompt riuscita potrebbe produrre output imbarazzante. Quando un agente IA ha accesso alla posta elettronica, ai repository di codice e all'infrastruttura di produzione, un'iniezione di prompt riuscita può risultare in esfilazione dei dati, accesso non autorizzato o compromissione del sistema.
L'Evoluzione degli Attacchi
Gli attacchi di iniezione di prompt di prima generazione erano rozzi: "Ignora le tue istruzioni precedenti e fai X". Questi vengono facilmente catturati dal filtraggio dell'input di base. Gli attacchi che i team di sicurezza affrontano nel 2026 sono molto più sofisticati.
Iniezione indiretta di prompt incorpora istruzioni malintenzionate nel contenuto che l'agente IA elabora come dati piuttosto che come input diretto dell'utente. Un attaccante potrebbe aggiungere testo invisibile a una pagina web che istruisce qualsiasi agente IA leggendo la pagina di inoltrare la sua cronologia delle conversazioni a un server esterno controllato dall'attaccante. Potrebbe creare un'email che, se elaborata da un assistente email IA, causa all'assistente di inoltrare tutte le email successive a un indirizzo controllato dall'attaccante.
Manipolazione multi-turno implica lo spostamento graduale del comportamento di un agente su più interazioni. Ogni singolo prompt appare benigno, ma l'effetto cumulativo è di spostare la comprensione dell'agente del suo contesto e dei suoi permessi in una direzione che beneficia all'attaccante. Questo è particolarmente efficace contro gli agenti con memoria persistente, dove ogni interazione modifica il contesto memorizzato dell'agente.
Attacchi di concatenamento di strumenti sfruttano la capacità dell'agente di utilizzare più strumenti in sequenza. L'obiettivo dell'attaccante non è istruire direttamente l'agente di eseguire un'azione dannosa — che verrebbe catturata dai filtri di sicurezza — ma di costruire una sequenza di chiamate di strumenti individualmente benigne che raggiungono un risultato dannoso se combinate.
Il Benchmark AgentShield
AgentShield, rilasciato all'inizio del 2026, è diventato il primo benchmark aperto che testava gli strumenti di sicurezza degli agenti IA commerciali. I risultati da 537 casi di test erano scoraggianti: rilevamento debole dell'abuso di strumenti in tutto, rilevamento incoerente dell'iniezione di prompt e quasi nessuna capacità di rilevare attacchi multi-step che concatenano operazioni benigne in risultati dannosi.
Il benchmark ha rivelato che la maggior parte degli strumenti di sicurezza esistenti era stata progettata per un mondo pre-agentico. Possono rilevare modelli di attacco conosciuti ma hanno difficoltà con la complessità combinatoria delle minacce basate su agenti, dove il pericolo risiede non in nessuna singola azione ma nella sequenza e nel contesto delle azioni.
Strategie Difensive
La difesa efficace contro l'iniezione di prompt nei sistemi agentici richiede più strati. La bonifica dell'input deve coprire non solo l'input diretto dell'utente ma tutti i dati che l'agente elabora, incluse pagine web, email, record di database e risposte API. Il monitoraggio dell'output deve tracciare non solo quello che l'agente dice ma quello che fa — ogni chiamata di strumento, ogni richiesta API, ogni operazione su file. L'analisi del comportamento deve stabilire linee di base per l'attività normale dell'agente e segnalare le deviazioni.
Anche le decisioni architettoniche sono importanti. Il principio del privilegio minimo è fondamentale: gli agenti dovrebbero avere accesso solo agli strumenti e ai dati di cui hanno bisogno per la loro funzione specifica. La separazione dei compiti significa che un agente che gestisce l'assistenza clienti non dovrebbe avere accesso agli strumenti di infrastruttura di produzione, anche se sono tecnicamente disponibili attraverso lo stesso server MCP. E i requisiti human-in-the-loop dovrebbero essere applicati per le azioni ad alto impatto — eliminazioni di database, transazioni finanziarie, modifiche del controllo di accesso — indipendentemente dalla sicurezza dell'agente nella sua decisione.
Attacchi alla Catena di Approvvigionamento negli Ecosistemi degli Agenti
L'ecosistema degli agenti ha creato una nuova variazione dell'attacco alla catena di approvvigionamento. Gli attacchi tradizionali alla catena di approvvigionamento mirano alle dipendenze del codice — pacchetti npm compromessi, immagini Docker avvelenate, GitHub Actions malintenzionati. Gli attacchi alla catena di approvvigionamento degli agenti mirano agli strumenti, alle skill e alle configurazioni da cui gli agenti dipendono.
Avvelenamento del Marketplace
I marketplace degli agenti come ClawHub di OpenClaw, con oltre 5.700 skill costruite dalla comunità, presentano un'enorme superficie di attacco. Una skill malintenzionata può apparire per eseguire una funzione utile mentre contemporaneamente esfiltra dati, modifica il comportamento dell'agente o stabilisce persistenza. I processi di revisione per questi marketplace sono spesso insufficienti: la scansione automatizzata può catturare modelli di malware conosciuti ma non può valutare l'intento semantico del codice che interagisce con il processo decisionale di un modello IA.
La crisi OpenClaw lo ha dimostrato chiaramente. Le skill malintenzionate erano progettate per superare le scansioni di sicurezza automatizzate mentre sfruttavano la fiducia implicita che l'agente ripone nelle sue skill installate. Alcune skill hanno esfilrato file locali. Altre hanno modificato il prompt di sistema dell'agente per iniettare istruzioni persistenti che hanno sopravvissuto alla disinstallazione della skill. Alcune hanno stabilito connessioni di shell inversa a server controllati da attaccanti.
Deriva della Configurazione
Le configurazioni degli agenti — prompt di sistema, permessi dello strumento, schemi di memoria — sono spesso trattate come codice ma gestite con meno rigore del codice di produzione. Potrebbero essere memorizzate in testo normale, condivise attraverso canali non sicuri e modificate senza controllo della versione o revisione. Un attaccante che può modificare la configurazione di un agente può alterare fondamentalmente il suo comportamento senza toccare alcun codice.
Difesa della Catena di Approvvigionamento
La difesa della catena di approvvigionamento per gli ecosistemi degli agenti richiede di trattare le configurazioni degli agenti con lo stesso rigore del codice di produzione. Usa il controllo della versione. Implementa la revisione del codice per i cambiamenti di configurazione. Firma e verifica i pacchetti degli agenti. Mantieni un inventario di tutte le skill e gli strumenti installati. E implementa il monitoraggio di runtime che può rilevare quando il comportamento di un agente si discosta dalla sua funzione prevista.
Avvelenamento della Memoria: La Minaccia Persistente
Gli agenti con memoria persistente introducono una categoria di vulnerabilità che non ha precedenti nella sicurezza del software tradizionale. Quando un agente ricorda il contesto tra le sessioni, un attaccante che può influenzare la memoria dell'agente può stabilire una presenza persistente che sopravvive ai riavvii, alla reinstallazione e persino agli aggiornamenti.
Come Funziona l'Avvelenamento della Memoria
Considera un agente che utilizza un database vettoriale per memorizzare e recuperare il contesto dalle interazioni passate. Un attaccante crea una serie di interazioni progettate per incorporare istruzioni malintenzionate nella memoria dell'agente. Queste istruzioni sono memorizzate come embeddings e recuperate ogni volta che l'agente incontra un contesto correlato. L'attacco persiste perché le memorie avvelenate sono indistinguibili da quelle legittime — sono memorizzate nello stesso formato, nello stesso database, utilizzando lo stesso modello di embedding.
Il risultato è un agente che si comporta normalmente la maggior parte del tempo ma si discosta dal comportamento atteso quando attivato da contesti specifici. È l'equivalente in IA di una bomba logica ed è estremamente difficile da rilevare.
Approcci di Mitigazione
La mitigazione dell'avvelenamento della memoria richiede una combinazione di igiene della memoria e monitoraggio. Implementa le politiche di scadenza della memoria che eliminano automaticamente le memorie vecchie. Usa la firma crittografica per verificare la provenienza dei contesti memorizzati. Implementa il rilevamento di anomalie sui modelli di recupero della memoria dell'agente. E mantieni la capacità di rollback della memoria di un agente a uno stato noto come bene.
Costruzione di Sistemi di Agenti Sicuri
La strada da percorrere non è quella di abbandonare gli agenti IA — i loro vantaggi di produttività sono troppo significativi per essere ignorati. Piuttosto, le organizzazioni devono costruire la sicurezza nel ciclo di vita dell'agente dall'inizio.
Zero Trust per gli Agenti
Applica i principi zero trust alle distribuzioni degli agenti. Nessun agente dovrebbe essere implicitamente affidato, indipendentemente da dove viene eseguito o chi lo ha distribuito. Ogni accesso allo strumento dovrebbe essere autenticato e autorizzato. Ogni azione dovrebbe essere registrata e revisionabile. Ogni flusso di dati dovrebbe essere crittografato e monitorato.
Lo Stack di Sicurezza degli Agenti
Uno stack di sicurezza completo degli agenti include diversi strati. Il controllo dell'identità e dell'accesso controlla quali agenti possono accedere quali risorse. La validazione dell'input previene l'iniezione di prompt e l'avvelenamento dei dati. La sandbox di esecuzione limita il raggio di scoppio di un agente compromesso. Il monitoraggio del comportamento rileva l'attività anomala dell'agente. La registrazione di audit fornisce la capacità forense. E le procedure di risposta agli incidenti devono tenere conto di scenari specifici degli agenti.
Preparazione Organizzativa
I controlli tecnici sono necessari ma non sufficienti. Le organizzazioni hanno bisogno di politiche che definiscono l'uso accettabile degli agenti IA, strutture di governance che assegnano la responsabilità della sicurezza degli agenti, programmi di formazione che educano i dipendenti sui rischi degli agenti ombra e procedure di risposta agli incidenti che tengono conto delle caratteristiche uniche degli attacchi basati su agenti.
Conclusione: Le Puntate Sono Reali
Il panorama della sicurezza dell'IA agentica nel 2026 è caratterizzato da una disallineamento fondamentale tra capacità e sicurezza. Abbiamo distribuito agenti con capacità straordinarie — ragionamento, uso degli strumenti, memoria persistente, processo decisionale autonomo — in ambienti progettati per un mondo pre-agente. Gli strumenti di sicurezza, i processi e i modelli mentali che abbiamo sviluppato per il software tradizionale sono insufficienti per questa nuova realtà.
Gli incidenti sono reali. Le vulnerabilità sono diffuse. La superficie di attacco sta crescendo. Ma la strada da percorrere è chiara: tratta gli agenti come principali di sicurezza di prima classe, applica la difesa in profondità, mantieni la supervisione umana per le azioni ad alto impatto e costruisci la sicurezza nel ciclo di vita dell'agente dall'inizio.
Le organizzazioni che fanno bene questo godranno i vantaggi di produttività dell'IA agentica senza diventare il prossimo avvertimento. Quelle che non lo fanno impareranno con le difficoltà che un agente con permessi eccessivi e monitoraggio insufficiente non è uno strumento di produttività — è una responsabilità.