Concedere autorizzazioni a un agente di intelligenza artificiale non è una semplice operazione di configurazione: è una decisione rischiosa che va presa con lo stesso rigore con cui si decide chi ha la facoltà di firmare su un conto bancario. Ogni autorizzazione aggiuntiva amplia il potenziale di danno, e questo ampliamento non è compensato dalla qualità del modello, perché il rischio non deriva da difetti del modello stesso, bensì dalla possibilità che esso possa essere manipolato o commettere errori nell'ambito delle autorizzazioni concesse.
La formula che utilizziamo internamente è semplice: Un agente non può arrecare danno in un luogo in cui non è autorizzato.. L'intera progettazione della sicurezza di un sistema agentivo deriva da questa frase.
OWASP, nella sua classifica dei 10 principali rischi per le applicazioni di modelli linguistici del 2025, classifica l'iniezione di prompt al primo posto per il secondo anno consecutivo e dedica un'intera categoria — LLM06, *Eccessiva attività di agenzia* — proprio a questo problema. Lo suddivide in tre forme:
Tutte e tre sono decisioni di progettazione, non difetti del modello. E tutte e tre vengono quasi sempre prese durante la fase di integrazione, per ragioni tecniche e all'insaputa di chiunque in azienda.
Il collegamento tra questi due approcci è l'iniezione indiretta di prompt: contenuti esterni (un'e-mail, un PDF da un fornitore, una pagina web, un ticket di assistenza clienti) contenenti istruzioni indirizzate al modello. L'agente legge questo contenuto come parte del suo contesto e agisce di conseguenza. Se i suoi permessi sono ampi, il testo scritto da terzi può finire per eseguire azioni all'interno dei vostri sistemi.
Ecco perché la sicurezza di un agente non si risolve scegliendo un modello migliore, bensì limitando le azioni che l'agente può compiere quando qualcuno riesce a influenzarlo.
Ecco un cambiamento strutturale che molte organizzazioni non hanno ancora integrato nella gestione degli accessi. Per vent'anni, il controllo delle identità è stato concepito per le persone: onboarding, offboarding, ruoli, revisioni periodiche. Gli agenti introducono identità che non sono persone; vengono create in pochi minuti, non compaiono nell'organigramma e raramente vengono revisionate.
Il rapporto "Cost of a Data Breach" di IBM del 2025 fornisce i dati che giungono a conclusione di questa argomentazione: Il 97% delle organizzazioni che hanno subito un incidente legato all'IA non disponeva di controlli di accesso adeguati. Non è un problema di sofisticatezza dell'attaccante. È un problema di igiene dei permessi.
Lo abbiamo trattato in modo approfondito in identità non umane, agenti di intelligenza artificiale e sicurezza informatica, In sintesi, il punto è questo: se il vostro processo di gestione degli accessi non include le identità non umane, il vostro inventario degli accessi è incompleto, probabilmente proprio nella parte che può avere il maggiore impatto.
Non tutti i permessi hanno lo stesso profilo di rischio. Questa classificazione consente di prendere una decisione in una riunione di trenta minuti.
Livello | Che cosa può fare l'agente? | Controllo richiesto |
1. Lettura limitata | Interroga i dati relativi a un dominio specifico | Registrazione degli accessi e limite di volume |
2. Lettura approfondita | Consultare più sistemi e dati sensibili | Autorizzazioni basate sui ruoli, mascheramento dei dati, audit |
3. Scrittura reversibile | Creare bozze, proposte, registri in sospeso | Validazione umana prima della conferma |
4. Scrittura irreversibile | Pagamenti, comunicazioni con i clienti, modifiche alla produzione | Approvazione esplicita, doppio controllo e piano di annullamento |
La regola generale è che La maggior parte del valore aziendale si trova nei livelli 1 e 3., e la maggior parte del rischio si concentra nella fase 4. Un agente che prepara il rimborso e lo lascia in attesa di approvazione ottiene quasi tutto il risparmio di tempo con una frazione del rischio di chi esegue il rimborso.
Quando qualcuno insiste sul livello 4, la domanda giusta è quanto valore aggiunto offra rispetto al livello 3. Di solito si tratta del tempo necessario a premere un pulsante. Raramente questo tempo viene compensato.
Identità di sé attraverso l'agente. Mai un account condiviso o il riutilizzo di un account di servizio esistente. Senza un'identità univoca, è impossibile risalire all'origine dell'accaduto.
Indennità minima per compito, non per agente. Se l'agente esegue tre compiti diversi, ognuno dovrebbe avere un proprio ambito. Un'autorizzazione concessa per un compito diventa disponibile per tutti gli altri.
Credenziali a breve termine. Si tratta di token che scadono, non di chiavi permanenti in un file di configurazione.
Lista bianca di titoli azionari. È preferibile definire esplicitamente quali operazioni possono essere eseguite, piuttosto che quali no. Quest'ultimo approccio è sempre incompleto.
Limiti di volume e di quantità. Un agente autorizzato a emettere rimborsi dovrebbe avere un limite per transazione e al giorno. È lo stesso principio che si applica a qualsiasi individuo con potere d'acquisto.
Registrazione completa e immutabile. Cosa è stato inserito, cosa è stato deciso, cosa è stato eseguito, con quale versione del modello e chi lo ha convalidato. Senza queste informazioni, non c'è possibilità di verifica né di difesa.
Interruttore di arresto. Un meccanismo per arrestare l'agente senza implementare codice e senza dipendere dal fornitore.
Nessuna delle sette è insolita. Si tratta di pratiche di sicurezza standard applicate a un nuovo attore. Ciò che colpisce è la frequenza con cui vengono omesse proprio perché l'attore è nuovo e non si adatta alle procedure esistenti.
Il rischio di questo articolo è che possa essere interpretato come un'argomentazione a favore dell'inazione. Non lo è. L'approccio che funziona è la scalabilità progressiva:
Questo è lo stesso principio di supervisione a livelli che applichiamo quando integriamo componenti di IA nei sistemi aziendali, ed è il motivo per cui la governance non è una fase finale del progetto ma una proprietà della sua architettura, come abbiamo spiegato in Rischi, allucinazioni e governance dell'IA
Prima di approvare qualsiasi implementazione di un agente, è consigliabile rispondere a questa domanda: Se uno sconosciuto potesse scrivere il testo che questo agente sta per leggere, qual è la cosa peggiore che potrebbe fargli fare?
Se la risposta è "consultare le informazioni pubbliche", il rischio è accettabile. Se la risposta è "effettuare un pagamento" o "scrivere a tutti i nostri clienti", il progetto non è completo.
Perché determinano la potenziale superficie di danno. Un agente non può causare danni dove non è autorizzato, indipendentemente dalla qualità del modello o dal fatto che sia stato manipolato. OWASP dedica una categoria separata a questo problema nella sua Top 10 LLM Applications for 2025: Excessive Agency.
Si tratta dell'attribuzione di capacità eccessive a un agente, in tre forme: funzionalità eccessive (accesso a strumenti non necessari al suo compito), permessi eccessivi (identità con più privilegi del necessario) ed autonomia eccessiva (esecuzione di azioni di grande impatto senza convalida umana).
Si tratta dell'attribuzione di capacità eccessive a un agente, in tre forme: funzionalità eccessive (accesso a strumenti non necessari al suo compito), permessi eccessivi (identità con più privilegi del necessario) ed autonomia eccessiva (esecuzione di azioni di grande impatto senza convalida umana).
Sette: identità unica e non condivisa, autorizzazioni minime per attività, credenziali di breve durata, lista bianca delle azioni consentite, limiti di volume e quantità, registrazione completa e immutabile di ogni esecuzione e un meccanismo di arresto che non richiede la distribuzione di codice.
Solo per azioni reversibili e a basso impatto, e solo dopo aver misurato per un periodo sufficiente la percentuale di proposte approvate senza modifiche. L'eliminazione della validazione umana a causa della pressione delle scadenze è la causa più comune di incidenti nei sistemi agentivi.
Simili ai controlli di accesso umani, ma con maggiore rigore: registrazione documentata, responsabile assegnato, autorizzazioni verificabili, scadenza delle credenziali e revisione periodica. Nel 2025 IBM ha documentato che il protocollo 97% per le organizzazioni che hanno subito incidenti legati all'intelligenza artificiale non disponeva di controlli di accesso adeguati.
Sai esattamente cosa può fare ciascun agente che hai implementato? Analizziamo la portata, le identità, le autorizzazioni e la tracciabilità dei vostri sistemi di intelligenza artificiale e forniamo una diagnosi per iscritto. Richiedi la verifica → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
