OWASP Agentic AI Top 10

L'IA agenziale cambia il discorso sulla sicurezza perché cambia ciò che i sistemi di IA possono fare.

Un chatbot che risponde a domande da una knowledge base è una cosa. Un agente IA che può pianificare attività, chiamare strumenti, accedere a sistemi interni, interrogare dati, scrivere su applicazioni, eseguire codice, coordinarsi con altri agenti e mantenere la memoria è un'altra cosa del tutto.

Molte organizzazioni hanno sperimentato nel 2024 e 2025 con integrazioni LLM, copilote interni, sistemi di recupero, assistenti IA e primi flussi di lavoro agenziali. Parte di questo lavoro è rimasto confinato in modo sicuro. Parte di esso si è espanso silenziosamente. Gli agenti hanno ottenuto accesso ad API, strumenti SaaS, database, file, sistemi di ticketing, record CRM, repository e flussi di lavoro operativi.

È lì che cambia il rischio per la sicurezza. Un agente IA non è solo un'altra interfaccia utente. È un attore software con istruzioni, permessi, strumenti, contesto e la capacità di prendere decisioni all'interno di un flusso di lavoro.

La Fondazione OWASP’ Top 10 per Applicazioni Agentiche 2026 offre ai team di sicurezza un modo pratico per pensare a questo cambiamento. Sviluppato attraverso la collaborazione con oltre 100 esperti del settore, ricercatori e professionisti, il framework identifica i rischi più critici che affrontano i sistemi di IA autonomi e agenziali. Non è solo un avvertimento sulle minacce future. È una mappa dei problemi che le organizzazioni stanno già iniziando ad affrontare mentre gli agenti passano dal pilota alla produzione.

Perché l'IA agenziale cambia l'equazione della sicurezza

La sicurezza delle applicazioni tradizionali si basa su assunti familiari. Gli utenti si autenticano. Le applicazioni applicano i permessi. I servizi chiamano API note. I log mostrano le azioni. I team di sicurezza monitorano i modelli di accesso, le vulnerabilità, il comportamento di rete e le attività sospette.

L'IA agenziale complica questi assunti.

Gli agenti non si comportano come utenti normali. Possono interpretare istruzioni, creare piani intermedi, decidere quali strumenti utilizzare, recuperare il contesto, chiamare sistemi ripetutamente e produrre azioni che appaiono legittime perché utilizzano credenziali approvate e integrazioni approvate.

L'analisi di Palo Alto Networks’ del rilascio OWASP evidenzia la necessità di un inventario incentrato sugli agenti, una visibilità completa, l'integrità della catena di fornitura attraverso i componenti IA, la governance, le ringhiere di sicurezza e il controllo attivo in fase di esecuzione. Questa inquadratura è utile perché il problema di sicurezza non è limitato all'iniezione di prompt. Include strumenti, identità, catene di fornitura, memoria, contesto, permessi e comportamento in fase di esecuzione.

In altre parole, proteggere un agente non è la stessa cosa che proteggere un modello. Il modello è solo una parte del sistema.

Il Top 10 OWASP per le Applicazioni Agentiche

L'elenco 2026 di OWASP’ identifica dieci principali categorie di rischio per i sistemi agenziali:

ASI01 — Dirottamento dell'Obiettivo dell'Agente: gli attaccanti manipolano o reindirizzano l'obiettivo dell'agente’, spesso attraverso linguaggio naturale, istruzioni nascoste o contesto malizioso.
ASI02 — Uso Improprio e Sfruttamento degli Strumenti: gli agenti utilizzano strumenti in modi non sicuri, non intenzionali o sfruttabili.
ASI03 — Abuso di Identità e Privilegi dell'Agente: gli agenti ricevono permessi eccessivi, ereditano credenziali rischiose o operano senza adeguati confini di identità.
ASI04 — Vulnerabilità della Catena di Fornitura Agenziale: prompt, plugin, server MCP, strumenti, set di dati, logica di orchestrazione, dipendenze o integrazioni sono compromessi.
ASI05 — Esecuzione di Codice Inaspettata: gli agenti attivano o generano comportamenti eseguibili non sicuri attraverso strumenti, script, plugin o sistemi connessi.
ASI06 — Avvelenamento della Memoria e del Contesto: gli attaccanti manipolano ciò che l'agente ricorda, recupera o utilizza come contesto.
ASI07 — Comunicazione Insecure tra Agenti: gli agenti comunicano tra loro senza sufficiente autenticazione, convalida o confini.
ASI08 — Fallimenti a Cascata degli Agenti: il fallimento, l'output errato o l'azione non sicura di un agente’ si propaga attraverso un più ampio flusso di lavoro agenziale.
ASI09 — Sfruttamento della Fiducia Uomo-Agente: gli utenti si fidano eccessivamente degli output, delle approvazioni o delle raccomandazioni degli agenti in modi che gli attaccanti possono sfruttare.
ASI10 — Agenti Ribelli: gli agenti agiscono al di fuori dell'ambito previsto, persistono oltre l'autorizzazione o operano senza un'adeguata supervisione.

