L'AI non ha deciso di diventare un hacker. Qualcuno le ha dato le chiavi.

Se avete seguito il caso dell'agente AI che, incaricato di aiutare il proprio utente ad avanzare nella lista d'attesa di una palestra australiana, ha scoperto una falla nell'API di prenotazione ed ha cancellato la prenotazione di un'altra persona, avrete probabilmente letto titoli sull'AI che avrebbe deciso di diventare hacker, che avrebbe sviluppato una specie di perspicacia umana oppure che sarebbe andata fuori controllo. Io ci vedo qualcosa di molto meno fantascientifico e, proprio per questo, potenzialmente molto più pericoloso. Il modello non si è svegliato con una nuova vocazione criminale e non ha inventato un obiettivo proprio: aveva un obiettivo assegnato, ha trovato una strada tecnicamente percorribile ed ha utilizzato una capacità che il sistema gli consentiva di utilizzare. Il problema si può riassumere in una riga: «raggiungi X» NON significa «sei autorizzato a fare qualsiasi cosa tecnicamente possibile per raggiungere X».

Un agente AI, semplificando parecchio, nasce dall'interazione fra prompt di sistema → prompt utente → orchestratore → modello → tools → mondo reale, e questo piccolo schema secondo me è fondamentale perché ci ricorda che il modello da solo non possiede magicamente la possibilità di cancellare prenotazioni, interrogare database, spedire mail oppure modificare file. Qualcuno gli ha dato strumenti capaci di raggiungere quei sistemi, qualcuno ha stabilito quali credenziali utilizzare, qualcuno ha deciso quali funzioni esporre e qualcuno ha costruito il pezzo di software che traduce una decisione probabilistica del modello in una richiesta reale verso un server. Nel caso australiano l'agente, eseguito tramite OpenClaw con Claude, ha trovato che l'API del sistema di prenotazione consentiva di cancellare una prenotazione appartenente ad un altro utente senza effettuare il necessario controllo di autorizzazione, ed è esattamente qui che comincia il problema interessante: una capacità tecnica esisteva, il server l'accettava ed il sistema agentico non possedeva un confine abbastanza forte da impedire che quella capacità venisse utilizzata su una persona estranea.

Ed è qui che secondo me stiamo accumulando una quantità enorme di GARBAGE AGENTICA. Oggi abbiamo framework e piattaforme che promettono di costruire agenti in «4+4=8»: colleghi un LLM, gli dai qualche tool, scrivi due istruzioni in linguaggio naturale ed improvvisamente hai qualcosa che può navigare, chiamare API, interrogare database, modificare file, spedire mail ed eseguire codice. Fantastico. Ma dare una capacità ad un agente ed autorizzarne l'utilizzo sono due problemi completamente differenti, ed il secondo non può essere risolto semplicemente sperando che il primo sappia sempre interpretare correttamente una frase. Se fornisco ad un agente un tool database_query(sql) capace di eseguire qualsiasi istruzione SQL e poi provo ad impedirgli di fare danni scrivendo nel prompt usa il database soltanto per le operazioni necessarie, non ho costruito un sistema di sicurezza. HO SCRITTO UNA FRASE.

Il tool dovrebbe invece essere progettato affinché l'agente possa eseguire soltanto determinate operazioni, su determinate risorse e con determinati parametri, applicando autorizzazioni che vivono fuori dal modello. Una DELETE critica non dovrebbe diventare lecita perché il modello ha trovato una sequenza di ragionamento nella quale quella DELETE appare funzionale all'obiettivo; se un agente deve consultare gli ordini gli si dà una funzione di lettura sugli ordini, non un accesso SQL universale al database, se deve prenotare per l'utente gli si espongono operazioni che agiscono sulle risorse di QUELL'UTENTE, non una cancellazione generica applicabile ad un identificativo qualsiasi. È il principio del least privilege, cioè del privilegio minimo, applicato agli agenti prima ancora che ai loro prompt. Il modello propone, l'architettura autorizza ed il tool esegue soltanto ciò che l'architettura gli permette di eseguire.

