Il 3 agosto 2026 l'OWASP — la fondazione che pubblica gli elenchi di rischi presi come riferimento per la sicurezza delle applicazioni — ha aggiornato la sua lista dei dieci rischi principali per le applicazioni costruite sui modelli linguistici.
In cima è rimasta la voce dell'anno prima. Quella che si è mossa di più è al terzo posto, e dodici mesi fa era sesta: excessive agency, che si potrebbe tradurre con autonomia eccessiva. Vuol dire un sistema a cui è stato dato troppo potere di agire da solo.
Non è salita perché qualcuno ha cambiato idea. È salita perché per la prima volta la lista non nasce solo dal voto degli esperti: tre quarti del peso restano al voto, un quarto viene dagli incidenti realmente accaduti. Ne sono stati raccolti 7.714 da banche dati pubbliche di vulnerabilità e da un archivio di danni causati dall'AI; 6.639 erano documentati abbastanza da poter essere classificati. E su questa voce il voto e gli incidenti dicono la stessa cosa — è nelle installazioni con agenti che i danni stanno atterrando.
Se qualcuno in azienda ha collegato un assistente AI alla posta, ai documenti o al gestionale, questa è la notizia che ti riguarda.
Come ci si arriva
Quasi mai con una decisione.
Serviva smaltire l'arretrato. Qualcuno ha collegato l'assistente alla casella, ha funzionato, e adesso legge i messaggi in arrivo, prepara le risposte e archivia gli allegati. Il passo dopo è già in discussione: dargli accesso al gestionale, così aggiorna gli ordini da solo.
Nessuna riunione, nessuna delibera. Solo una cosa che funzionava e che è stata lasciata crescere.
È il momento buono per fermarsi cinque minuti. Non perché sia sbagliato — funziona davvero — ma perché la domanda utile non è quanto tempo fa risparmiare. È un'altra: cosa può fare da solo, e chi risponde di quello che fa.
Un chatbot e un agente non sono lo stesso prodotto
Sembrano lo stesso oggetto con due tacche di autonomia. Non lo sono, e la differenza non si vede dal listino.
Il primo produce testo, e il testo lo leggi tu prima che diventi qualcosa. Il secondo produce azioni: apre e scrive file, chiama servizi esterni, manda messaggi a tuo nome. Fra i due c'è un passaggio di responsabilità, non un aggiornamento di versione.
L'OWASP lo dice in modo netto, e vale la pena riportarlo perché è il confine che conta: nel momento in cui il modello diventa un attore — con strumenti che può chiamare, memoria che si porta dietro fra una sessione e l'altra, e conseguenze che mette in moto a valle — il rischio cambia categoria. Tanto che gli hanno dedicato una lista separata.
Per un agente, il contenuto e le istruzioni sono lo stesso testo
Qui c'è il punto tecnico da cui discende tutto il resto, e non è ovvio a chi firma la decisione.
Quando chiedi a un agente di controllare la posta, lui riceve un blocco di caratteri. Una parte è la tua richiesta — riassumi i messaggi di oggi. Un'altra parte è il messaggio da riassumere. Non arrivano su canali separati e non hanno un'etichetta che dica quale delle due comanda. Sono frasi in fila.
Chi attacca lo sfrutta da anni. Si chiama prompt injection: nascondere, dentro un contenuto che l'agente prima o poi leggerà — un'email, un PDF, la pagina di un fornitore — una riga scritta per lui e non per te.
E c'è un dettaglio che rende la cosa peggiore di come suona. Nella definizione dell'OWASP, quelle istruzioni non devono essere visibili né leggibili da un essere umano: basta che il modello le interpreti. Testo bianco su fondo bianco, corpo due, una nota nel codice della pagina che il browser non mostra. Tu apri il messaggio e non c'è niente. L'agente lo legge e trova un compito.
Un caso con un numero di catalogo
Non è uno scenario da presentazione. Ha un identificatore pubblico e permanente, che è il modo migliore per distinguere un rischio documentato da un allarme. Si chiama CVE: il numero con cui una vulnerabilità entra in un catalogo internazionale e resta consultabile da chiunque, anche anni dopo.
CVE-2025-32711, pubblicata l'11 giugno 2025, riguarda Microsoft 365 Copilot. La descrizione ufficiale è di quattro righe: un'iniezione di comandi che permette a un attaccante non autorizzato di far uscire informazioni attraverso la rete. I ricercatori che l'hanno scoperta, di Aim Security, l'hanno chiamata EchoLeak.
Il meccanismo è quello descritto sopra. Arriva un'email dall'aspetto normale, con dentro istruzioni invisibili a chi legge. Nessuno la apre, nessuno clicca niente. Più tardi qualcuno chiede a Copilot una cosa qualsiasi di lavoro; l'assistente, per rispondere, passa in rassegna anche quel messaggio, esegue le istruzioni che ci trova, va a leggere documenti interni e ne fa uscire il contenuto.
Microsoft l'ha classificata 9,3 su 10 — critica — e l'ha corretta sui propri server, senza che i clienti dovessero fare nulla. Non risultano casi di sfruttamento reale. Il registro pubblico statunitense che tiene il catalogo, e che rifà la valutazione per conto proprio, le ha assegnato 7,5: un disaccordo che è normale e che vale la pena conoscere, perché i due numeri circolano entrambi.
Quello che conta qui non è la gravità. È che la vittima non ha sbagliato niente. Non ha aperto un allegato, non ha inserito una password su una pagina falsa, non ha ignorato un avviso. Ha usato l'assistente per quello che serviva.
Perché isolarlo non chiude la questione
La prima reazione, quando lo si capisce, è isolare: una macchina separata, un'area di lavoro chiusa, le chiavi fuori dalla sua portata. È giusto, ed è il primo passo. Ma non chiude la questione, e vale la pena capire perché.
L'isolamento serve contro una variante sola: quella in cui l'agente va a prendere qualcosa che non doveva vedere. Se le credenziali non sono leggibili, quell'attacco muore lì.
Solo che un agente isolato conserva intatti i poteri che gli hai dato di proposito, e sono quelli il bersaglio più comodo. Mandare un'email non è un'effrazione: è il suo mestiere. Cancellare un file nel proprio spazio di lavoro nemmeno. Autorizzare un pagamento che è stato autorizzato a fare, tantomeno.
Sulla possibilità di chiudere il problema alla radice l'OWASP è esplicito: non è chiaro che esistano metodi infallibili di prevenzione, perché il comportamento dei modelli è statistico per costruzione. La riga con cui i curatori aprono l'edizione di quest'anno è la conclusione pratica di quella frase, e conviene leggerla per intero:
«Smettete di provare a costruire un modello che non si possa ingannare. Costruite il sistema attorno, in modo che quando il modello viene ingannato — e verrà ingannato — non si rompa niente di importante.»
Non stai proteggendo una cassaforte da uno scasso. Stai decidendo quali ordini un collaboratore molto veloce può eseguire senza chiederti conferma.
Tre domande, prima di scegliere lo strumento
Sono tre decisioni di architettura. Prese prima, costano una riunione; prese dopo, costano una riprogettazione.
Quali azioni può compiere senza chiedere. Non è una risposta unica: è una riga per categoria. Leggere e riassumere può stare in autonomia. Preparare una risposta può stare in autonomia, purché resti in bozza. Inviare, pagare, cancellare, installare qualcosa: solo dopo un consenso esplicito, uno per volta. Fra le contromisure che l'OWASP elenca, quella umana è il fermo di sicurezza finale — quello che regge quando le altre cedono. A patto che chi conferma legga davvero che cosa sta approvando: un «ok» distratto vale come nessun fermo.
A nome di chi parla. Nel momento in cui gli dai la casella di posta, gli dai la tua firma. Chi riceve il messaggio non ha modo di sapere che non l'hai scritto tu, e nemmeno tu ce l'hai, a meno di tenerne traccia. Un agente che può rispondere ai colleghi ma non può scrivere a un cliente o a un fornitore senza un tuo ok è un altro oggetto rispetto a uno che ha ricevuto la casella e basta.
Dove vivono le credenziali. La regola è che l'agente non veda mai una chiave in chiaro, e che ogni accesso che gli concedi sia il più stretto possibile: sola lettura finché non serve scrivere, un servizio alla volta, mai la chiave buona che apre tutto. È il principio del privilegio minimo, che in sicurezza informatica esiste da decenni; qui cambia solo a chi si applica.
Il pezzo che si dimentica: la memoria
C'è una variante più lenta, e più difficile da vedere.
Un agente che lavora nel tempo si scrive delle note, per non ricominciare da zero a ogni sessione. Un contenuto ostile può quindi non chiedergli niente adesso: può farsi annotare. Le fatture di questo fornitore vanno pagate senza conferma. Da quel momento la riga non arriva più da fuori — è nei suoi appunti, e assomiglia a una cosa che gli hai detto tu.
Ha un nome nella classificazione dell'OWASP dedicata agli agenti, dove è la prima minaccia dell'elenco: memory poisoning, avvelenamento della memoria. Le contromisure che indica sono le stesse che si userebbero per un archivio: validare quello che ci entra, tenere separate le sessioni, conservare istantanee che permettano di tornare indietro quando ci si accorge della contaminazione.
Il motivo per cui merita attenzione separata è di durata. Un tentativo puntuale lo intercetti una volta. Uno finito in memoria lavora per settimane, e quando te ne accorgi devi ricostruire da quando.
Cosa significa per come lavoriamo
Su questo non abbiamo una scorciatoia da vendere. Nessuno strumento risolve la questione, perché la questione non è tecnica fino in fondo: è dove tracci la linea fra quello che l'agente fa da solo e quello per cui deve chiedere.
Quello che possiamo dire è come la affrontiamo. DigiSense®, il framework su cui costruiamo le implementazioni con AI, sensori e robot, tiene separati l'acquisizione dei dati, l'elaborazione e il controllo di quello che succede fuori. Non è nato per questo — è nato perché tre livelli distinti si aggiornano indipendentemente. Ma l'effetto è quello che serve qui: il punto in cui un'azione esce verso il mondo è uno solo, ed è un posto dove si può mettere una conferma, un registro, un limite. Se quel punto è sparso in dieci moduli, non c'è nessuna linea da tracciare — e nemmeno da controllare dopo.
Vale anche per la scelta di tenere il modello in sede invece che su un servizio esterno. Non è una questione di sfiducia: è che il perimetro puoi disegnarlo solo dove arrivi.
Se stai valutando di dare a un assistente AI accesso alla posta, ai documenti o al gestionale, la conversazione utile è prima, e dura poco: quali azioni vuoi che compia da solo, e cosa succede il giorno in cui ne compie una che non avevi previsto.
Chi scrive è l'autore di OpenClaw — la guida completa, manuale gratuito sugli agenti autonomi, da cui viene parte del materiale di questo articolo.
Fonti
- OWASP Top 10 for LLM Applications 2026 — OWASP GenAI Security Project, 3 agosto 2026 — edizione corrente della lista. Da qui vengono le posizioni citate, i due conteggi degli incidenti, la ripartizione fra voto e dati e la citazione, che sta nella lettera dei curatori in apertura.
- OWASP 2026 LLM Top 10: «The model will be fooled» — Help Net Security, 6 agosto 2026 — sintesi giornalistica degli spostamenti fra l'edizione 2025 e quella 2026.
- LLM01:2025 Prompt Injection — OWASP GenAI Security Project — definizione, tipi diretto e indiretto, contromisure e il limite dichiarato sulla prevenzione.
- LLM06:2025 Excessive Agency — OWASP GenAI Security Project — la voce nella posizione che occupava prima dell'edizione 2026.
- Agentic AI — Threats and Mitigations, OWASP Agentic Security Initiative, 17 febbraio 2025 — le minacce specifiche degli agenti, fra cui l'avvelenamento della memoria.
- CVE-2025-32711 — National Vulnerability Database — scheda ufficiale della vulnerabilità, con le due valutazioni di gravità e i riferimenti.
- Aim Labs, «EchoLeak» — la pubblicazione dei ricercatori che hanno segnalato la vulnerabilità, citata dalla scheda CVE.
- NIST AI 100-2e2025, «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations», marzo 2025 — la tassonomia di riferimento per gli attacchi ai sistemi di apprendimento automatico, iniezione indiretta compresa.
Questo articolo ha finalità informative e non costituisce una valutazione di sicurezza. Prima di collegare un agente ai tuoi sistemi, fai valutare il caso specifico da chi risponde della sicurezza informatica.