L'elenco è importante perché riflette come i sistemi agenziali falliscono realmente. I rischi sono comportamentali, architetturali e operativi. Non sono solo vulnerabilità nel senso tradizionale.

Il problema dell'identità per cui nessuno si è preparato

I team di sicurezza gestiscono già identità non umane: account di servizio, carichi di lavoro, dispositivi, applicazioni, bot, script di automazione e chiavi API. L'IA agenziale aggiunge un altro livello.

Un agente può operare con autorità delegata. Può utilizzare le credenziali di un utente’, un account di servizio, un token specifico per lo strumento o un'identità gestita dalla piattaforma. Può accedere a più sistemi in un unico flusso di lavoro. Può decidere quale strumento utilizzare in base al contesto. Può operare per conto di diversi utenti in momenti diversi.

Questo crea una domanda difficile: cosa esattamente è permesso fare all'agente?

Se la risposta è “tutto ciò che l'account connesso può fare,” l'organizzazione ha un problema. I permessi umani sono spesso troppo ampi per un uso autonomo. Un utente può avere accesso a file sensibili, dati dei clienti, sistemi di fatturazione, impostazioni amministrative o codice sorgente perché ha bisogno di quell'accesso in contesti specifici. Dare a un agente la stessa ampiezza di accesso può creare rischi inutili.

Le identità degli agenti devono essere governate deliberatamente. Questo significa privilegio minimo, credenziali con ambito limitato, proprietà chiara, permessi a livello di strumento, porte di approvazione, registrazione e la capacità di revocare o ruotare l'accesso rapidamente.

Il dirottamento dell'obiettivo è diverso dalla compromissione tradizionale

Il dirottamento dell'obiettivo dell'agente è uno dei rischi più importanti perché attacca le istruzioni dell'agente’ piuttosto che il codice sottostante.

Un attaccante potrebbe non aver bisogno di sfruttare una vulnerabilità del software nel senso usuale. Potrebbe inserire istruzioni maliziose in un documento, pagina web, email, ticket di supporto, problema del repository, output dello strumento o altro contesto che l'agente legge. Se l'agente non può distinguere le istruzioni attendibili dal contenuto non attendibile, potrebbe reindirizzare il suo comportamento.

L'analisi di Auth0’ dell'elenco OWASP descrive le prime due categorie, dirottamento dell'obiettivo e uso improprio degli strumenti, come rischi che sorgono perché gli agenti elaborano il linguaggio naturale e potrebbero non distinguere in modo affidabile le istruzioni di sistema dai payload maliziosi nascosti nel contenuto o nell'output degli strumenti.

Questo è un modello mentale diverso per i difensori. La superficie di attacco include testo, contesto, risposte degli strumenti, memoria, documenti recuperati e flussi di lavoro, non solo endpoint esposti.

L'accesso agli strumenti trasforma il ragionamento errato in azione reale

L'IA agenziale diventa più potente quando può utilizzare strumenti. Diventa anche più pericolosa.

Un modello che dà una risposta sbagliata è un problema di qualità. Un agente che dà una risposta sbagliata e poi aggiorna un record cliente, apre un ticket, invia un'email, cambia una configurazione, chiama un'API o esegue codice è un rischio operativo.

