Now Reading: Sicurezza degli agenti AI: rischi, identità e permessi
-
01
Sicurezza degli agenti AI: rischi, identità e permessi
Quando un agente AI può leggere dati e compiere azioni, il problema non è soltanto l’allucinazione: identità, permessi e controllo diventano sicurezza di base.
Un chatbot che sbaglia una risposta può confondere una persona. Un agente AI che sbaglia un’azione può modificare un database, inviare un messaggio, eseguire codice o utilizzare credenziali a cui non avrebbe dovuto accedere. È questa differenza a trasformare la sicurezza degli agenti da variante della sicurezza dei modelli a nuovo problema operativo.
Nel 2026 il NIST ha dedicato un’iniziativa specifica agli standard per gli agenti AI e ha raccolto contributi sulla loro sicurezza. Il risultato preliminare è netto: molti principi della cybersecurity tradizionale restano validi, ma devono essere adattati a sistemi capaci di pianificare e compiere azioni in autonomia.
Se vuoi partire dalla definizione generale, abbiamo spiegato cosa sono gli agenti AI. Il problema qui è diverso: cosa succede quando li colleghiamo davvero alle applicazioni che usiamo?
Il rischio nasce dall’unione tra modello e strumenti
Un modello linguistico da solo produce testo. Un agente diventa operativo quando può chiamare strumenti: browser, API, terminali, database, email, calendari, CRM, sistemi di pagamento. Ogni strumento aggiunge capacità, ma anche una superficie di attacco.
Il NIST sottolinea proprio questa combinazione. Alcuni rischi sono quelli classici del software — autenticazione debole, vulnerabilità nelle dipendenze, gestione scorretta delle credenziali — mentre altri emergono dal fatto che l’output probabilistico di un modello determina quale funzione eseguire e con quali parametri.
È un cambio importante. Non basta chiedersi se il modello “conosce” informazioni pericolose. Bisogna chiedersi che cosa può fare con le informazioni che riceve.
Prompt injection: quando un contenuto diventa un comando
Uno dei rischi più noti è la prompt injection. Un agente che naviga sul web o legge documenti può incontrare testo creato appositamente per modificare il suo comportamento. Per un essere umano, una frase nascosta in una pagina è soltanto testo; per un sistema che interpreta il linguaggio come istruzione può diventare un comando.
Il problema aumenta quando l’agente ha accesso a dati privati o strumenti operativi. Un documento malevolo potrebbe tentare di convincerlo a inviare informazioni verso l’esterno, ignorare una policy o utilizzare un tool in modo improprio.
Non esiste una singola protezione definitiva. Servono separazione tra istruzioni e contenuti, validazione delle azioni, limiti ai tool disponibili e controlli specifici per le operazioni ad alto impatto.
Identità: chi sta davvero compiendo l’azione?
Nel software tradizionale siamo abituati a distinguere utenti e applicazioni. Gli agenti complicano la situazione perché agiscono per conto di qualcuno ma possono farlo senza una richiesta umana immediata. Per questo identità e autorizzazione stanno diventando uno dei nodi centrali dell’agentic AI.
Il 29 settembre 2026 il National Cybersecurity Center of Excellence del NIST ha pubblicato una sintesi dei commenti ricevuti sul tema dell’identità e delle autorizzazioni degli agenti. La domanda di fondo è semplice: un sistema deve poter identificare l’agente come soggetto distinto, sapere per chi sta operando e quali permessi gli sono stati delegati.
Usare le credenziali complete dell’utente è la soluzione più facile e spesso la peggiore. Un agente dovrebbe ricevere soltanto i privilegi necessari al compito, possibilmente temporanei e revocabili. È il principio del least privilege, ma applicato a software che decide dinamicamente come utilizzare quei privilegi.
Un agente non dovrebbe avere sempre il diritto di agire
Una buona architettura distingue almeno tre tipi di azione. Ci sono operazioni a basso rischio, come leggere dati non sensibili o preparare una bozza. Ci sono azioni reversibili, come modificare una scheda interna. E ci sono azioni ad alto impatto: effettuare pagamenti, eliminare dati, pubblicare contenuti, inviare informazioni riservate.
Più aumenta l’impatto, più dovrebbe aumentare la necessità di conferma. L’obiettivo non è bloccare l’autonomia, ma definire confini dell’autonomia. Un agente può essere autorizzato a preparare un bonifico senza poterlo eseguire, oppure a modificare codice in un ambiente di test senza distribuirlo in produzione.
Questa logica diventa ancora più importante con gli agenti AI autonomi e persistenti, che possono continuare a lavorare senza che l’utente osservi ogni singolo passaggio.
Logging e tracciabilità: sapere perché è successo
Un sistema autonomo deve lasciare una traccia leggibile delle proprie azioni. Non basta sapere che un file è stato cancellato: bisogna poter ricostruire quale obiettivo aveva l’agente, quali informazioni ha ricevuto, quali strumenti ha utilizzato e quale regola ha autorizzato l’operazione.
La tracciabilità serve alla sicurezza, ma anche alla responsabilità. Quando un agente entra in un processo aziendale, la domanda “chi ha fatto questa cosa?” non può avere come risposta semplicemente “l’AI”. Serve una catena di delega comprensibile.
La sicurezza diventa una proprietà del sistema, non del modello
Il punto più importante è che un agente sicuro non nasce scegliendo semplicemente il modello più affidabile. La sicurezza dipende dall’intero sistema: autenticazione, permessi, isolamento degli strumenti, policy, supervisione, logging, gestione delle credenziali e possibilità di interrompere l’attività.
L’agentic AI rende così evidente un principio che vale da sempre nell’informatica: capacità e rischio crescono insieme. Più un sistema può fare, meno possiamo permetterci di affidare la sicurezza alla speranza che interpreti correttamente ogni istruzione.
