I problemi di sicurezza AI più difficili ora si trovano al di fuori del modello

Il 2026 OWASP Top 10 for LLM Applications offre una prospettiva critica sulla maturità dell’AI di produzione. Rileva un cambiamento fondamentale: il settore sta superando il sandbox e affrontando le complessità dell’integrazione nel mondo reale.

Quando si collega un LLM agli strumenti e ai flussi di lavoro aziendali, la superficie di minaccia cambia radicalmente. I rischi associati all’autorità e all’utilizzo delle risorse diventano notevolmente più difficili da contenere. Allo stesso tempo, vulnerabilità come la gestione impropria dell’output stanno lasciando il centro dell’attenzione, non perché siano state risolte, ma perché altri problemi sono saliti al primo piano.

La classifica OWASP Top 10 riflette questa evoluzione. “Excessive Agency” è salita dal sesto al terzo posto, mentre “Unbounded Consumption” è salita al sesto. Al contrario, “Improper Output Handling” è scesa al decimo.

Ciò non diminuisce il rischio legato alla gestione dell’output. Se una risposta di un LLM raggiunge una shell o un database senza una validazione rigorosa, le tradizionali vulnerabilità di iniezione persistono. Tuttavia, il paradigma è cambiato. In un sistema agentico, la risposta del modello non è la destinazione; è un input che trasporta autorità. Quando un modello detiene credenziali o interagisce con un’API, il suo output funge da vettore in grado di attivare azioni su sistemi disparati.

La sfida di sicurezza non è più solo valutare il modello; è definire i confini di ciò che accade dopo l’inferenza. La tua architettura determina se un’allucinazione rimane in forma di testo o si manifesta come una mutazione non autorizzata del database.

La classifica segue il danno

OWASP ha sfruttato 7,714 incidenti, il 75% basato sul consenso della comunità e il 25% su dati empirici degli incidenti. Questa base di evidenze ha costretto a un reale riordino delle priorità.

“Excessive Agency” è aumentata perché la realtà degli ambienti di produzione ha raggiunto la teoria. Le organizzazioni stanno accelerando il dispiegamento di capacità autonome più rapidamente di quanto stiano creando i piani di controllo necessari. La vulnerabilità critica non è solo la risposta fornita dal modello, ma il contesto di autorizzazione in cui tale risposta viene eseguita.

Mentre “Improper Output Handling” rimane una preoccupazione, i team DevOps hanno maturato la capacità di proteggere i sink a valle mediante la validazione degli schemi e le query parametrizzate. Queste sono pratiche consolidate di sicurezza delle applicazioni.

L’agenzia, tuttavia, è una classe di problema diversa. Una chiamata a uno strumento può essere strutturalmente valida ma contestualmente illegittima. Il modello può invocare una funzione approvata per un compito inappropriato o puntare alla risorsa sbagliata. La sanitizzazione statica non può giudicare l’intento. Ciò richiede un’autorizzazione sofisticata e contestualmente consapevole che il modello non dovrebbe mai eseguire in isolamento.

Considera ogni strumento come una capacità esposta

Molti team trattano le definizioni degli strumenti come semplici tubature di integrazione. Questo è un errore piuttosto ridicolo e fondamentale. Ogni strumento, connettore o endpoint API espande la sfera di influenza dell’applicazione AI.

Considera un agente progettato per riassumere una casella di posta. Se l’implementazione utilizza un connettore ampio che include capacità di scrittura o cancellazione, hai introdotto funzionalità eccessive prima che il primo prompt venga elaborato.

Devi applicare il principio del minimo privilegio:

• Restringi l’interfaccia: fornisci all’agente strumenti in sola lettura anziché connettori di uso generale.
• Contesto limitato: esegui le richieste nell’identità dell’utente con ambito OAuth.
• Policy Enforcement Points (PEP): Implementa la logica di autorizzazione come middleware obbligatorio tra il modello e i sistemi a valle. Ogni azione deve essere convalidata rispetto alla policy prima dell’esecuzione.
• Human-in-the-loop (HITL): Richiedi un’approvazione esplicita per operazioni difficili da annullare o che hanno un impatto materiale elevato.