L'uso improprio degli strumenti può accadere anche senza intento malizioso. L'agente potrebbe fraintendere una richiesta. Potrebbe utilizzare uno strumento nell'ordine sbagliato. Potrebbe agire su dati obsoleti. Potrebbe chiamare un'API con i parametri sbagliati. Potrebbe non riconoscere che è necessario un passaggio di approvazione umana.

La soluzione non è semplicemente “prompt migliori.” Gli agenti hanno bisogno di confini per gli strumenti. Hanno bisogno di ambiti di permesso. Hanno bisogno di valori predefiniti sicuri. Hanno bisogno di modalità di prova per azioni ad alto impatto. Hanno bisogno di approvazione umana per operazioni sensibili. Hanno bisogno di monitoraggio che comprenda il comportamento dell'agente, non solo il traffico API.

Memoria e contesto creano una nuova superficie di attacco

La memoria dell'agente è utile perché permette ai sistemi di trattenere preferenze, stato del flusso di lavoro, decisioni precedenti e contesto tra le sessioni. Crea anche rischi.

Se la memoria può essere avvelenata, l'agente potrebbe portare avanti presupposti errati. Se il recupero del contesto è debole, l'agente potrebbe utilizzare documenti sbagliati, politiche obsolete o dati modificati in modo malizioso. Se gli utenti possono influenzare la memoria condivisa senza controlli, l'input di un utente’ potrebbe influenzare l'esperienza di un altro utente’.

I sistemi di memoria e recupero dovrebbero essere trattati come parte dell'architettura di sicurezza. Le organizzazioni devono sapere cosa è memorizzato, chi può modificarlo, per quanto tempo è trattenuto, come è convalidato e come il contesto avvelenato o obsoleto può essere corretto.

Il rischio della catena di fornitura ora include prompt, strumenti e server MCP

La sicurezza della catena di fornitura del software include già dipendenze, pacchetti, contenitori, sistemi di build, API e servizi dei fornitori. L'IA agenziale espande la catena di fornitura.

Prompt, definizioni degli strumenti, script di orchestrazione, set di dati RAG, plugin, server MCP, strumenti esterni, archivi vettoriali e fornitori di modelli diventano tutti parte del sistema agenziale. Uno strumento compromesso o un set di dati avvelenato può cambiare il comportamento dell'agente tanto quanto un pacchetto compromesso può cambiare il comportamento dell'applicazione.

Palo Alto Networks enfatizza l'integrità della catena di fornitura attraverso prompt, plugin, set di dati RAG, script di orchestrazione e dipendenze del modello. Questa è la prospettiva giusta. I team di sicurezza devono trattare i componenti agenziali come dipendenze di produzione, non come configurazione informale.

La conformità non può essere un'idea successiva

L'IA agenziale espone alla conformità perché gli agenti possono toccare dati sensibili, influenzare decisioni, creare record, comunicare esternamente o intraprendere azioni all'interno di flussi di lavoro regolamentati.

La domanda sulla conformità non è solo se il modello è approvato. È se l'intero flusso di lavoro agenziale può essere spiegato, monitorato, auditato e controllato.

Le organizzazioni devono rispondere:

Quali agenti sono distribuiti?
Chi possiede ogni agente?
A quali dati può accedere ogni agente?
Quali strumenti può utilizzare ogni agente?
Quali azioni richiedono l'approvazione umana?
Come vengono versionati prompt, strumenti e configurazioni?
Come vengono registrati gli output?
Come vengono rilevati e escalati gli incidenti?
Come vengono ritirati o dismessi gli agenti?

Se a queste domande non si può rispondere, l'organizzazione non ha un programma di governance dell'IA agenziale. Ha un uso dell'IA agenziale.

Cosa dovrebbero fare i team di sicurezza ora

La risposta giusta non è vietare ogni sistema agenziale. È creare un modello di sicurezza che corrisponda al rischio.

