Sicurezza e governance dell'AI agentica: guida per le aziende

Indice dei contenuti

Le minacce ereditate: l’AI generativa ha già la sua Top 10
Le minacce nuove: quando il rischio non è la risposta, ma l’azione
I modelli di governance a cui prepararsi
Governare prima che proliferino

Negli articoli precedenti abbiamo raccontato come il traffico verso i modelli AI stia diventando parte integrante delle architetture aziendali, e come l’AI Gateway rappresenti l’evoluzione naturale dell’API Gateway per governarlo. Ma mentre le organizzazioni imparano a gestire questo primo livello di complessità, il panorama sta già cambiando di nuovo: i sistemi AI stanno smettendo di limitarsi a rispondere e stanno iniziando ad agire.

È il passaggio dall’AI generativa all’AI agentica: agenti software che, ricevuto un obiettivo, pianificano i passi per raggiungerlo, invocano strumenti e API, leggono e scrivono dati, dialogano con altri agenti e portano a termine processi con un grado di autonomia crescente. Non più un assistente che suggerisce la risposta a un operatore, ma un attore che apre il ticket, interroga il gestionale, aggiorna la pratica e notifica il cliente.

I numeri dicono che questa transizione non è all’orizzonte: è in corso. Secondo il report Okta “AI at Work 2025, il 91% delle organizzazioni utilizza già agenti AI in qualche forma — ma solo il 36% ha un modello di governance centralizzato dell’AI e solo il 10% ha una strategia strutturata per gestire le identità non umane. È esattamente il tipo di scarto tra adozione e governo che abbiamo già visto con l’API sprawl, e che sappiamo quanto costi recuperare a posteriori.

Per chi governa le infrastrutture IT, la domanda da porsi è duplice: quali nuove minacce introduce questo scenario? Con quali modelli di governance occorre farsi trovare pronti?

Le minacce ereditate: l’AI generativa ha già la sua Top 10

Un primo insieme di rischi non nasce con gli agenti, ma con i modelli linguistici stessi, ed è ormai codificato: la OWASP Top 10 for LLM Applications, aggiornata nel 2025, è per i sistemi AI ciò che la OWASP API Security Top 10 — di cui abbiamo parlato a proposito di API Security — è per le API. Le voci principali meritano di essere conosciute anche da chi non si occupa di sicurezza a tempo pieno:

Prompt injection, stabilmente al primo posto: istruzioni malevole nascoste nell’input — o nei contenuti che il modello legge, come un documento o una pagina web — che dirottano il comportamento del sistema;
Sensitive information disclosure: il modello che rivela dati sensibili appresi dal contesto, dai documenti aziendali o dalla conversazione stessa;
System prompt leakage: l’esfiltrazione delle istruzioni di sistema, che spesso contengono logiche di business e regole di sicurezza;
Supply chain dei modelli: vulnerabilità ereditate da modelli, dataset ed embedding di terze parti, esattamente come accade con le dipendenze software.

Queste minacce si affrontano in gran parte al livello che conosciamo già: guardrail sui prompt, mascheramento dei dati personali, controllo centralizzato del traffico — il territorio dell’AI Gateway. Ma l’AI agentica aggiunge un piano completamente nuovo.

Le minacce nuove: quando il rischio non è la risposta, ma l’azione

Con un chatbot, l’esito peggiore di un attacco è una risposta sbagliata o un dato esposto. Con un’AI agentica che dispone di strumenti e permessi, l’esito è un’azione sbagliata eseguita con credenziali legittime. È una differenza di natura, non di grado, e ha spinto OWASP a pubblicare una classifica dedicata: la OWASP Top 10 for Agentic Applications 2026. Le categorie più rilevanti per chi progetta infrastrutture:

Goal hijacking e memory poisoning

Un attaccante non deve più violare il sistema: gli basta manipolare l’obiettivo dell’agente o avvelenarne la memoria. Un’e-mail costruita ad arte, un documento contaminato in una knowledge base, un dato alterato in un CRM possono diventare istruzioni che l’agente eseguirà convinto di fare il proprio lavoro — e che persisteranno nella sua memoria attraverso le sessioni.

Tool misuse e tool poisoning

L’AI agentica agisce attraverso strumenti, sempre più spesso esposti tramite protocolli standard come MCP – Model Context Protocol. Uno strumento compromesso o malevolo può esfiltrare dati o indurre l’agente ad azioni dannose: lo studio del 2026 “The Mother of All AI Supply Chains” a cura OX Security ha censito decine di vulnerabilità note negli ecosistemi MCP e fino a 200.000 istanze esposte tra IDE, tool interni e servizi cloud. La supply chain degli strumenti degli agenti è la nuova supply chain del software.

Excessive agency