Questo approccio richiede un cambiamento nella pipeline di consegna. Il tuo processo di revisione deve estendersi oltre il modello per includere modifiche agli schemi degli strumenti, alle identità dei servizi e agli ambiti di permesso. Un aggiornamento del modello può apparire innocuo, ma una modifica al contesto di autorizzazione di un connettore può creare una vulnerabilità catastrofica.

La visibilità è imprescindibile. Devi registrare l’esecuzione specifica dello strumento, l’identità autorizzante e la modifica risultante nel sistema di destinazione. Questa catena di custodia è essenziale per la risposta agli incidenti, consentendo di interrompere un processo attivo e ricostruire il percorso di audit dopo l’incidente.

Ogni esecuzione autonoma richiede un arresto definitivo

“Unbounded Consumption” è aumentata perché il volume di richieste è una metrica inadeguata per il rischio di risorse. Un singolo prompt conciso può innescare una catena ricorsiva e intensiva di risorse di chiamate agli strumenti. Il contatore non si ferma finché l’agente non termina.

Un semplice avviso è insufficiente quando la velocità di esecuzione supera la risposta umana. Hai bisogno di limiti deterministici e rigidi che rimangano al di fuori del controllo dell’agente. Implementa soglie rigorose per l’uso dei token, il tempo trascorso, la profondità di ricorsione e il costo operativo cumulativo. Se un’esecuzione supera questi parametri, il sistema deve terminare o limitare l’esecuzione.

L’ambito operativo richiede la stessa rigore. Determina il numero massimo di record che un agente può modificare e definisci i limiti della propagazione dei compiti. Se la tua architettura manca di un meccanismo “stop” deterministico, hai essenzialmente delegato l’autorità senza definirne il perimetro.

Costruire per la risposta sbagliata

L’ingegneria dei sistemi si è a lungo affidata a un’architettura resiliente per proteggere componenti intrinsecamente inaffidabili. Prevediamo il guasto dei componenti e l’instabilità della rete; la sicurezza deriva da tale presupposto, non dall’illusione della perfezione. I LLM richiedono la stessa disciplina architettonica.

Non basare la tua strategia di sicurezza sull’assunzione di un allineamento perfetto del modello. Presupponi il fallimento, sia per incomprensioni benigne che per sfruttamenti malevoli. Limita le capacità dell’agente al minimo assoluto necessario e mantieni contesti di autorizzazione utente rigorosi per tutte le chiamate a valle. Fondamentale è che l’applicazione delle politiche esista al di fuori del modello per impedire che l’iniezione di prompt o errori di ragionamento aggirino i tuoi controlli.

Ora consideriamo l’iniezione di prompt meno come una vulnerabilità e più come una legge della fisica. Sarà sempre in agguato. Il fatto è che i modelli stessi non possono essere decisori efficaci per questioni critiche di sicurezza. In un progetto agente reale che sto costruendo, abbiamo circa 100 test “red team” automatizzati. Ci assicuriamo di superarli tutti. Ma lo facciamo costruendo controlli rigidi al di fuori del modello. Possiamo disattivarli e vedere i tassi di superamento/insuccesso solo per il modello. Il modello più vecchio e più debole che testiamo fallisce il 17 % delle volte. Il modello più nuovo e più grande fallisce il 2 % delle volte. Grande progresso, vero? Ma il 98 % è sufficiente quando ogni fallimento comporta la perdita di dati sensibili? Per niente.

Le operazioni ad alto impatto devono essere osservabili, auditabili e, idealmente, reversibili. Ogni esecuzione autonoma richiede barriere di protezione immutabili che rimangano al di là della portata del modello.

Le classifiche del 2026 illuminano davvero dove i fallimenti dell’IA si trasformano in conseguenze concrete. Il modello può avviare l’errore, ma è l’architettura a definire il raggio d’azione. Per l’IA in produzione, il lavoro di sicurezza più critico avviene nella pipeline post-inferenza.