Costruire un inventario degli agenti: Identificare agenti, copilote, automazioni, plugin, server MCP, flussi di lavoro di chiamata degli strumenti e funzionalità IA dei fornitori già in uso.
Mappare permessi e strumenti: Documentare a quali sistemi ogni agente può accedere, quali credenziali utilizza e quali azioni può intraprendere.
Applicare il privilegio minimo: Non permettere agli agenti di ereditare ampi permessi umani per impostazione predefinita. Limitare l'accesso al compito.
Separare le istruzioni attendibili dal contenuto non attendibile: Trattare documenti, pagine web, email, ticket e output degli strumenti come input potenzialmente ostili.
Controllare le azioni ad alto impatto: Richiedere approvazione, revisione o modalità di prova per operazioni sensibili.
Sicurezza della memoria e del recupero: Controllare cosa gli agenti possono ricordare, recuperare, modificare e condividere tra utenti o sessioni.
Monitorare il comportamento in fase di esecuzione: Registrare chiamate agli strumenti, uso dei permessi, accesso ai dati, output, errori e modelli di azione insoliti.
Red-team dei flussi di lavoro agenziali: Testare per dirottamento dell'obiettivo, uso improprio degli strumenti, abuso di privilegi, avvelenamento del contesto, esecuzione di codice non sicura e fallimenti a cascata.

Questi controlli dovrebbero essere progettati nell'architettura agenziale prima della distribuzione. Aggiungerli in seguito è più difficile, specialmente dopo che gli utenti iniziano a dipendere dal sistema.

Come Ridiculous Engineering pensa alla sicurezza dell'IA agenziale

In Ridiculous Engineering, vediamo la sicurezza dell'IA agenziale come un problema di architettura, non solo un problema di indurimento dei prompt. I prompt contano, ma gli agenti diventano rischiosi perché sono connessi a strumenti, identità, dati, memoria, API, flussi di lavoro e persone.

Questo significa che la sicurezza degli agenti deve essere progettata attraverso l'intero sistema. A cosa può accedere l'agente? Cosa può cambiare? Quale contesto può influenzarlo? Cosa viene registrato? Cosa richiede revisione? Chi possiede l'agente dopo la distribuzione? Come l'organizzazione rileva il comportamento non sicuro prima che diventi un incidente aziendale?

Aiutiamo i clienti ad affrontare queste domande in modo pratico. Questo può significare inventariare flussi di lavoro agenziali, mappare permessi e accesso ai dati, rivedere integrazioni degli strumenti, progettare porte di governance, costruire monitoraggio, creare modelli di distribuzione più sicuri o aiutare i team a passare da agenti sperimentali a sistemi di produzione con controlli più chiari.

L'obiettivo non è rallentare l'innovazione per il suo stesso bene. L'obiettivo è rendere l'IA agenziale utile senza lasciare che l'autonomia superi la responsabilità.

La linea di fondo

L'IA agenziale non è un problema di sicurezza futuro. È un problema di architettura presente.

Il Top 10 OWASP per le Applicazioni Agentiche, le linee guida di sicurezza di Palo Alto Networks’, l'analisi di Auth0’ sul dirottamento dell'obiettivo e l'uso improprio degli strumenti e la più ampia comunità di sicurezza stanno tutti indicando nella stessa direzione: le organizzazioni hanno bisogno di visibilità, controllo dell'identità, ringhiere di sicurezza in fase di esecuzione, governance degli strumenti, protezione della memoria e supervisione umana per gli agenti IA.

Non puoi aggiungere tutto questo a un'architettura fragile alla fine e aspettarti che regga.

Se la tua organizzazione sta sperimentando con agenti IA, distribuendo flussi di lavoro agenziali o cercando di capire se il tuo modello di sicurezza è pronto per i sistemi autonomi, Ridiculous Engineering può aiutare. Lavoriamo con i team per valutare l'architettura, identificare il rischio agenziale e progettare controlli che permettano ai sistemi IA di operare con i giusti confini.

L'IA agenziale può essere potente. Ha anche bisogno di essere governata come qualcosa di potente.

Fonti e letture aggiuntive: OWASP: Top 10 per Applicazioni Agentiche 2026, Progetto Sicurezza GenAI OWASP: Top 10 rischi e mitigazioni per la sicurezza dell'IA agenziale, Palo Alto Networks: OWASP Top 10 per Applicazioni Agentiche 2026, Auth0: Lezioni dal Top 10 OWASP per Applicazioni Agentiche, DeepTeam: OWASP Top 10 per Agenti 2026, Teleport: OWASP Top 10 per Applicazioni Agentiche

OWASP Agentic AI Top 10: Cosa i team di sicurezza devono preparare per il 2026