Per le operazioni irreversibili oppure ad alto impatto aggiungerei poi un livello ancora più semplice, ovvero l'approvazione umana esplicita. Non perché l'essere umano sia infallibile, ma perché esiste una differenza enorme fra leggere una posizione in lista d'attesa e cancellare la prenotazione di un'altra persona, esattamente come esiste fra leggere una mail e spedirla, fra consultare una fattura e disporre un pagamento, fra analizzare una configurazione cloud e modificarla. OWASP tratta già questo problema sotto il nome di Excessive Agency e raccomanda proprio di ridurre strumenti, funzioni e privilegi al minimo necessario, di eseguire le azioni nel contesto autorizzativo dell'utente e di richiedere approvazione umana per quelle ad alto impatto. Non è quindi una questione filosofica su quanto il modello sia buono o cattivo, è normale progettazione di sicurezza.

Per questo non parlerei nemmeno soltanto di prompt sbagliato. Un prompt di sistema deve essere coerente, granulare, privo di regole conflittuali e deve certamente dire al modello quali comportamenti sono ammessi, ma trasformarlo nel firewall principale dell'agente significa chiedere ad un sistema probabilistico di essere contemporaneamente l'esecutore e l'autorità che decide se l'esecuzione sia consentita. Il firewall deve stare ANCHE SOTTO. Se l'utente chiede di farlo avanzare nella lista d'attesa, l'orchestratore può consentire funzioni come get_waitlist_position() e book_available_slot(), mentre un'operazione capace di cancellare la prenotazione di un altro utente non dovrebbe neppure essere tecnicamente raggiungibile in quel contesto oppure dovrebbe richiedere un'autorizzazione separata. Non ha molto senso mettere a disposizione un generico DELETE /booking/{id} confidando poi nel fatto che il modello capirà quando sia moralmente, legalmente e tecnicamente opportuno non usarlo.

E qui c'è l'altro mezzo incidente che non dipende affatto dall'AI. Se l'API della palestra accettava una cancellazione su una prenotazione appartenente ad un altro utente senza verificare che chi effettuava la richiesta fosse autorizzato a modificarla, abbiamo un problema di broken access control lato server, più precisamente il genere di difetto che OWASP classifica fra le vulnerabilità di autorizzazione a livello di oggetto nelle API. Quella verifica doveva essere fatta dal server indipendentemente dal fatto che la richiesta provenisse da un browser, da uno script, da un essere umano oppure da un agente AI. L'agente non ha creato quella falla, l'ha trovata ed utilizzata. Ed è la sovrapposizione delle due debolezze a rendere il caso molto più istruttivo di tutta la narrativa sulla macchina diventata cattiva: API vulnerabile + AGENTE SOVRA-PERMESSO = INCIDENTE.

Non serve quindi attribuire alla AI volontà, intuizione, avidità oppure un'improvvisa vocazione criminale. Le abbiamo fornito un obiettivo, capacità operative sufficientemente ampie ed un perimetro che non ha impedito un'azione capace di danneggiare un terzo, mentre dall'altra parte un server vulnerabile ha accettato quella stessa azione. Il modello ha trovato una sequenza compatibile con ciò che il sistema gli permetteva di fare, e questo secondo me è molto più serio della storiella dell'AI che «ha deciso di hackerare una palestra», perché un chatbot progettato male produce una risposta sbagliata, mentre un agente progettato male collegato a filesystem, database, posta elettronica, API aziendali, infrastrutture cloud oppure sistemi industriali può trasformare quella stessa risposta sbagliata in un'AZIONE SBAGLIATA.

Ed un'azione sbagliata può essere irreversibile. Il problema non dimostra che le AI stiano diventando umane, dimostra qualcosa di molto meno spettacolare: stiamo dando capacità operative enormi a sistemi probabilistici e troppo spesso proviamo a contenerle con altro linguaggio naturale. Prima di costruire l'agente bisogna progettare i suoi confini, prima di dargli un tool bisogna chiedersi non soltanto cosa debba fare ma soprattutto cosa NON DEBBA ESSERE TECNICAMENTE IN GRADO DI FARE, ed ancora prima sarebbe utile aver compreso bene che cosa è una AI, invece di continuare a stupirci attribuendole ciò che non è!