È la categoria più caratteristica: l’agente che dispone di più funzionalità, più permessi o più autonomia di quanto il suo compito richieda. Un agente di supporto clienti che può anche cancellare
record, un’utenza tecnica condivisa con privilegi ampi, un processo che esegue azioni irreversibili senza checkpoint: ognuno di questi eccessi è un moltiplicatore del danno potenziale di qualsiasi altra vulnerabilità.

Effetti a cascata nei sistemi multi-agente

Quando gli agenti collaborano tra loro, un singolo agente compromesso o semplicemente “fuori rotta” può propagare l’errore agli altri — secondo un’analisi di Tech Plus Trends il cascade failure è considerato la modalità di guasto dominante del 2026 — con derive di ragionamento, abusi di privilegio o consumi di token che si amplificano lungo la catena.

Identità invisibili

Il rischio forse più sottovalutato è organizzativo prima che tecnico: un agente senza un’identità registrata, un owner definito e un perimetro di permessi governato è, dal punto di vista del programma di sicurezza aziendale, semplicemente invisibile. E ciò che è invisibile non si può proteggere, auditare né spegnere.

APPROFONDISCI IL TEMA AI

AI Sprawl: dove porta l’adozione incontrollata dell’AI (e come governarla)

LEGGI L'ARTICOLO

I modelli di governance a cui prepararsi

La buona notizia è che per questo scenario non serve inventare la governance da zero: serve estendere — con alcune novità sostanziali — i modelli che le organizzazioni mature hanno già costruito per API e identità. Cinque direttrici, in ordine di priorità.

Gli agenti come identità di prima classe

Ogni agente deve avere un’identità propria — non umana, ma governata come quella di un dipendente privilegiato: censita in un registro, associata a un owner responsabile, dotata di credenziali dedicate con ciclo di vita gestito (provisioning, rotazione, revoca). È la premessa di tutto il resto: senza anagrafica degli agenti non esiste né controllo né audit. Le pratiche di Identity & Access Management si estendono così alle non-human identities, oggi l’area più immatura nelle aziende.

Least privilege, e il suo corollario: least agency

Al principio classico del minimo privilegio si affianca quello della minima agency: a ogni agente solo gli strumenti strettamente necessari al compito (tool allowlisting), solo i permessi minimi su ciascuno strumento, e un livello di autonomia graduato sulla criticità — con checkpoint human-in-the-loop obbligatori per le azioni irreversibili o ad alto impatto: pagamenti, cancellazioni, comunicazioni verso l’esterno.

Un punto di enforcement sul runtime

Come per le API e per il traffico LLM, i controlli non possono vivere sparsi nel codice dei singoli agenti. Il modello che si sta affermando è quello del gateway come punto di controllo anche per il piano degli strumenti: ogni invocazione di tool passa da un punto centralizzato che verifica identità dell’agente, policy, quote e coerenza della richiesta — lo stesso pattern architetturale dell’AI Gateway, esteso dal traffico verso i modelli al traffico degli agenti verso i sistemi aziendali. Anche Microsoft, nel delineare la sicurezza degli agenti che “passano dal leggere all’agire”, converge su questo insieme di controlli: identity binding, allowlisting, monitoraggio runtime.

Observability comportamentale e audit trail

Il monitoraggio tradizionale osserva metriche; con gli agenti occorre osservare comportamenti: quali strumenti usa un agente, con che frequenza, con quali pattern, e segnalare le deviazioni — un agente contabile che improvvisamente interroga l’anagrafica clienti è un’anomalia, anche se ogni singola chiamata è formalmente autorizzata. Ogni azione va tracciata in un audit trail immutabile: un requisito che l’AI Act, con i suoi obblighi di tracciabilità e trasparenza, sta trasformando da buona pratica a obbligo normativo, in particolare nei settori regolamentati.

Un framework di riferimento e un processo, non solo strumenti

OWASP mette a disposizione, accanto alla Top 10 delle applicazioni agentiche, una tassonomia delle minacce, mentre Cloud Security Alliance ha predisposto il framework di threat modeling MAESTRO, pensati proprio per portare metodo dove oggi c’è sperimentazione. Ma il framework da solo non basta: serve una governance operativa fatta di catalogo degli agenti e dei casi d’uso, policy di adozione, criteri di classificazione del rischio, piani di incident response che contemplino lo scenario “agente compromesso” — incluso il suo spegnimento rapido e selettivo.

Governare prima che proliferino

Chi ha seguito questa serie di articoli riconoscerà lo schema: è la stessa traiettoria delle API. Prima l’entusiasmo e l’adozione spontanea, poi la proliferazione, poi — per chi non si è mosso in tempo — anni di rincorsa tra shadow IT, debito tecnico e incidenti. Con gli agenti la finestra è più stretta, perché l’autonomia amplifica sia il valore sia il rischio: un ecosistema di agenti non governato non è solo disordinato, è attivamente pericoloso.

Sicurezza e governance operativa nell’era dell’AI agentica

Le minacce ereditate: l’AI generativa ha già la sua Top 10